Respecting MTA-STS

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

Respecting MTA-STS

Micah Anderson-2

If we want to try and respect MTA-STS, when doing STARTTLS, the sender
needs to send the right information in the TLS SNI (Server Name
Inidication) extension. An MTA-STS-honoring SMTP client expects to
validate the X.509 certificate of the receiving MTA, but that MTA might
be known by a dozen names, unless the SNI is provided.

For example, if i'm trying to reach out to mail.example.biz but it
happens to also serve mail.example.com on the same address at port 25, I
definitely need to tell it which hostname i'm looking for, so that the
server can offer me the mail.example.biz certificate instead of the
mail.example.com certificate.

Unfortunately, in postfix versions prior to 3.4 SNI is not sent. In
postfix 3.4, the parameter 'smtp_tls_servername' was added. This is an
*optional* parameter that sends the value to the remote SMTP server in
the TLS SNI extension.

However, the documentation seems to suggest that there could be problems
with this parameter:

http://www.postfix.org/postconf.5.html#smtp_tls_servername

        Some SMTP servers use the received SNI name to select an
        appropriate certificate chain to present to the client. While
        this may improve interoperability with such servers, it may
        reduce interoperability with other servers that choose to abort
        the connection when they don't have a certificate chain
        configured for the requested name. When in doubt, leave this
        parameter empty, and configure per-destination SNI as needed

I'm wondering what this particular problem in the documentation is
about. Does anyone have any statistics of how frequent of an occurrence
this actually is, is it actually such a major problem that turning this
on will cause significant issues?

I'd like to enable this parameter, but I'm concerned that this might
cause problems. Ideally, this parameter should be on by default, but
this warning in the documentation seems to suggest there are some widely
implemented problems that need to be uncovered and I'd like to find out
more about what these are.

It seems like if we wish to respect MTA-STS, we need to get servers who
are doing this to stop doing this.

We need to know what servers are doing this so we can get them to
change.

Does anyone want to get the gamification sites to add this test to their
servers (mxtoolbox etc)? Or can people connect to all the servers you've
connected to in the past, with SNI, and see if it aborts connections and
then make a list that we can go harass to fix?



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

Re: Respecting MTA-STS

A. Schulze

micah anderson:

> If we want to try and respect MTA-STS, when doing STARTTLS, the sender
> needs to send the right information in the TLS SNI (Server Name
> Inidication) extension. An MTA-STS-honoring SMTP client expects to
> validate the X.509 certificate of the receiving MTA, but that MTA might
> be known by a dozen names, unless the SNI is provided.

I don't fully understand the value of SNI for MTA-to-MTA communication,
but that's an other problem.

I suggest to look at https://github.com/Snawoot/postfix-mta-sts-resolver ...

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Respecting MTA-STS

Micah Anderson-2
"A. Schulze" <[hidden email]> writes:

> micah anderson:
>
>> If we want to try and respect MTA-STS, when doing STARTTLS, the sender
>> needs to send the right information in the TLS SNI (Server Name
>> Inidication) extension. An MTA-STS-honoring SMTP client expects to
>> validate the X.509 certificate of the receiving MTA, but that MTA might
>> be known by a dozen names, unless the SNI is provided.
>
> I don't fully understand the value of SNI for MTA-to-MTA communication,
> but that's an other problem.

As I wrote in the initial email, if i'm trying to reach out to
mail.example.biz but it happens to also serve mail.example.com on the
same address at port 25, I definitely need to tell it which hostname i'm
looking for, so that the server can offer me the mail.example.biz
certificate instead of the mail.example.com certificate.

> I suggest to look at
> https://github.com/Snawoot/postfix-mta-sts-resolver

I am aware of that, but I'm not asking specifically how to implement
this, I'm more trying to find out what really is the concern here with
enabling this, and what we need to do to fix that.

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

Re: Respecting MTA-STS

Viktor Dukhovni
> On Oct 11, 2019, at 10:19 AM, micah anderson <[hidden email]> wrote:
>
> I am aware of that, but I'm not asking specifically how to implement
> this, I'm more trying to find out what really is the concern here with
> enabling this, and what we need to do to fix that.

The concern is as stated, we don't know what remote MTAs will do if
they receive an unexpected SNI.  You can try it I guess, and see
what happens.

One way to hedge your bets is to use the "servername" field in
per-destination TLS policies, but otherwise leave SNI disabled.
Since you probably need a policy service anyway to emulate MTA-STS
in Postfix, that policy service can also return "servername=hostname".

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Respecting MTA-STS

