Re: [jetty-users] Can't enable SSLv3

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 15.04.2015 um 15:49 schrieb Mark Mielke:

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

With SSLv3, it is not much more than plain text or - if you want
a better fitting example - WEP. As long as you haven't disabled
SSLv3 a man in the middle attack can be performed leading to a
downgrade to SSLv3 between two peers allowing you to eavesdrop
that session.

> Gracefully means that a minor patch (6.2.3 => 6.2.4)

Just because the third part of the version number changes doesn't
imply a "minor" patch but a patch of the 9.2-line of Jetty, containing
any number of fixes from typos up to major flaws.

> probably shouldn't
> suddenly encryption that has been working fine in production use for
> years.

No encryption was disabled but a protocol version that was
considered insecure for a decade and being completely broken
last year.

If a protocol version, a cipher or other security relevant
parts are broken they always are removed from production
systems sooner than later since they have no relevance
for that anymore. Examples are MD5 for CA signatures, RC4,
DES, WEP, The NSA random generators, etc.

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

SSLv3 wasn't removed completely but taken off the default list
of protocol versions to be used. So it's still not impossible
to use SSLv3, but really not recommended for something outside
a testlab.

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

There is a difference between obvious plain text and the simulation
of security by using SSLv3/WEP/DES/RC4/ROT13/...
Plain text makes it obvious to the user that everybody can read
what is transfered, SSLv3 gives these users the impression that
everything is secure where it isn't (same with desktop firewalls
but I'm not going to open that can of worms here ;-)

> I notice that www.eclipse.org <http://www.eclipse.org> is using plain
> text over http:// .

And if you log in, you and everybody else can read your credentials.
If you use https://www.eclipse.org and the server were using SSLv3
this fact doesn't change but you will get the "everything's fine"-
lock symbol in the address bar (unless your browser doesn't see
SSLv3 as secure and warns you).

> Why is the assumption so easily made that because
> a SSLv3 has weaknesses,

It's _broken_. It was considered weak and on the brink of being
broken for the last 10 years. The grace-period you are demanding
was the last decade; it doesn't start now.

> therefore it absolutely must be eliminated from all production
> possible today?

A definite yes. It's in the same league as all the other algorithms
and protocols I listed above. Other vulnerabilities like BEAST,
CRIME, ... are bad as well but harder to exploit (especially if
no browser is involved) so there is no immediate need for action
at the moment, so if somebody on this list asks how to configure
a JVM to disable the new default TLSv1.2 in Java 1.8, I'd happily
point to the relevant System-property.

> This is a "baby out with the bath water" type of conclusion.

No.

> It's a knee jerk reaction.

No.

BTW: If you were using NQ Vault and have read
https://ninjadoge24.github.io/#002-how-i-cracked-nq-vaults-encryption
do you also think that deciding to deinstall NQ Vault from
your device is a knee jerk reaction?

> The real conclusion should be that *new* installs should avoid use
> of SSLv3,

Concerning the conclusion: No, everybody should stop using it.
Concerning the word "avoid": Are you kidding me? It's *broken*

> and old installs should plan a smooth migration out.

No, the issue should be addressed immediately and with the highest
priority possible. Reenabling SSLv3 is possible, so you can
keep your particular system running until you addressed the issue
the week after.

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

Sorry but you take the whole issue too easy. Not all security
weaknesses are a "all hands on deck"-situation like Heartbleed,
RogueCA or the DNS cache poisoning vulnerability of 2008.
But POODLE/SSLv3 is.

The reason why so many "bubbles" are coming up lately is that
companies like Google are taking money in their hands to do
an audit of the open source software that is the basis of our
digital economy. So instead of complaining that "Google
declares something being insecure" we should be
grateful that they are doing what should have happened a
decade ago. Their effort among others revealed Heartbleed,
POODLE, the fact, that Diginotar was completely 0wned and
that sqlite has many flaws (still waiting to be exploited)

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

Oh, I had my own share of cases. An example: After the update
connections to SAP BusinessConnector-installations failed.
Reason is that they were being installed with the shipped
CD instead of the binary being downloaded from their site.
The version on the CD is US-export-restricted only allowing
symmetric keys up to 40 Bit. With our new version we removed
these insecure ciphers leading to the problem.

I told them the same thing as I told you or Michael, that
they should switch to plain text communication because a
40-bit-secured connection is esentially the same. The
communication now works again (without my customer re-
enabling 40-bit symmetric keys).

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

I assume that this is pointed in my direction ;-)

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

This is a mailing list with volunteers answering questions
for free. You're not my boss and you're not my customer and
even if you were I still would tell you that the use of SSLv3 is
a bad idea and you shouldn't use it so that there must be a
good reason why you still need it (i.e. the actual smell of
your shoes you live in). Your users might be my users as well
and I don't want to expose them to insecurity and be it
indirectly by helping you (or others) to do it.


Cheers, Lothar