(Bleh... and Jetty 6.2.3 / 6.2.4 should be 9.2.3 / 9.2.4... more coffee required... and sorry for the noise...)
On Wed, Apr 15, 2015 at 9:49 AM, Mark Mielke <[email protected]> wrote: > Hi Thomas: > > On Wed, Apr 15, 2015 at 8:29 AM, Thomas <[email protected]> wrote: > >> first you do not mean SSLv3 Hello. Hello mean the even older SSLv2_Hello. >> This is called hello because the client does not support SSLv2 but >> support V2 >> Handshake Syntax. >> > > Yes, a minor mistake from memory that I already corrected... > > >> The next point is even java 6 can be configured to use only TLSv1. >> TLSv1 is not an state of the art technology like TLSv1.2 with AEAD cipher >> suites. >> This protocol is from 1999 for security this is really old. >> > > This was not the problem. In fact, when I wrote the code originally in > 2005, I specifically configured the cipher suite to use TLS 1.0 and only > TLS 1.0. However, at a later time, I determined that even TLS 1.0 was "too > old", and so why not let JavaSSE pick the right protocol for me? So, I > removed the enforcement, and let Java make the decision around 2010. This > decision seemed like a good one until January, 2015, when a patch upgrade > of Jetty 6.2.3 and Jetty 6.2.6 (I'm looking at my records now), to pick up > other fixes that I believe I was waiting for appeared innocent enough to > apply. I tested it on all the normal platforms and everything seemed great. > After deployment, Solaris 8 clients failed, because Solaris 8 is too old to > support Java 7... NOT because Solaris 8 is too old to support TLS 1.0. > > As I commented in my next post, it appears that this was really a Java > bug, in that the Java team provided a fix to allow the SSLv2 handshake to > proceed, in order to use TLS 1.0 or later, which should now work, but did > not work in January, 2015. > > >> >> I am not sure what cipher suites you are using but from my point i would >> say if the company >> use an cipher technology that is 16 years outdated they can as well use >> plain text. >> > > I'm not using "cipher technology that is 16 years outdated". I am using > Java 6u45 on Solaris 8, which although EOL and "old", is certainly not 16 > years old. > > It is not true that "you can as well use plain text." SSL/TLS provides > several features, and privacy is not the only one of extreme value. In my > case, I am also using it primarily for client authentication for > automation, which still works perfectly fine with SSLv2 handshake and TLS > 1.0+ encryption between a Solaris 8 client running Java 6 (because it > cannot use Java 7!), and a Linux server running Java 8. This is not "just > as well use plain text". Well, it worked perfectly fine until Jetty 6.2.3, > and which point.. > > > >> "All change must be managed gracefully. " >> >> Who long is gracefully in your mind ? If we are talking about security >> issues. >> - Days (required with CVE category 10 like Heartbleed) >> - Weeks (normally acceptalbe for patches) >> - Months >> - Years >> > > Gracefully means that a minor patch (6.2.3 => 6.2.4) probably shouldn't > suddenly encryption that has been working fine in production use for years. > But, even if it is an emergency, then there should be an escape hatch. It > shouldn't be the global expectation that people cannot receive any other > patches unless they also pick up a breaking patch. > > What happend since beginning of SSLv3 >> - RC4 broken >> - MD5 broken >> - SHA1 broken >> - CBC broken >> - Padding broken (V3 have no requirements) >> - 3DES broken (1/n-1 split) >> - Heartblead >> - Poodle >> - Export Suites broken >> - export suites, rc4 and other are already forbidden in TLSv1.2 some even >> in TLSv1.1 >> >> So an really clear point:* "**PRODUKTION + SSLv3 is an absolut NO-GO"* >> > > This is false. You may as well say that plain text is an absolut NO-GO. I > notice that www.eclipse.org is using plain text over http:// . Why is the > assumption so easily made that because a SSLv3 has weaknesses, therefore it > absolutely must be eliminated from all production possible today? This is a > "baby out with the bath water" type of conclusion. It's a knee jerk > reaction. > > The real conclusion should be that *new* installs should avoid use of > SSLv3, and old installs should plan a smooth migration out. What we're > really facing here is that people don't do smooth migrations very well, and > after so many years, it suddenly became popular over night due to a few new > exposures and bubbles of security being burst, that suddenly it became a > knee-jerk reaction to force the transition. > > In any case, all in all it's been pretty quiet. Only a few people got > broken (like me), and only in a handful of cases. So, all in all, I can't > ... and *didn't* complain. Please note that I hit my problem in January, > 2015, and it is now April before I am talking about it. What I'm really > responding to is the condescending "I know better than you" attitude that I > saw up for display here. You don't live in shoes and you cannot represent > me. Unless you know my entire circumstances, you should be careful about > making statements about what I should and shouldn't do. > > Thanks, > > -- > Mark Mielke <[email protected]> > > -- 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
