[rfc][icedtea-web] https probing

[Jacob Wisor]

On 08/18/2014 08:46 PM, Omair Majid wrote:
> Hi,
>
>
> * Jacob Wisor <gitne at gmx.de> [2014-08-11 12:12]:
>> On 08/08/2014 10:37 AM, Jiri Vanek wrote:
>>> Unluckily this fix patch is not helping obscure servers to do exists.
>>> It really fixes bugs.
>>>
>>> First part of fix is delivered to be able  handle SSLv2 handshake, Those servers
>>> do exists, and have no reason nor need to update or patch or whatever. We are
>>> wrong by not allowing it right now.
>>> See   System.setProperty("https.protocols", "SSLv3,SSLv2Hello"); in code.
>>
>> Oh yes they do need fixing. SSLv2 is insecure and has been revoked by the
>> IETF, period. Nobody should be using it. Even SSL 3.0 is deemed by the IETF
>> as historic (https://datatracker.ietf.org/doc/rfc6101) although it is
>> largely identical to TLS 1.0. Nevertheless, nobody should be using it
>> either. Just one of many reasons is that it does not even support such a
>> common hash algorithm as SHA1 (which by the way has been deprecated by NIST
>> in favor of SHA256 too). Everybody should really upgrade to at least TLS
>> 1.0, even though possible security leaks have been discovered in TLS 1.0 on
>> specific configuration settings permutations.
>>
>> DO NOT use SSL anymore and DO NOT promote them in your software. Upgrade to TLS.
>
> This isn't SSv2, though. It's a SSLv2 hello packet wrapping an SSLv3
> packet: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4915862
>
> It's actually part of the TLS 1.0 spec:
> https://www.ietf.org/rfc/rfc2246.txt, Appendix E.

This part describes backward compatibility of TLS 1.0 clients to SSL 3.0 and SSL 
2.0 servers (and vice versa).

"TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
    Version 2.0 client hello messages [SSL2]. TLS servers should accept
    either client hello format if they wish to support SSL 2.0 clients on
    the same connection port. The only deviations from the Version 2.0
    specification are the ability to specify a version with a value of
    three and the support for more ciphering types in the CipherSpec."

Currently, IcedTea-Web is a TLS 1.0 or SSL 3.0 client. According to this 
paragraph, TLS 1.0 clients send SSL 2.0 client hello messages in order to 
connect to SSL 2.0 servers, that is, to negotiate a SSL 2.0 connection. So no, 
SSL 2.0 servers do not upgrade automagically to TLS 1.0 when they receive SSL 
2.0 client hello messages from TLS 1.0 clients. Pure old SSL 2.0 servers will 
never speak anything later than SSL 2.0.

One reason behind this paragraph was for TLS 1.0 clients to allow probing SSL 
2.0 servers with cipher specifications in SSL 2.0 and those introduced in TLS 
1.0. In practice, SSL 2.0 servers will _never_ negotiate to a cipher 
specification introduced since TLS 1.0 because they were simply not built for that.

Another reason for this paragraph back in 1999 (!) was to allow implementors of 
TLS 1.0 to ease transition from SSL to TLS and to give them the option to merge 
TLS into their existing SSL libraries (or as much as possible build on top of 
them). Again, this has nothing to do with automagically upgrading SSL 2.0 
servers to TLS. It is just a description of how TLS 1.0 clients could fallback 
to SSL 2.0, if they wish to.
And, I am most certain nobody should want this, unless one has no clue what 
transport security is all about or is a complete lunatic.

The next paragraph says it all:

" Warning: The ability to send Version 2.0 client hello messages will be
            phased out with all due haste. Implementors should make every
            effort to move forward as quickly as possible. Version 3.0
            provides better mechanisms for moving to newer versions."

So, the Java API should have got rid of the option to fallback to SSL 2.0 years 
before. It's a shame that J2SE still supports SSL 2.0 connections in 2014. Why? 
Because this has nothing to do with compatibility but with *security*.

Jacob