Micah Anderson-2
Viktor Dukhovni <[hidden email]> writes:

>> On Oct 11, 2019, at 10:19 AM, micah anderson <[hidden email]> wrote:
>>
>> I am aware of that, but I'm not asking specifically how to implement
>> this, I'm more trying to find out what really is the concern here with
>> enabling this, and what we need to do to fix that.
>
> The concern is as stated, we don't know what remote MTAs will do if
> they receive an unexpected SNI.  You can try it I guess, and see
> what happens.

Indeed, this is why I was wondering how we could go about probing these
remote MTAs to track down what exactly they would do. We'd need someone
who has a significant number of remote clients that they send to, over
TLS, to gather those and attempt to connect using SNI to see what would
happen.

Or is there a good 'gamification' site that people use that could be
convinced to add this check?

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

Re: Respecting MTA-STS

Viktor Dukhovni
On Fri, Oct 11, 2019 at 11:32:50AM -0400, micah anderson wrote:

> > The concern is as stated, we don't know what remote MTAs will do if
> > they receive an unexpected SNI.  You can try it I guess, and see
> > what happens.
>
> Indeed, this is why I was wondering how we could go about probing these
> remote MTAs to track down what exactly they would do. We'd need someone
> who has a significant number of remote clients that they send to, over
> TLS, to gather those and attempt to connect using SNI to see what would
> happen.
>
> Or is there a good 'gamification' site that people use that could be
> convinced to add this check?

FWIW, I just sent my system a message from a Gmail account, with a
tcpdump capture running to record inbound SMTP traffic.  My system
does not advertise MTA-STS, and, AFAIK, Gmail does not support
outbound DANE.  So my server plausibly looks "generic" to Gmail's
outbound systems.

The tshark decode of that traffic, shows, that Gmail sends SNI,
probably unconditionally, especially because it also attempts to
negotiate TLS 1.3, where SNI is generally expected.

So likely at this point it is safe to conclude that sending SNI is
unlikely to cause problems.  Your mileage may vary.

--
        Viktor.

Transport Layer Security
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 255
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 251
            Version: TLS 1.2 (0x0303)
            Random: b076d376a44eb9442cf84e00ccce53ac3ce3e8742d704c63…
                GMT Unix Time: Oct 25, 2063 18:36:38.000000000 EDT
                Random Bytes: a44eb9442cf84e00ccce53ac3ce3e8742d704c6320e8547a…
            Session ID Length: 32
            Session ID: ec944655829cba19b42319521a5f0c8c2503a0bd1cf1e4a8…
            Cipher Suites Length: 36
            Cipher Suites (18 suites)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 142
            Extension: server_name (len=22)
                Type: server_name (0)
                Length: 22
                Server Name Indication extension
                    Server Name list length: 20
                    Server Name Type: host_name (0)
                    Server Name length: 17
                    Server Name: smtp.dukhovni.org
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0
            Extension: supported_groups (len=8)
                Type: supported_groups (10)
                Length: 8
                Supported Groups List Length: 6
                Supported Groups (3 groups)
                    Supported Group: x25519 (0x001d)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: secp384r1 (0x0018)
            Extension: ec_point_formats (len=2)
                Type: ec_point_formats (11)
                Length: 2
                EC point formats Length: 1
                Elliptic curves point formats (1)
                    EC point format: uncompressed (0)
            Extension: session_ticket (len=0)
                Type: session_ticket (35)
                Length: 0
                Data (0 bytes)
            Extension: signature_algorithms (len=20)
                Type: signature_algorithms (13)
                Length: 20
                Signature Hash Algorithms Length: 18
                Signature Hash Algorithms (9 algorithms)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (4)
                    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (5)
                    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (6)
                    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
            Extension: key_share (len=38)
                Type: key_share (51)
                Length: 38
                Key Share extension
                    Client Key Share Length: 36
                    Key Share Entry: Group: x25519, Key Exchange length: 32
                        Group: x25519 (29)
                        Key Exchange Length: 32
                        Key Exchange: bf35ed7ad1b921cc3d1442977047cbb1a98430348588ab49…
            Extension: psk_key_exchange_modes (len=2)
                Type: psk_key_exchange_modes (45)
                Length: 2
                PSK Key Exchange Modes Length: 1
                PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
