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
