[rfc][icedtea-web] https probing

Tue Aug 26 07:28:03 UTC 2014

I have some legacy servers here at work, which are having trouble with
Oracle Java 8 (with TLS1.1/2.0 enabled by default).

Is there any chance this issue is somewhat related to this? (i havent
tested this on Icedtea)

Will it help you if I test something? (Perhaps I'm able to reproduce
something)

On Tue, Aug 26, 2014 at 9:16 AM, Jiri Vanek <jvanek at redhat.com> wrote:

> 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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140826/c2daae9f/attachment.html>