[rfc][icedtea-web] https probing

[Jiri Vanek]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: httpsSolution_03.patch
Type: text/x-patch
Size: 40594 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140820/20f4b709/httpsSolution_03-0001.patch>