[rfc][icedtea-web] https probing
Jiri Vanek
jvanek at redhat.com
Fri Sep 12 11:26:47 UTC 2014
:(((
This patch is becoming blocker.
Any volunteer?
J.
On 09/10/2014 11:42 AM, Jiri Vanek wrote:
> ping?
>
>
> -------- Original Message --------
> Subject: Re: [rfc][icedtea-web] https probing
> Date: Wed, 03 Sep 2014 16:04:25 +0200
> From: Jiri Vanek <jvanek at redhat.com>
> To: Jacob Wisor <gitne at gmx.de>, distro-pkg-dev at openjdk.java.net
>
> On 08/26/2014 09:51 AM, Jacob Wisor wrote:
>> On 08/26/2014 09:16 AM, Jiri Vanek 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.
>> >
>> > + DeploymentConfiguration.KEY_HTTPS_PROBINGALOWED,
>> > [...]
>> > + public static final String KEY_HTTPS_PROBINGALOWED =
>> > "deployment.security.https.probing.alowed";
>> > [...]
>> > + public void disconect(URLConnection conn) {
>> > [...]
>> > + public synchronized void disconectHttps(HttpsURLConnection conn) {
>> > [...]
>> > + private final boolean unsecure;
>> > +
>> > + private HttpsSettings(boolean ssl2, boolean unsecure) {
>> > [...]
>> > + public static URLConnection openConnection(URL url, boolean ssl2,
>> > boolean unsecure) throws IOException {
>>
>> I am not testing this unless you have fixed your typos.
>> For god's sake, your are a programmer, right? You should know best that exact spelling is important.
>> Obviously, I am just talking till I am blue in the face.
>
> Noooo. I moreover overlooked :( Sorry.
>
> Now it should be as good as I'm able to do so without third party attendance.
>>
>> Also, please replace all occurrences of "ssl2" in text strings with "SSL2" (or "SSL 2.0" as used in
>> the specification). Acronyms of names are always upper case in English.
>>
>
> ok!
>>
>
>
> Here is updated version.
>
>
> Sorry for delay, I was hacking the documentation generator. Now its one (discussing with Lukas
> concurrently edited code), ad I think you will like it :)
>
>
> J.
>
>
>
>
>
More information about the distro-pkg-dev
mailing list