Message not retransmitted immediately after opportunistic TLS handshake failure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Message not retransmitted immediately after opportunistic TLS handshake failure

Nikk
Hi all,

In one of my tests I'm configuring Postfix client (smtp) to use opportunistic TLS with TLSv1.2 protocol only and the next MTA (server side) to use opportunistic TLS with TLSv1.1 only,
to see the behaviour of Postfix after a failed handshake.
As expected the TLS handshake fails, but Postfix moves the message to deferred queue rather than retrying immediately in plaintext.

What is the reason of the timeout between the incoming_arrival and active_arrival (var_min_backoff_time) of a message, before the message is allowed to be immediately retransmitted?

Many thanks,

Nik Kostaras

Team Leader

[Telephone] +44 118 903 8635

[Twitter]@clearswift

[Clearswift] <http://www.clearswift.com/>

1310 Waterside | Arlington Business Park | Theale | Berkshire | RG7 4SA | United Kingdom


Adaptive Adaptive Security & Data Loss Prevention solutions for email, web, cloud apps and endpoint. On-premise and Hosted deployment options available.

Secure Sharing, Redaction and Data Loss Prevention with Clearswift. Learn more here<https://www.clearswift.com/solutions/information-security>.

This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated.  If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful.  If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security threats.

To find out more about Clearswift’s solutions please visit www.clearswift.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Wietse Venema
Nik Kostaras:
> As expected the TLS handshake fails, but Postfix moves the message
> to deferred queue rather than retrying immediately in plaintext.

What is the error message? The kind of error determines whether
or not Postfix will immediately fall back to plaintext immediately.
The Postfix version may matter as well.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Message not retransmitted immediately after opportunistic TLS handshake failure

Nikk
Postfix 3.2.0

Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 220 icarus.com ESMTP
Jun 22 17:30:26 postfix-outbound/smtp[27125]: > 10.44.43.1[10.44.43.1]:25: EHLO cs-gw-25856.localdomain
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 250-icarus.com
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 250-SIZE 20480000
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 250-STARTTLS
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 250-AUTH LOGIN
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 250 HELP
Jun 22 17:30:26 postfix-outbound/smtp[27125]: server features: 0x1019 size 20480000
Jun 22 17:30:26 postfix-outbound/smtp[27125]: smtp_stream_setup: maxtime=300 enable_deadline=0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: > 10.44.43.1[10.44.43.1]:25: STARTTLS
Jun 22 17:30:26 postfix-outbound/smtp[27125]: < 10.44.43.1[10.44.43.1]:25: 220 Ready to start TLS
Jun 22 17:30:26 postfix-outbound/smtp[27125]: setting up TLS connection to 10.44.43.1[10.44.43.1]:25
Jun 22 17:30:26 postfix-outbound/smtp[27125]: 10.44.43.1[10.44.43.1]:25: TLS cipher list "ALL:!aNULL:!EXP"
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr request = seed
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr size = 32
Jun 22 17:30:26 postfix-outbound/smtp[27125]: private/tlsmgr: wanted attribute: status
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute name: status
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute value: 0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: private/tlsmgr: wanted attribute: seed
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute name: seed
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute value: /Z4GA8CHRNRAq8X7WI8ZFRldWBsJmdqiOcx3LSGD06A=
Jun 22 17:30:26 postfix-outbound/smtp[27125]: private/tlsmgr: wanted attribute: (list terminator)
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute name: (end)
Jun 22 17:30:26 postfix-outbound/smtp[27125]: SSL_connect error to 10.44.43.1[10.44.43.1]:25: -1
Jun 22 17:30:26 postfix-outbound/smtp[27125]: warning: TLS library problem: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
Jun 22 17:30:26 postfix-outbound/smtp[27125]: connect to subsystem private/defer
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr nrequest = 0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr flags = 0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr queue_id = 3wtnBB3Jr7z1Q67T
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr original_recipient = [hidden email]
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr recipient = [hidden email]
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr offset = 691
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr dsn_orig_rcpt = rfc822;[hidden email]
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr notify_flags = 0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr status = 4.7.5
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr diag_type =
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr diag_text =
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr mta_type =
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr mta_mname =
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr action = delayed
Jun 22 17:30:26 postfix-outbound/smtp[27125]: send attr reason = Cannot start TLS: handshake failure
Jun 22 17:30:26 postfix-outbound/smtp[27125]: private/defer socket: wanted attribute: status
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute name: status
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute value: 0
Jun 22 17:30:26 postfix-outbound/smtp[27125]: private/defer socket: wanted attribute: (list terminator)
Jun 22 17:30:26 postfix-outbound/smtp[27125]: input attribute name: (end)
Jun 22 17:30:26 postfix-outbound/smtp[27125]: 3wtnBB3Jr7z1Q67T: to=<[hidden email]>, relay=10.44.43.1[10.44.43.1]:25, delay=0.08, delays=0.02/0.03/0.03/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure)

It reaches
if (PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE)
      RETRY_AS_PLAINTEXT;

inside smtp_start_tls(), but the condition is false the first time because of the "PREACTIVE_DELAY >= var_min_backoff_time" clause of  PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE.

Nik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wietse Venema
Sent: 22 June 2017 20:17
To: Postfix users <[hidden email]>
Subject: Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Nik Kostaras:
> As expected the TLS handshake fails, but Postfix moves the message to
> deferred queue rather than retrying immediately in plaintext.

