On 10/03/16 09:32, Curtis Villamizar wrote:
In message <56dfcd11.5010...@spectralmud.org>
Richard James Salts writes:
On 09/03/16 06:44, Viktor Dukhovni wrote:
On Mar 8, 2016, at 2:31 PM, Curtis Villamizar <cur...@orleans.occnc.com> wrote:
With HTTP the server cert is provided after HTTP identifies which
virtual host it thinks its talking to. The IP address along gives no
clue. That connection is then used only for that virtual host. This
is why you can have a TLS cert per vhost (aka DNS domain).
To be more precise, with HTTPS, the desired TLS server name is
conveyed via the TLS SNI extension and the HTTP server presents
the corresponding certificate. By contrast, the Postfix SMTP
server neither supports nor needs SNI.
But some MUAs (i.e. user's mail clients) do support SNI and will try to
match against the name that was entered into the configuration. This
might be important if you have many white label resellers who want
clients to be able to enter mail.<reseller's domain> into their
customers mail clients.
Which MUAs and exactly how do they use SNI?
I'm not sure on all of them, but thunderbird does at the very least. It
uses the name in the account settings. I tested this by adding an entry
to /etc/hosts with garbage in it and changing the settings to point to
that and I got a certificate name mismatch when trying to send via
submission port(587) on my server and packet capture shows this
reflected in the client hello after starttls. At the moment a few
clients can guess what server names should be based on an email address,
but they're usually using an adhoc heuristic. For instance thunderbird
has its own list that administrators can upload configurations for their
domain to, otherwise it will fall back to trying the domain itself on
well known smtp ports, then mail.domain, then smtp.domain. There is an
rfc for publishing records indicating the server the MUA should contact,
e.g. _submission._tcp SRV 0 1 mail.example.org. but in this case the
email client is recommended to use the email domain itself to
authenticate. This changes a bit with dnssec and there is a draft which
expires in July that gives some recommendations of this
(https://tools.ietf.org/html/draft-melnikov-uta-dnssec-email-tls-certs-00#section-5.1
specifically), but it's still a mess.
Most MUAs would be talking to a IMAP to receive mail and might also
use IMAP to send mail, therefore port 993, not 25 or 587.
btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but
I'm not sure about that.
If any do use port 587 do the MUAs use SNI to indicate which sender
domain? Your statement above seems to indicate a check made by the
client, but against what? The CN or subjectAltName(s) in the cert?
SNI requires that the client use an extension to the TLS handshake in
their client hello to say "I would like to talk to this FQDN" before it
establishes a secure connection. It's then up to the server to choose
what do do. In postfix which only supports SNI for the smtp client this
will mean it's only based on the ip/port combination and what's in
main.cf and/or overridden in master.cf with a separate listener.
AFAIK postfix has no support for SNI other than the limited support
for DANE, but a cert with MX FQDN in CN and all domains pointing at
that MX in subjectAltName also solves this with or without SNI. There
does not seem to be any postfix config option to specify per SNI cert.
Did I miss it? Otherwise, the only solution is putting everything in
subjectAltName (which means SNI does nothing for port 587 use).
Firstly, SMTP TLS connections are typically unauthenticated, and
it does not matter which certificate the server presents, so no
need to have one that matches any particular name.
In the rare cases that authentication does take place through
the magic of MX record redirection a single MX host can support
multiple domains provided that it is the MX hostname and not the
target domain that the client authenticates. This is the case
with DANE.
https://tools.ietf.org/html/rfc7672#section-1.3
The original question I think had to do with port 587 TLS (though I
admit some initial confusion on Tom's objectives) which would normally
use smtpd_tls_req_ccert=yes and use smtpd_tls_security_level=encrypt
on the server side. On the client side, connection to port 587 would
be better off with smtp_tls_security_level=encrypt rather than
dane-only and this would have nothing to do with MX records. In this
context (no MX lookup at all) I'm not sure what role SNI would play
(in a world where postfix supported everything even remotely useful).
If the original question was related to outside users connecting via
port 25 to send mail to a mailing list and getting a "per vhost cert"
(Tom's words, approximately), then SNI could do something useful if
postfix had a means to set smtpd_tls_key_file and smtpd_tls_cert_file
per SNI. This could be supported if something existed that was like
smtp_tls_policy_maps (the key feature being able to set any main.cf
policy statememt in the rhs) but on the smptd_ side and using SNI as
the key. (Maybe such a config option exists in a world where postfix
supports everything even remotely useful, but I couldn't find it in
local or online docs). This would work with or without TLSA records.
If one MX supports a large number of domains, the subjectAltName could
get rather large if there is no means to select key and cert based on
SNI and if the client side wanted to verify per domain (as DANE does)
rather than looking for the MX name in the cert. Just an observation.
Did I go wrong here somewhere?
Curtis
