[rfc][icedtea-web] https probing
helpcrypto helpcrypto
helpcrypto at gmail.com
Mon Sep 8 07:00:47 UTC 2014
Hi Jiri.
Should i apply/test this patch?
Does it solve my TLS problems?
Regards.
On Wed, Sep 3, 2014 at 4:04 PM, Jiri Vanek <jvanek at redhat.com> wrote:
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140908/f4384802/attachment.html>
More information about the distro-pkg-dev
mailing list