------- 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: pdp@???
ReportedBy: pdp@???
CC: exim-dev@???
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
