------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1168 Summary: TLS SNI support Product: Exim Version: N/A Platform: Other OS/Version: All Status: NEW Severity: wishlist Priority: medium Component: TLS AssignedTo: [email protected] ReportedBy: [email protected] CC: [email protected] This has been in my private todo list, but since RFC 6186 explicitly calls it out as a requirement for submission mail servers: We should support SNI (Server Name Indication) in TLS as both a client and a server. Client is easy but not well defined for email to MX: it's just an extra option. Should probably make the choice of hostname to send configurable. Server-side is most useful for Submission, where there _is_ a clearly defined domain name for clients to verify. We need to hook into an earlier stage of TLS negotiation and provide an expansion variable $tls_sni which can be used in the definitions of various variables; besides the obvious two, people might reasonably have different policies about which hosts are required to use TLS for which domains, so probably $tls_sni should remain valid for the lifetime of the connection (but should not be stored with the message). We should be careful to explicitly unset it at the start of outbound deliveries (but then can be set by configuration). It's just about conceivable that someone might be trying to change protocol suites advertised to clients but not able to do so for all domains; more conceivable that someone responsible for example.com might set up test.example.com with stricter rules and get experience that way, so $tls_sni might reasonably be used as a lookup key even in tls_require_ciphers. However, I suspect that it's far too late to change those settings, once TLS is already negotiating and SNI is received, so I suspect that a distinct IP address will still be needed for such cases. * tls_privatekey * tls_certificate * tls_verify_certificates * tls_crl * tls_verify_hosts * tls_try_verify_hosts At present, tls_privatekey is needed during init, before we start letting clients talk to us. Admins will, for the foreseeable future, still need to support clients which lack SNI support. So a reasonable construct might be: tls_certificate = /etc/exim/tls/cert${if def:tls_sni {-${lookup{$tls_sni}cdb{/etc/exim/tls/domains-to-tag.cdb}}}{}}.pem This would then be expanded twice: once at TLS session startup, and then _again_ iff SNI is used. It's conceivable that someone might only want to use TLS with SNI and thus fail the TLS handshake if SNI is not supplied. If it's possible to use the TLS libraries _without_ a certificate defined at the very start, we could then support such a case, but would then need to detect string expansion failure because $tls_sni was referenced unset, as opposed to any other cause, to continue to be able to not advertise TLS when not configured completely. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
