Hi Viktor,
Is this on the roadmap for 3.4 or for a long-term roadmap?Just curious.Thanks
for all the amazing work on Postfix.
-M
From: Viktor Dukhovni <postfix-us...@dukhovni.org>
To: Postfix users <postfix-users@postfix.org>
Sent: Thursday, January 25, 2018 10:23 PM
Subject: Re: SMTP SNI Support
> On Jan 25, 2018, at 10:06 PM, MK <ph...@rogers.com> wrote:
>
> OpenSSL implementations (OpenSSL 0.9.8 mainly which is used in Debian 8
> and others of that era of a few years ago) can't handle a server with SNI
> certificates and fails to connect.
This is not an accurate description of the problem. The real problem is
that the target server returned a warning alert when it could not find
a matching certificate for the requested SNI name, instead of quietly
returning a default certificate and not making a fuss.
As I mentioned before, Postfix will not be so silly. Perhaps surprisingly,
for once common sense also prevails in RFC6066:
https://tools.ietf.org/html/rfc6066#section-3
The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: either abort the handshake by sending a fatal-level
unrecognized_name(112) alert or continue the handshake. It is NOT
RECOMMENDED to send a warning-level unrecognized_name(112) alert,
because the client's behavior in response to warning-level alerts is
unpredictable. If there is a mismatch between the server name used
by the client application and the server name of the credential
chosen by the server, this mismatch will become apparent when the
client application performs the server endpoint identification, at
which point the client application will have to decide whether to
proceed with the communication.
Going further back, the original specification, outdated by RFC6066,
did recommend sending the alert:
https://tools.ietf.org/html/rfc4366#section-3.1
If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name"
alert (which MAY be fatal).
This design error is likely the source of the problem. File bug
reports against outdated server-side SNI implementations that follow
the obsolete RFC4366. The RFC6066 behaviour is by far more sensible.
> Incorrect openssl behaviour is noted here. debian exim4 for example would
> fail to connect to the smtp server when sni was enabled among other random
> servers on the net . They were rare, but our solution was to not have sni on
> port 25 anyway and run it only on port 587, where clients typically have a
> much faster upgrade cycle. For the most part servers were okay but those
> linked with problematic versions didn’t like it.
>
> Tons of details and the particular patch here:
>
> https://rt.openssl.org/m/ticket/history?id=3038
Thanks for that. It clearly explains the interoperability failure. This
will not be an issue for Postfix.
--
Viktor.
