SMTP SNI Support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
MK
Reply | Threaded
Open this post in threaded view
|

SMTP SNI Support

MK
There were some discussions in 2015 and more recently about SNI support.

For IMAP/POP, dovecot (which allows SNI support) has a configuration like this in our setup:
local_name imap.example.org {
  ssl_cert = </etc/ssl/certs/imap.example.org.crt
  ssl_key = </etc/ssl/private/imap.example.org.key
}
local_name imap.example2.org {
  ssl_cert = </etc/ssl/certs/imap.example2.org.crt
  ssl_key = </etc/ssl/private/imap.example2.org.key
}

Moving from a perl-based SMTP server that allowed me to load multiple certificates, my clients all use mail.yourdomain.com:587 as their outgoing mail server. For the most part, a STARTTLS command is issued and the connection is upgraded to SSL. This has worked really well, with the end user needing to remember only mail.yourdomain.com for incoming and outgoing mail, and still getting SSL encryption.  Thus far, we've found every mail client has supported this method without any errors.

I found this discussion circa 2015 ( http://postfix.1071664.n5.nabble.com/postfix-and-multiple-TLS-certificates-td80968.html ) which references the request, but it doesn't seem to have come into fruition.


This is not for outgoing SSL (which makes senses to come only from the server), or for incoming mail (which would go to the MX record in question) but for incoming mail submission, via SSL. The clients all support SNI, any recent version of OpenSSL supports SNI.

Does postfix?  If so how to configure?  If not, how to feature request this?



-M
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

Bill Cole-3
On 25 Jan 2018, at 16:17 (-0500), MK wrote:

> There were some discussions in 2015 and more recently about SNI
> support.
> For IMAP/POP, dovecot (which allows SNI support) has a configuration
> like this in our setup:
>
> local_name imap.example.org {  ssl_cert =
> </etc/ssl/certs/imap.example.org.crt  ssl_key =
> </etc/ssl/private/imap.example.org.key}local_name imap.example2.org
> {  ssl_cert = </etc/ssl/certs/imap.example2.org.crt  ssl_key =
> </etc/ssl/private/imap.example2.org.key}
>
> Moving from a perl-based SMTP server that allowed me to load multiple
> certificates, my clients all use mail.yourdomain.com:587 as their
> outgoing mail server. For the most part, a STARTTLS command is issued
> and the connection is upgraded to SSL. This has worked really well,
> with the end user needing to remember only mail.yourdomain.com for
> incoming and outgoing mail, and still getting SSL encryption.  Thus
> far, we've found every mail client has supported this method without
> any errors.
>
> I found this discussion circa 2015
> ( http://postfix.1071664.n5.nabble.com/postfix-and-multiple-TLS-certificates-td80968.html )
> which references the request, but it doesn't seem to have come into
> fruition.

That thread also has explanations by Wietse & Viktor of why SNI for
Postfix is difficult both to justify and to safely implement.

> This is not for outgoing SSL (which makes senses to come only from the
> server), or for incoming mail (which would go to the MX record in
> question) but for incoming mail submission, via SSL. The clients all
> support SNI, any recent version of OpenSSL supports SNI.
> Does postfix? 

No.

> If so how to configure?  If not, how to feature request this?

Provide a compelling argument for it to Wietse?

I don't understand why SNI for mail submission is something anyone wants
to deploy instead of just giving all users just one hostname for
submission and handling the housekeeping for just one certificate.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

Viktor Dukhovni


> On Jan 25, 2018, at 5:52 PM, Bill Cole <[hidden email]> wrote:
>
>> I found this discussion circa 2015 ( http://postfix.1071664.n5.nabble.com/postfix-and-multiple-TLS-certificates-td80968.html ) which references the request, but it doesn't seem to have come into fruition.
>
> That thread also has explanations by Wietse & Viktor of why SNI for Postfix is difficult both to justify and to safely implement.
>
>> This is not for outgoing SSL (which makes senses to come only from the server), or for incoming mail (which would go to the MX record in question) but for incoming mail submission, via SSL. The clients all support SNI, any recent version of OpenSSL supports SNI.
>> Does postfix?
>
> No.

I'm tentatively planning to start work on SNI for Postfix 3.4 in April...

--
        Viktor.

MK
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

MK
Amazing!  Thanks!

I’d request considering allowing the SNI to be enabled per port. While using it in production we found a very small number (<1%) of mail servers sending to our server didn’t like SNI- likely ancient mail servers.  That said, we didn’t find any clients (outlook, phones, etc) that didn’t. At this time we run SNI on port 587 with all the certificates and port 25 is just the mail server name. I’d recommend making that setup an option for maximum compatibility, if possible.

As for the request for a use case someone mentioned, it’s based on a submission port (587). Hosting provider has machine1.hostingdomain.com machine2.hostingdomain.com and machine3.hostingdomain.com. One of their customers customerdomain.com comes on board with DNS changes and adds their mailboxes. Their employees don’t want to see Hostingdomain as their server name. Moreover, the customer needs more space and you move that customer from machine1 to machine2. You now need to update all clients.

Instead the client uses mail.customerdomain.com and you can move them around independent of the server setup without impacting clients.

Exim supports. Dovecot supports. It’s also the reality that we have servers with way more capacity these days and having another incoming hostname is not unthinkable.



Sent from Yahoo Mail for iPhone

On Thursday, January 25, 2018, 7:16 PM, Viktor Dukhovni <[hidden email]> wrote:



> On Jan 25, 2018, at 5:52 PM, Bill Cole <[hidden email]> wrote:
>
>> I found this discussion circa 2015 ( http://postfix.1071664.n5.nabble.com/postfix-and-multiple-TLS-certificates-td80968.html ) which references the request, but it doesn't seem to have come into fruition.
>
> That thread also has explanations by Wietse & Viktor of why SNI for Postfix is difficult both to justify and to safely implement.
>
>> This is not for outgoing SSL (which makes senses to come only from the server), or for incoming mail (which would go to the MX record in question) but for incoming mail submission, via SSL. The clients all support SNI, any recent version of OpenSSL supports SNI.
>> Does postfix?
>
> No.

I'm tentatively planning to start work on SNI for Postfix 3.4 in April...


--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

Viktor Dukhovni


> On Jan 25, 2018, at 9:30 PM, MK <[hidden email]> wrote:
>
> I’d request considering allowing the SNI to be enabled per port.

Each port gets its own entry in master.cf, so you will certainly
be able to enable or disable SNI support for a given TCP endpoint.

> While using it in production we found a very small number (<1%) of mail servers
> sending to our server didn’t like SNI- likely ancient mail servers.

This is rather intriguing... How would they even know you had SNI?
The effect of SNI is present a certificate selected on the basis
of the supplied hostname hint.  Otherwise, everything looks exactly
the same, so it is hard to imagine how said servers "didn't like" SNI.

Perhaps your server responded to some unexpected SNI names by aborting
the TLS handshake?  Postfix won't do that.  For SNI names that don't
have a matching configuration, Postfix will respond with a default
certificate, it'll be up to the client to either accept that or not.

--
        Viktor.

MK
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

MK

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 older --client-- openssl versions which we saw remote machines on the internet connecting as.

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:

User: guest / Pass: guest





Sent from Yahoo Mail for iPhone

On Thursday, January 25, 2018, 9:43 PM, Viktor Dukhovni <[hidden email]> wrote:



> On Jan 25, 2018, at 9:30 PM, MK <[hidden email]> wrote:
>
> I’d request considering allowing the SNI to be enabled per port.

Each port gets its own entry in master.cf, so you will certainly
be able to enable or disable SNI support for a given TCP endpoint.

> While using it in production we found a very small number (<1%) of mail servers
> sending to our server didn’t like SNI- likely ancient mail servers.

This is rather intriguing... How would they even know you had SNI?
The effect of SNI is present a certificate selected on the basis
of the supplied hostname hint.  Otherwise, everything looks exactly
the same, so it is hard to imagine how said servers "didn't like" SNI.

Perhaps your server responded to some unexpected SNI names by aborting
the TLS handshake?  Postfix won't do that.  For SNI names that don't
have a matching configuration, Postfix will respond with a default
certificate, it'll be up to the client to either accept that or not.


--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

Viktor Dukhovni


> On Jan 25, 2018, at 10:06 PM, MK <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: SMTP SNI Support

Bill Cole-3
In reply to this post by MK
On 25 Jan 2018, at 21:30 (-0500), MK wrote:

> Hosting provider has machine1.hostingdomain.com
> machine2.hostingdomain.com and machine3.hostingdomain.com. One of
> their customers customerdomain.com comes on board with DNS changes and
> adds their mailboxes. Their employees don’t want to see
> Hostingdomain as their server name.

In an age where MS and Google are in the mopping-up phase of the
extermination of smaller email outsourcers, this seems like something
customers don't really value all that much, but maybe that's just trauma
speaking...

> Moreover, the customer needs more space and you move that customer
> from machine1 to machine2. You now need to update all clients.
> Instead the client uses mail.customerdomain.com and you can move them
> around independent of the server setup without impacting clients.

That's a much more compelling case.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole