Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
On 15/10/18 20:41, Viktor Dukhovni wrote: > On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote: > >>> What do you make of the >>> idea of making it possible for servers to accept downgrades (to some >>> floor protocol version or all supported versions)? >> >> I'm really not keen on that idea at all. > > I understand the healthy skepticism, but it may worthwhile to keep > in mind that for SMTP the consequence of not accepting fallback to > TLS 1.2, is accepting fallback to cleartext! So protocol downgrade > protection looks somewhat silly. > > The only counter-argument I can think of is that some clients in > fact do mandatory authenticated TLS (e.g. with DANE, MTA-STS or > local policy), and they will not fall back to cleartext. On the > other hand, no MTA I know of does attempts (valid) browser-style > protocol fallback after a connection failure. So the clients that > insist on security (Postfix, Exim, ...) just defer the mail when > the TLS handshake fails. > > In the SMTP ecosystem enforcing FALLBACK_SCSV is pretty much > counter-productive (only reduces security to cleartext for opportunistic > clients, and does not at all help non-opportunistic clients get > through to servers that don't support TLS 1.3, and fail the handshake > if you try). > I think we should do more to understand the current problem before going any further down this route. If this is caused by pre6 or below OpenSSL clients then I don't think we should be making any changes to accommodate them. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote: > > What do you make of the > > idea of making it possible for servers to accept downgrades (to some > > floor protocol version or all supported versions)? > > I'm really not keen on that idea at all. I understand the healthy skepticism, but it may worthwhile to keep in mind that for SMTP the consequence of not accepting fallback to TLS 1.2, is accepting fallback to cleartext! So protocol downgrade protection looks somewhat silly. The only counter-argument I can think of is that some clients in fact do mandatory authenticated TLS (e.g. with DANE, MTA-STS or local policy), and they will not fall back to cleartext. On the other hand, no MTA I know of does attempts (valid) browser-style protocol fallback after a connection failure. So the clients that insist on security (Postfix, Exim, ...) just defer the mail when the TLS handshake fails. In the SMTP ecosystem enforcing FALLBACK_SCSV is pretty much counter-productive (only reduces security to cleartext for opportunistic clients, and does not at all help non-opportunistic clients get through to servers that don't support TLS 1.3, and fail the handshake if you try). -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
On 15/10/18 18:54, Viktor Dukhovni wrote: > > >> On Oct 15, 2018, at 9:19 AM, Matt Caswell wrote: >> >>> Early, partial reports of the cause seem to indicate that the sending >>> side was using OpenSSL with: >>> >>> SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV); >>> >>> seemingly despite no prior handshake failure, >> >> Are you sure about the "no prior handshake failure" bit? If they were >> using pre6 or below then if they attempt TLSv1.3 first it will fail >> (incorrectly - it should negotiation TLSv1.2 see issue 7315). The >> fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be >> reasonable. > > No, not sure at all, but that's what the receiving system administrator > tells me the sending system administrator told him. Perhaps they failed > to understand the docs, and always set the fallback bit. MTAs tend to > not do complex fallback, just send in the clear if opportunistic TLS > fails, or try later and hope things work out better then. > > I've not yet received further corroboration. What do you make of the > idea of making it possible for servers to accept downgrades (to some > floor protocol version or all supported versions)? > I'm really not keen on that idea at all. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
> On Oct 15, 2018, at 9:19 AM, Matt Caswell wrote: > >> Early, partial reports of the cause seem to indicate that the sending >> side was using OpenSSL with: >> >> SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV); >> >> seemingly despite no prior handshake failure, > > Are you sure about the "no prior handshake failure" bit? If they were > using pre6 or below then if they attempt TLSv1.3 first it will fail > (incorrectly - it should negotiation TLSv1.2 see issue 7315). The > fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be > reasonable. No, not sure at all, but that's what the receiving system administrator tells me the sending system administrator told him. Perhaps they failed to understand the docs, and always set the fallback bit. MTAs tend to not do complex fallback, just send in the clear if opportunistic TLS fails, or try later and hope things work out better then. I've not yet received further corroboration. What do you make of the idea of making it possible for servers to accept downgrades (to some floor protocol version or all supported versions)? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
On 12/10/18 16:50, Viktor Dukhovni wrote: > On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote: > >> I would guess that the misbehaving clients are early openssl betas >> that receive the real TLS 1.3 version and then try to interpret >> as whatever draft versino they actually implemnet. > > Early, partial reports of the cause seem to indicate that the sending > side was using OpenSSL with: > > SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV); > > seemingly despite no prior handshake failure, Are you sure about the "no prior handshake failure" bit? If they were using pre6 or below then if they attempt TLSv1.3 first it will fail (incorrectly - it should negotiation TLSv1.2 see issue 7315). The fallback to TLSv1.2 with SSL_MODE_SEND_FALLBACK_SCSV set would then be reasonable. Matt > this is of course > fatally wrong. But my question remains, should/could we provide a > control that ignores fallback signals from clients, and keeps going? > Either regardless of the resulting protocol version, or perhaps if > it is at least some acceptable floor? > > That way, applications like MTAs that do opportunistic TLS, could > keep going with TLS 1.2, since failing to negotiate TLS will typically > result in downgrade to cleartext, rather than protection from TLS > version downgrades. Such a mechanism might also make it possible > to support connections from a small fraction of broken clients, > without disabling TLS 1.3 globally. > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote: > I would guess that the misbehaving clients are early openssl betas > that receive the real TLS 1.3 version and then try to interpret > as whatever draft versino they actually implemnet. Early, partial reports of the cause seem to indicate that the sending side was using OpenSSL with: SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV); seemingly despite no prior handshake failure, this is of course fatally wrong. But my question remains, should/could we provide a control that ignores fallback signals from clients, and keeps going? Either regardless of the resulting protocol version, or perhaps if it is at least some acceptable floor? That way, applications like MTAs that do opportunistic TLS, could keep going with TLS 1.2, since failing to negotiate TLS will typically result in downgrade to cleartext, rather than protection from TLS version downgrades. Such a mechanism might also make it possible to support connections from a small fraction of broken clients, without disabling TLS 1.3 globally. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FYI: [postfix & TLS1.3 problems]
I would guess that the misbehaving clients are early openssl betas that receive the real TLS 1.3 version and then try to interpret as whatever draft versino they actually implemnet. -Ben On Thu, Oct 11, 2018 at 01:18:03PM -0400, Viktor Dukhovni wrote: > > Apparently, some SMTP clients set fallback_scsv when doing TLS 1.2 > with Postfix servers using OpenSSL 1.1.1. Not yet clear whether > they tried TLS 1.3 first and failed, or just sent the SCSV out of > the blue... > > See attached. If this is a common problem, it might be useful to > have a control that tolerates "downgrade" to TLS 1.2, without > disabling TLS 1.3 support. In many cases, and especially opportunitistic > security, where STARTTLS can be stripped by an MiTM entirely, so > we often can't even prevent downgrades to cleartext, TLS 1.2 is > quite good enough. > > -- > Viktor. > Date: Thu, 11 Oct 2018 12:53:38 -0400 > From: Viktor Dukhovni > To: postfix-us...@postfix.org > Subject: Re: postfix & TLS1.3 problems > User-Agent: Mutt/1.10.1 (2018-07-13) > > On Thu, Oct 11, 2018 at 05:54:59PM +0200, A. Schulze wrote: > > > today I noticed a significant amount of TLS failures in my postfix log. > > > > Oct 11 17:43:35 mta postfix/smtpd[23847]: SSL_accept error from > > client.example[192.0.2.25]:34152: -1 > > > > I traced some sessions and found the problematic client is announcing > > the special cipher "TLS_FALLBACK_SCSV" > > in a TLSv1.2 ClientHello message. Now, as my server support TLSv1.3, > > my SSL library (openssl-1.1.1) assume a downgrade attack an close the > > connection with an SSL error message "inappropriate fallback" > > > > The core issue is a client with a nonconforming TLS implementation. > > Any idea what software these clients are running? Are they at all > likely to fix this any time soon? > > > To circumvent the problem I tried to disable TLS1.3 on my server by setting > > smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1.3 > > > > But that does not help. > > The Client still fail an deliver the message by falling back to plain text > > :-/ > > > > The only option to force encrypted traffic again would be a library > > downgrade on my side. > > Any other suggestions? > > Support for OpenSSL 1.1.1 and TLS 1.3 is on the list of fixes slated > for Postfix 3.4, and some may then be backported to patch levels > of earlier releases. > > In the meantime, try: > > tls_ssl_options = 0x2000 > > which corresponds to SSL_OP_NO_TLSv1_3. I am not aware of any > method to accept the "downgrade" to TLS 1.2 without disabling TLS > 1.3 for clients that do have correct implementations. > > -- > Viktor. > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
