[rfc][icedtea-web] https proobing

[Lukasz Dracz]

Hello,

I don't have much experience with cryptography, but I do think this might be a good idea
to switch to TLS. I would like to point out one thing,

> release, possibly 1.6, should accept no less than TLS 1.0 connections only.
> Heck, actually we would need a patch which implements the opposite: No SSL
> 2.0
> and SSL 3.0 connections what so ever.

If we do decide to switch to TLS due to this POODLE vulnerability, then I think the no less
should be TLS 1.1 since TLS 1.0 is still vulnerable to POODLE according to this

https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/

Relevant part: 
 Note that TLS versions before 1.1 had similar padding-related vulnerabilities, which is why we recommend to switch to TLS 1.1, at least

Regards,
Lukasz Dracz

----- Original Message -----
> From: "Jacob Wisor" <gitne at gmx.de>
> To: distro-pkg-dev at openjdk.java.net
> Sent: Thursday, October 16, 2014 8:44:10 AM
> Subject: Re: [rfc][icedtea-web] https proobing
> 
> On 08/07/2014 at 07:25 PM, Jiri Vanek wrote:
> > Hi!
> >
> > this patch *should* solve most of the issues ITW have with various broken
> > or old
> > https servers. Should, because I have no page where to reproduce. My only
> > tracker is https://bugzilla.redhat.com/show_bug.cgi?id=1089130 and small
> > attached program which I wrote used to tests various requests to known
> > broken
> > https server (to get files).
> 
> I suppose this
> https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0
> and
> http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html
> makes the discussion about this patch obsolete. I am no cryptography expert,
> however I do have sufficient knowledge on this subject to strongly advise
> everybody who really cares about security to migrate to TLS. IMHO the next
> JDK
> release should definitely finally drop support for SSL 2.0 and SSL 3.0
> altogether. Yes, even when this means that things will break, or perhaps
> /because/ things break. Outdated and EOL applications which rely on transport
> security supporting SSL 2.0 or SSL 3.0 only should not run on newer versions
> of
> Java. It's simply irresponsible to allow this madness to continue. So called
> "legacy compatibility" is not an issue of compatibility but about forcing
> people
> to give up their security.
> Having said that, IcedTea-Web should not get on the wrong track either. The
> next
> release, possibly 1.6, should accept no less than TLS 1.0 connections only.
> Heck, actually we would need a patch which implements the opposite: No SSL
> 2.0
> and SSL 3.0 connections what so ever.
> 
> OpenJDK as well as Oracle's JRE currently enable users and administrators to
> configure the JRE to fallback all the way down to SSL 2.0. It may not be
> convenient to configure or unknown and difficult for inexperienced users but
> it
> is possible, which is bad enough in the light of recent discoveries. If
> somebody
> wants or needs to run software which relies on insecure connections should
> have
> been warned by now and be really sure about what they are doing.
> 
> Jacob
>