Re: [jetty-users] Enable SSLv3 in 9.2.10.v20150310

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Hi Mark,

Am 15.04.2015 um 00:52 schrieb Mark Mielke:

> Java 6 on
> Solaris defaults to the SSLv3 Hello,

Um, no. As you found out for yourself in your subsequent mail, the
default is using SSLv2-Hello, which is something different than the
statement that it defaults to SSLv3. Java 6 already supports TLSv1
so the removal of SSLv3 shouldn't lead to any problems at all if the
other side is capable of upgrading to TLS (which Java/Jetty is).

As you found out later, this was a bug in the JDK, which - by the
way - could have been solved by deactivating SSLv2-Hello on the
Solaris-side since Java 6 is also capable of using the newer
Client-Hello-formats in the TLS handshake as well.

> 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.

Concerning Jetty and the bad habit of changing the API of the classes
and therefor the format of the configuration files I agree with you
in a way but concerning SSLv3 I think you see it wrong. Google didn't
declare SSLv3 to be insecure but published a report showing flaws in
SSLv3 and the whole security community decided that the points are
valid and SSLv3 is considered to (finally) be dead because of this.

So immediately disabling SSLv3 in newer versions of products is a
Good Thing[TM] that everybody and their dogs were doing. Not all
things considered insecure are blocked immediately by default BTW.
TLSv1 and TLSv1.1 are still allowed by default despite the fact
that they are vulnerable to attacks like BEAST and CRIME.

> All change must be managed gracefully.

Not all changes can be done gracefully. Heartbleed and POODLE are
two examples where you can't wait for everybody to be ready for it,
since it impacted the security of data transfers and I can only
reiterate what I said in a previous mail: If you can only use
SSLv3 you can switch off SSL completely since there is essentialy
no difference in a plain connection and a SSLv3-"secured" one.

And: The change in the default wasn't forced on you. It was your
decision to update the Jetty Server making it your responsibility
to test for side effects, which brings us to

> 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...

This sounds like a manual testing process. You should consider
setting up testcases that do the testing for you, so you can't
miss a platform when doing changes. The name for this concept is
Continuous Delivery and there are quite some books out there
explaining the concept. You have to invest time to set it up
but it will save you a s***load of time in the long run (e.g.
when switching from Java 7 to Java 8 since Java 7 is EOL already
as well). BTDT for quite some time (the list of things breaking
when we switched from Java 6 to Java 7 was surprisingly long
and would never have been found with manual testing alone).

I'm in a quite similar situation as yourself giving support to
customers and be in the responsibility to make sure that updates
like the Jetty library doesn't break anything. But I think that
the difference between us is the mindset. If something breaks
after an update I don't blame the provider of the library for
doing updates but my lack of testcases rasing a flag that something
is breaking or my lack of concentration when reading through the
list of changes for the library's update.


Cheers, Lothar