What is the error message? The kind of error determines whether or not Postfix will immediately fall back to plaintext immediately.
The Postfix version may matter as well.

        Wietse

----------------------------------------------------------------------------------------------
Message Processed by the Clearswift V4 Engineering Dogfood Secure Email Gateway

This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated.  If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful.  If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security threats.

To find out more about Clearswift’s solutions please visit www.clearswift.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Wietse Venema
Nik Kostaras:
> Jun 22 17:30:26 postfix-outbound/smtp[27125]: 3wtnBB3Jr7z1Q67T: to=<[hidden email]>, relay=10.44.43.1[10.44.43.1]:25, delay=0.08, delays=0.02/0.03/0.03/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure)
>
> It reaches
> if (PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE)
>       RETRY_AS_PLAINTEXT;
>
> inside smtp_start_tls(), but the condition is false the first time because of the "PREACTIVE_DELAY >= var_min_backoff_time" clause of  PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE.

This is a security workaround for active attackers who aren't smart
enough to remove or modify STARTTLS in the EHLO response, but who
can still tamper with the TLS handshake.

Perhaps Viktor remembers what problem we were trying to solve.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Viktor Dukhovni
In reply to this post by Nikk
On Thu, Jun 22, 2017 at 06:14:08PM +0000, Nik Kostaras wrote:

> In one of my tests I'm configuring Postfix client (smtp) to use
> opportunistic TLS with TLSv1.2 protocol only

Don't do that.  See RFC7435.  Raising the floor on acceptable
cryptographic parameters often lowers security.  Instead raise the
ceiling allowing the peers to negotiate stronger algorithms.

> As expected the TLS handshake fails, but Postfix moves the message to
> deferred queue rather than retrying immediately in plaintext.

This avoids needless downgrade to cleartext when there's a transient
glitch during the TLS handshake.

> What is the reason of the timeout between the incoming_arrival and
> active_arrival (var_min_backoff_time) of a message, before the message is
> allowed to be immediately retransmitted?

Some MTAs (say Sendmail) don't downgrade to cleartext at all when
the peer purports to support STARTTLS.  Postfix gives the remote
MTA another chance to complete a TLS hanshake by deferring the
attempted delivery.  Not all STARTTLS failures are the result of
persistent incompatibility.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Claus Assmann-22
On Fri, Jun 23, 2017, Viktor Dukhovni wrote:

> Some MTAs (say Sendmail) don't downgrade to cleartext at all when
> the peer purports to support STARTTLS.  Postfix gives the remote

Just FYI: in sendmail 8.16 it's an option:

        To automatically handle TLS interoperability problems for outgoing
                mail, sendmail can now immediately try a connection again
                without STARTTLS after a TLS handshake failure.
                This can be configured globally via the option
                TLSFallbacktoClear or per session via the 'C' flag
                of tls_clt_features.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Message not retransmitted immediately after opportunistic TLS handshake failure

Nikk
In reply to this post by Viktor Dukhovni
Thanks VIktor, this verifies my suspicions.

I'm using the protocol mismatch to forcibly trigger a TLS handshake failure because I was too lazy to pick an invalid cipher.
Is there any value making this check optional with the use of a configuration parameter, to specify the expected minimum timeout (0 to disable the timeout check)?
If so I can send a patch for that.

Nik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Viktor Dukhovni
Sent: 23 June 2017 01:06
To: [hidden email]
Subject: Re: Message not retransmitted immediately after opportunistic TLS handshake failure

On Thu, Jun 22, 2017 at 06:14:08PM +0000, Nik Kostaras wrote:

> In one of my tests I'm configuring Postfix client (smtp) to use
> opportunistic TLS with TLSv1.2 protocol only

Don't do that.  See RFC7435.  Raising the floor on acceptable cryptographic parameters often lowers security.  Instead raise the ceiling allowing the peers to negotiate stronger algorithms.

> As expected the TLS handshake fails, but Postfix moves the message to
> deferred queue rather than retrying immediately in plaintext.

This avoids needless downgrade to cleartext when there's a transient glitch during the TLS handshake.

> What is the reason of the timeout between the incoming_arrival and
> active_arrival (var_min_backoff_time) of a message, before the message
> is allowed to be immediately retransmitted?

Some MTAs (say Sendmail) don't downgrade to cleartext at all when the peer purports to support STARTTLS.  Postfix gives the remote MTA another chance to complete a TLS hanshake by deferring the attempted delivery.  Not all STARTTLS failures are the result of persistent incompatibility.

--
        Viktor.

----------------------------------------------------------------------------------------------
Message Processed by the Clearswift V4 Engineering Dogfood Secure Email Gateway

This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated.  If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful.  If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security threats.

To find out more about Clearswift’s solutions please visit www.clearswift.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Message not retransmitted immediately after opportunistic TLS handshake failure

Viktor Dukhovni
On Fri, Jun 23, 2017 at 01:48:29AM +0000, Nik Kostaras wrote:

> Is there any value making this check optional with the use of a
> configuration parameter, to specify the expected minimum timeout (0 to
> disable the timeout check)?

I think that a brief delay for the tiny fraction of sites that
misadvertise STARTTLS is a feature not a bug.  So I don't think
there's a demonstrable need here for a configurable delay.

--
        Viktor.
Loading...