In message <56e0ccb4.6010...@spectralmud.org> Richard James Salts writes: > > 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.
Thanks. 5.1 bullet 2 is what I described as the workaround - one cert with lots of domain names in subjectAltName. OK for self signed certs or a local CA. Bullet 4 is SNI (best choice IMHO if it was a choice). > > 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. So you are confirming that for an MUA that uses the SNI extension, postfix smptd can't take advantage of this to send a specific cert and we have to fall back to lots of domains in subjectAltName or separate ports for each domain. OK got it. Thanks. > > 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
