[rfc][icedtea-web] https probing

[Jiri Vanek]

ping?

On 08/20/2014 08:30 PM, Jiri Vanek wrote:
> On 08/19/2014 11:25 PM, Jacob Wisor wrote:
>> 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*.
>>
>
> Ok. Thank you for patience with me. (really!)
>
> So there is another approach.
>
> Now the ssl2 is tested as last attempt, and if it is possible to connect like that, then the user is
> warned and error is thrown (which leads to skipping resource from that
>
>
> The not-checking certificate now can be allowed or forbidden by properties. By default it asks user
> by every such invalid certs its found. How to deal with human intraction is todo.
>
>
> The reason for this message is to get verbose logical error emsssage, not only "itw do not work again"
>
>
> What do you think now?
>
> J.
>