[rfc][icedtea-web] https probing
Jiri Vanek
jvanek at redhat.com
Wed Sep 3 14:04:25 UTC 2014
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 --------------
A non-text attachment was scrubbed...
Name: httpsSolution_05.patch
Type: text/x-patch
Size: 39993 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140903/646d56d7/httpsSolution_05-0001.patch>
More information about the distro-pkg-dev
mailing list