Not to recommend the use of SSLv3 by any means, but just to point out that there is a single case (of many) where I was forced to make a software change to migrate to SSLv3, and if making a software change is not feasible for some business reason, this would make it necessary to retain Jetty support for SSLv3 for such a person.
My single case was... I hope I get this right... Use of Jetty 9.2.x latest as a server, to a Java 6 client on Solaris 8. Java 7 is not available for Solaris 8. Solaris 8 is end-of-life, but the company I work for still has support contracts that stipulate that that the product will still still have support under Solaris 8. Java 6 on Solaris defaults to the SSLv3 Hello, and when I upgraded to Jetty 9.2.x latest from something like Jetty 9.2.1, everything worked fine except for the loadbuild machines support Solaris 8. Jetty 9 is being used as part of a web services frame work that is integrated with the loadbuild process. First, I backed out the server upgrade to a Jetty version that didn't block SSLv3. This bought breathing room. Then, I researched and figure this all out. I updated the client to a newer version of Apache HttpClient that *also* blocked SSLv3, which caused the client to use TLSv1 Hello by default, which then allowed me to update the server to latest Jetty 9.2.x. So, I'm not saying the change to Jetty was wrong. The default probably should be to block SSLv3. But, I think there can be an assumption made by people using latest technology, that everybody else can as well. Just because Google or some other company declares SSLv3 insecure, doesn't mean that it can be disabled without consequence. All change must be managed gracefully. I don't mind ripping the band-aid off, but there should be a way to let people purposefully keep the band-aid on a little longer if they need to. Now, maybe "stay on old Jetty" is an accept way to do this. But, it's still verging on imposing a general conclusion on every single situation out there, and that can result in pain for people. In my case, I didn't even realize there would be an impact and it was a production outage when it occurred. I did test all the common systems, but I missed testing Solaris 8... On Tue, Apr 14, 2015 at 1:02 PM, Thomas <[email protected]> wrote: > Hi, > > i hope you have really good reasons to enable SSLv3 the protocol is broken, > this is the reason that it is disabled in new JRE Version. > 1) RC4 is broken and obsoleted by an RFC > 2) CBC if also broken > 3) GCM is not available in SSLv3 and SSLv3 does not have padding > constraints. > So SSLv3 should only enable for protocol testing but NEVER for securing > data. > > Gruß Thomas > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Apr 2015 16:19:25 +0000 > From: "Grimm, Michael J (HPCS-R&D)" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [jetty-users] Can't enable SSLv3 in 9.2.10.v20150310 > Message-ID: > < > 41551cee2042a8479e4048be0e3b7a85a2b44...@g4w3231.americas.hpqcorp.net> > > Content-Type: text/plain; charset="us-ascii" > > FYI. > I found the problem was NOT with Jetty, but rather with the new JRE I'm > using. > In Java1.8_u31, SSLv3 is disabled. > You can see this in: > jre/lib/security/java.security - jdk.tls.disabledAlgorithms=SSLv3 > > When I deleted that property and restarted my application, Jetty was able > to use SSLv3. > > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Mark Mielke <[email protected]>
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
