Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Can't enable SSLv3

(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 <mark.mielke@xxxxxxxxx> wrote:
Hi Thomas:

On Wed, Apr 15, 2015 at 8:29 AM, Thomas <jetty@xxxxxxxxx> 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 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.


Mark Mielke <mark.mielke@xxxxxxxxx>

Mark Mielke <mark.mielke@xxxxxxxxx>

Back to the top