Re: [TLS] Deprecating SSLv3

[Hubert Kario <[e-mail]>]

On Monday 24 November 2014 16:59:35 Martin Rex wrote:
> Hubert Kario wrote:
> > I've extended the scanner to try more fallbacks when testing (retry with a
> > much smaller client hello) and the stats for this month look like this:
> > 
> > Supported Protocols       Count     Percent
> > -------------------------+---------+-------
> > SSL2                      38835     8.7934
> > SSL2 Only                 100       0.0226
> > SSL3                      204062    46.2059
> > SSL3 Only                 2195      0.497
> > SSL3 or TLS1 Only         108575    24.5847
> > SSL3 or lower Only        2293      0.5192
> > TLS1                      438481    99.2856
> > TLS1 Only                 46428     10.5127
> > TLS1 or lower Only        143729    32.5447
> > TLS1.1                    281522    63.7453
> > TLS1.1 Only               25        0.0057
> > TLS1.1 or up Only         443       0.1003
> > TLS1.2                    292517    66.2349
> > TLS1.2 Only               337       0.0763
> > TLS1.2, 1.0 but not 1.1   13585     3.0761
> 
> How do TLS extension support fit into your picture?

I don't know.

That is: I'm using openssl command line binary (albeit with few changes, 
modifications and additions compared to upstream) and as such I don't believe 
I can send TLS1.0/1.1/1.2 Client Hello without extensions.

In other words, all those servers that report TLS1.0 as supported mean also 
support for typical extensions (server_name, curves, signature_algorithms, 
etc.). The amount of servers which are TLS extension intolerant and either 
have SSLv3 disabled or are V2 client hello compatible is under 0.1%.

What I have no idea about is the amount of servers that are V2 ClientHello 
*and* TLS-extension intolerant.

> Just a few days ago I was working on a customer message about interop
> problems with a Business-2-Business scenario, and the Server that is used
> seems to be an extensions-intolerant TLSv1.0 server.  The server is OK
> with ClientHello.client_version = { 3, 3 }, but when ClientHello includes
> any TLS extensions, it will abort with a fatal unexpected_message(10) alert.
> 
>  (the Website is http://www.elemica.com,
>    the service(s) are on https://preprod.connect.elemica.com:5443
>                      and https://connect.elemica.com:5443
>    authentication is by TLS client certificate, but you'll see the
>    TLS extensions intolerance by the fatal alert response to ClientHello.
> 
> > I think we can safely banish a protocol that only 0.5% of servers require
> > for interoperability.
> 
> Maybe you can, but I can not.  The support load would still be prohibitive.

In the case you're talking about you can connect using TLS1.0 without 
extensions, and while that is suboptimal in general it is allowed under 
current draft (and supported with TLS_FALLBACK_SCSV).

Anyway, you should file a complaint to the manufacturer that it haven't 
addressed the POODLE vulnerability in their product (or that it doesn't 
implement advertised protocols properly).
If you don't have a contract under which you can do that or can't change the 
TLS library yourself, you have much bigger problems anyway...
 
> > Regarding the SSLv3 MUST NOT: we have to remember that we're talking about
> > a security protocol *used* for security. In such context SSLv3 should not
> > be used.
> > 
> > Just like MD5 use for digital signatures is completely broken but is
> > completely fine to use it as a checksum to verify proper download of a
> > file
> > over internet (people use CRC32 for that!), use of SSLv3 for interop is
> > fine, but not if it is used for confidentiality.
> 
> You might not be aware of it, but there is only one TLS protocol version
> that allows digital signatures with md5WithRsaEncryption, and that is
> TLSv1.2.

yes, I am aware about that. Quite a few servers will in fact happily sign the 
key exchange with MD5. But that will happen only if the client advertises 
support for it (I did found 3 that will sign using only MD5 but I haven't 
checked if it's not a false positive). And most will fallback to either non 
(EC)DHE cipher or just force SHA1 on the client if it doesn't advertise RSA 
key signature algorithms.

-- 
Regards,
Hubert Kario