Am 2015-12-15 20:36, schrieb Viktor Dukhovni:
On Mon, Dec 14, 2015 at 04:34:58PM +0000, Viktor Dukhovni wrote:
So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2. I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.
So far I'm not sensing any burning desire for server-side SNI in
Postfix, and it is quite late in the 3.1 cycle, so if we're going
to do SNI, it'll be in 3.2 or later.
At present, the Postfix SMTP client only sends SNI with DANE, where
it is clear what name to ask for (the TLSA base domain). With
"verify" and "secure" it is far from clear that sending SNI would
do more good than harm, and we match multiple names or name patterns,
so the choice of what to send in SNI is not so clear.
I think we're set for now with Postfix as-is.
Could you explain, why you think sending SNI could harm?
Lets look at the different cases assuming no DNSSEC is used. In the
general case the only trustable reference identifier therefore is the
domain of the recipient address. If you do not send SNI then the server
sends the default cert attached to the ip address of the server (TLS
connection endpoint). If it was possible to put all hosted domains into
the SAN of the cert you get a match for your reference identifier and if
the cert could be verified you get an authenticated TLS connection. If
the domain was not in the set of presented identifiers at the maximum
you get a trusted TLS connection (cert verified) but no authenticated
TLS connection.
If you send the recipient domain as SNI the server checks its certs:
- if it only has a default cert, it sends the default cert
- if it has multiple certs, it checks the presented identifiers (SAN of
cert) for a match with the SNI.
* if there is no match, it sends the default cert,
* if there is a match it sends the matching cert.
Therefore, if you send SNI and get back the default cert, there is no
difference to not sending SNI. If you get back a different cert than the
default cert, your reference identifier which you send as SNI is among
the presented identifiers of the cert. Therefore you have a match and
that is exactly what you want.
For the single recipient email I cannot see any possible harm.
If you have a multi-recipient email and
- the domain of all recipients ist the same there is no difference to
the single-recipient email
- if the domains are different and
* if the connection endpoints of the TLS connections are different,
you must create multiple TLS connections and each TLS connection behaves
the same way as in the single recipient email case
* if the connection endpoints are the same
+ you could ignore this and still use a different connection for
every domain as in the case above
+ you could try to optimize the number of connections and use the
domain of the first recipient for SNI and then check for the next
recipient if the domain is included in the presented identifiers
. if yes reuse the TLS connection
. if not open a new connection with that domain as SNI
In both cases you get back either the default cert and maybe a match
or another cert with a match
Therefore if you send SNI you are getting the highest chance for a match
for your reference identifier and therefore for an authenicated TLS
connection. The cost would be the higher number of connections is some
cases. Thats the only harm I can see. But the benefit of more possible
matches is much more important.
Michael