Reply | Threaded
Open this post in threaded view
|

Re: Respecting MTA-STS

A. Schulze


Am 11.10.19 um 18:10 schrieb Viktor Dukhovni:
> So likely at this point it is safe to conclude that sending SNI is
> unlikely to cause problems.  Your mileage may vary.

Hi,

that Gmail enabled SNI on their SMTP client is an indicator that using SNI may not cause relevant trouble.
But it's also known, Gmail is able to do such stuff very selective to prevent damage.

In theory, an SMTP client, postfix smtp for example, could always try to connect to a remote destination
using SNI, log success or failure and fallback to reconnect without SNI.
That would enable users to gather their own statistics.

reading http://www.postfix.org/postconf.5.html#smtp_tls_servername give me the impression one
could set "smtp_tls_servername = hostname". That would force the SMTP client to always send SNI.

The admin can monitor the log for additional delivery failures and gather statistics.
Right?

Andreas
 
Reply | Threaded
Open this post in threaded view
|

Re: Respecting MTA-STS

Viktor Dukhovni
On Fri, Oct 11, 2019 at 08:02:32PM +0200, A. Schulze wrote:

> that Gmail enabled SNI on their SMTP client is an indicator that using SNI
> may not cause relevant trouble.  But it's also known, Gmail is able to do
> such stuff very selective to prevent damage.

Indeed I am not presently able to rule out that possibility, the
question could be posed to the Gmail email engineering team directly,
they probably know the answer.

> In theory, an SMTP client, postfix smtp for example, could always try to
> connect to a remote destination using SNI, log success or failure and
> fallback to reconnect without SNI.

That feels too complicated, how many permutations of TLS settings
do you want Postfix to try when TLS handshakes fail?

> Reading http://www.postfix.org/postconf.5.html#smtp_tls_servername give
> me the impression one could set "smtp_tls_servername = hostname". That
> would force the SMTP client to always send SNI.

Yes, and one can set it empty in a per-destination policy for
any hypothetical site that breaks as a consequence.

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

Re: Respecting MTA-STS

Viktor Dukhovni
In reply to this post by Micah Anderson-2
On Fri, Oct 11, 2019 at 02:17:16PM -0400, Viktor Dukhovni wrote:

> > that Gmail enabled SNI on their SMTP client is an indicator that using SNI
> > may not cause relevant trouble.  But it's also known, Gmail is able to do
> > such stuff very selective to prevent damage.
>
> Indeed I am not presently able to rule out that possibility, the
> question could be posed to the Gmail email engineering team directly,
> they probably know the answer.

I've reached out to two Gmail engineers, don't yet have an answer.
It could take some time...

On Thu, Oct 17, 2019 at 03:33:47PM -0400, Daniel Kahn Gillmor wrote:

> If we shift the default for postfix this way, and an installation
> observes a specific failure on a target delivering host, they can
> override this setting (bringing it back to the empty string) manually.

Yes.

> ---
>  postfix/html/postconf.5.html     | 4 ++--
>  postfix/man/man5/postconf.5      | 4 ++--

These files are build artefacts, not sources, the source file is
proto/postconf.proto, from which both are constructed, and which
then also updates the defaults reported in manpages that reference
the parameter.  It suffices to update the source, and the rest
happens when Wietse builds a package for distribution.


> --- a/postfix/src/global/mail_params.h
> +++ b/postfix/src/global/mail_params.h
> @@ -1598,9 +1598,9 @@ extern char *var_smtp_tls_sec_cmatch;
>  extern char *var_smtp_tls_fpt_cmatch;
>  
>  #define VAR_SMTP_TLS_SNI "smtp_tls_servername"
> -#define DEF_SMTP_TLS_SNI ""
> +#define DEF_SMTP_TLS_SNI "hostname"
>  #define VAR_LMTP_TLS_SNI "lmtp_tls_servername"
> -#define DEF_LMTP_TLS_SNI ""
> +#define DEF_LMTP_TLS_SNI "hostname"
>  extern char *var_smtp_tls_sni;
>  
>  #define VAR_SMTP_TLS_BLK_EARLY_MAIL_REPLY "smtp_tls_block_early_mail_reply"

Should the LMTP default be explicit, or should it inherit the SMTP
setting?  I guess the current empty values are explicit, so inheritance
would be a surprising change.

I'd prefer to wait to hear back from my Gmail contacts, but this
change probably makes sense these days.

--
        Viktor.