Subject: [TLS] Prohibiting SSL 3.0

From: Yuhong Bao <[email-masked]>
Date: Mon, 27 Oct 2014 19:05:41 -0700

I hope that a Internet-Draft prohibiting SSL 3.0 will be next. Maybe make an exception for things like browser download sites (it is easy to enable TLS 1.0 in IE6 but for these kind of sites it is probably not worth the effort).

Yuhong Bao

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 19:43:12 -0700

> I hope that a Internet-Draft prohibiting SSL 3.0 will be next. Maybe make an exception for things like browser download sites (it is easy to enable TLS 1.0 in IE6 but for these kind of sites it is…

It didn't meet the deadline, but Richard and I put something together.

https://unicorn-wg.github.io/sslv3-diediedie/

But then we learned that there might be another draft.  That other
draft is probably better.  Not sure if this one is worth doing or not.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 28 Oct 2014 12:19:48 +0100

* Yuhong Bao:

> I hope that a Internet-Draft prohibiting SSL 3.0 will be next.

RFC 6101 already has status “HISTORIC”.  I'm not sure what else the
IETF can do.  The cryptographically protected version negotation means
that there is no actual harm in supporting SSL 3.0 along with TLS.
(Same for supporting earlier TLS versions.)

---

From: Hubert Kario <[email-masked]>
Date: Wed, 29 Oct 2014 11:43:58 +0100

> (Same for supporting earlier TLS versions.)

Even the TLS 1.3 draft says that a client SHOULD NOT send a SSLv2 compatible 
client hello with server support being stated as MAY. Similarly, the value for 
SSL 3.0 for record layer in client hello is mentioned as the backwards 
compatible option with no mention of recommendation against it.

I'd say an RFC that updates them to a MUST NOT/SHOULD NOT (respectively for 
SSLv2 and SSLv3, at the very least) is not entirely out of scope...

-- 
Regards,
Hubert Kario

---

From: Florian Weimer <[email-masked]>
Date: Wed, 29 Oct 2014 12:18:58 +0100

> SSLv2 and SSLv3, at the very least) is not entirely out of scope...

I think the SSLv2 compatible client hello is unrelated to the protocol
version advertised by the client, but I might be mistaken about that.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 29 Oct 2014 12:30:09 +0100

> version advertised by the client, but I might be mistaken about that.
Unless I'm mistaken, there is no point for a client to send a SSLv2 compatible
ClientHello unless the client is prepared to actually negotiate SSLv2. If think
if fair to say that client MUST NOT do that.

OTOH, accepting an SSLv2 ClientHello on the server makes sense even if the
server will never negotiate SSLv2. So I guess the MAY here is ok.

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 29 Oct 2014 12:37:38 +0100

> > I hope that a Internet-Draft prohibiting SSL 3.0 will be next.

The UTA BCP I-D has that (
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-05), although not
everything is in scope.

> IETF can do.

I agree, but see RFC 6176 for precedent.

Bodo

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 29 Oct 2014 12:51:47 +0100

> server will never negotiate SSLv2. So I guess the MAY here is ok.
... which is exactly what RFC 6176 says (thanks Bodo for mentioning it, I
totally forgot about it). So maybe the TLS 1.3 draft should just be updated to
refer to RFC 6176 here?

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Wed, 29 Oct 2014 21:43:11 +0100 (CET)

>> version advertised by the client, but I might be mistaken about that.

Correct.  You can negotiate TLSv1.2 on a connection that is started
with a SSL VERSION 2.0 CLIENT-HELLO.

>
> Unless I'm mistaken, there is no point for a client to send a SSLv2
> compatible ClientHello unless the client is prepared to actually
> negotiate SSLv2. If think if fair to say that client MUST NOT do that.

You might be surprised just how much crap (as servers) got shipped into
the installed base, and what turns out to be the most suitable workaround
to interop with those.

The problem with SSLv3 & ClientHello protocol version negotiation is
that a number of servers totally goofed the implementation, and a number
of clients (pretty much all browsers) followed suit.

The issue with TLS protocol version negotiation is that the SSLv3&TLS record
layer uses a "protocol_version" tag in the record layer PDU that indicates
_the_record_layer_PDU_encoding_, and when an initial ClientHello
is received on a new connection, there is also a ClientHello.client_version
field included.  A number of broken servers screwed up the protocol
version negotiation (which is performed EXCLUSIVELY through
ClientHello.client_version) by choking on the record layer PDU encoding
protocol_version when it differs from ClientHello.client_version.

Now the advantage of the SSL VERSION 2.0 CLIENT-HELLO is that it comes
with only a single protocol version -- and it seems that less server
implementors got that wrong.

> server will never negotiate SSLv2. So I guess the MAY here is ok.

We already settled the SSLv2 ClientHello issues.

http://tools.ietf.org/html/rfc6176#section-3

-Martin

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 29 Oct 2014 22:02:26 +0100

On 29/10/2014 21:43, Martin Rex wrote:
> [...]            A number of broken servers screwed up the protocol
Ok, I didn't know, thanks for the info.

> http://tools.ietf.org/html/rfc6176#section-3
Yes, I'd forgotten that until Bodo mentioned it.

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Fri, 31 Oct 2014 02:03:10 +0100 (CET)

Yuhong Bao wrote:
> Maybe make an exception for things like browser download sites
> (it is easy to enable TLS 1.0 in IE6 but for these kind of sites
>  it is probably not worth the effort).

No, why?

This may be unknown to you, but SSLv3 is still perfectly safe to use
within its stated design goals.  Even within the Design Goals stated
for TLSv1.2!

Remember the TLSv1.2 product warning label:

  https://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

And recap the stated properties of the protocol:

  https://tools.ietf.org/html/rfc5246#appendix-F

  https://tools.ietf.org/html/rfc5246#appendix-F.2

TLS up to and including TLSv1.2 similar to its predecessor SSLv3
*NEVER* *EVER* promised to provide any protection against attacks
such as BEAST, CRIME, Poodle or the RC4-attacks.  All of these
attacks have the prerequiste of almost full control over the behaviour
of an endpoint.  Remove the control-over-the-endpoint from these
attack scenarios, and none of these attacks will be possible anymore.

Btw. when I just did online-banking a few hours ago, I noticed
a longer numeric "token" variable at the end of the URL that changed
with every mouseclick and navigation on the page.  Seems like someone
properly realized that the root of all evil is applications on top
of TLS using disclosing authentication schemes.

Poodle targets the final block of CBC padding, and has an "efficiency"
of recovering 1 byte of plaintext per 256 TLS sessions during which
the server encounters 255 MAC errors on the app data (something that
normally occurs one per week or less).
As such Poodle looks like an extremely "noisy" attack to me.

The plaintext pattern that Poodle is trying to achieve for the final
CBC block of an SSL record looks like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 07
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 0F

Does anyone remeber Serge Vaudenay's original problem as a result from
the incorrect ordering of pad and mac in the SSL GenericBlockCipher
PDU processing, i.e.
the use of the unsafe "mac + pad + encrypt"
rather than a safe "pad + mac + encrypt":

       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau01
       http://lasec.epfl.ch/php_code/publications/search.php?ref=Vau02a

Didn't the the plaintext pattern that Vaudenay suggested in trying to
achieve for the final CBC block look like this:

       64-bit blockcipher (DES, 3DES, IDEA)
                 XX XX XX XX XX XX XX 00
      128-bit blockcipher (AES, CAMELIA, SEED, CAST):
                 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00

I can not see much of a difference between original Vaudenay and Poodle,
and the efficieny is exactly the same: plaintext recovery of 1 byte per 256
TLS sessions.

Just that the TLS WG actually *NEVER* followed Vaudenay's advice
by moving to "pad + mac + encrypt", which would have reliably
thwarted Lucky thirteen and Poodle.

If there was ever reason to "Panic", this was back in 2001 when the
problem was first described.  IMHO.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 30 Oct 2014 18:56:19 -0700

>   https://tools.ietf.org/html/rfc5246#appendix-F.2

Those sources say TLS provides a secure channel. Maybe that means
something different to you then me, but to me that means
INT-PTXT+IND-CCA2, aka "looks like a wire strung between the
machines", aka "I can do what I want, and an attacker will have no
hope". Or was this warning intended to be "don't trust this with
anything important, because it can bite"?

Your reading amounts to saying, that because TLS is insecure, the
provided properties are empty, and that's fine. I think most people
would disagree with that assertion, especially given the detailed
enumeration of security properties following that quote.

> attack scenarios, and none of these attacks will be possible anymore.

So TLS wasn't designed to satisfy standard security properties?
Browsers were never intended to run Javascript?

This seems like an argument for replacing TLS with something secure.

> of TLS using disclosing authentication schemes.

No, the root of all evil is hiring a biology student for a summer to
make a security protocol. It's a miracle SSLv3 works at all, showing
that the Lord protects drunks, fools, and interns.

(Also, that's for CSRF protection. The authentication is probably by a
cookie, and if that cookie is stolen, the CSRF protection doesn't stop
an attacker from going to the login form, which checks that the user
is logged in and kaboom. Changing authorization cookies shouldn't be
necessary: the only reason you are proposing it is that SSL v3 fails
to provide necessary security properties.)

> As such Poodle looks like an extremely "noisy" attack to me.

Okay, so the server logs the MAC errors, and then what happens? And
why should I have to watch the logs to ensure that I'm not being
attacked when I turned on SSL? It's secure ainit?

> and the efficieny is exactly the same: plaintext recovery of 1 byte per 256

Yes, Bodo Moeller and I already noted this in several emails to
various mailing lists, Kenny Paterson said this on Twitter, etc.

> thwarted Lucky thirteen and Poodle.

They also didn't follow the advice of everyone else to encrypt then
mac, which would have fixed it. Furthermore, we did finally publish an
encrypt then MAC draft, which also fixes the problem, about 13 years
later.

> problem was first described.  IMHO.

So why don't we fix it now? And why didn't you discover it yourself,
or propose a fix then? Every single time we've tried to solve
problems, you've insisted that they are really the user's problem. And
when these problems are rediscovered, you now argue we should have
fixed them the first time, and that we didn't shows how unimportant
they are, even when they steal someones money live on stage as a
demonstration.

In fact, you've even gone so far as to claim issues you thought were
security flaws when you discovered them, weren't. What's the goal
here? To get the WG to give up and never change the protocol ever
again?

Sincerely,
Watson Ladd

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Fri, 31 Oct 2014 03:31:39 +0100 (CET)

> anything important, because it can bite"?

To me, the second sentence of Appendix F:

   This document makes several traditional assumptions, including that
   attackers have substantial computational resources and cannot obtain
   secret information from sources outside the protocol.

says pretty clearly that TLS is not designed to provide protection from
an attacker who can gain almost full control over one of the communication
endpoints and can exploit this to get data of his own liking and data
that the attacker would like to discover mixed according to the attackers
choice with attacker supplied data and sent over the very same TLS-protected
communication channel.

An attack which I would consider scary is one that works like an
attack against the OpenSSL CVE-2014-0224 out-of-sequence ChangeCipherSpec
implementation bug (which is not a protocol defect, mind you).

When one of the 80 million affected andoid clients (smartphones, tablets)
talks to a still-vulnerable server, then a pure network-MitM attacker
(with ZERO control over the endpoint) can get in between the two,
read and modify the entire communication in both directions to his
own liking, and neither communication will notice anything unusual
or be aware that this attack ever happened.  no errors, no unusual
delays, no additional load, no failed requests, no repeated requests
no downgrades.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 30 Oct 2014 20:12:09 -0700

> choice with attacker supplied data and sent over the very same TLS-protected

Surely one traditional assumption is that an attacker can create
messages of his own and get them inserted into the stream?  Including
the possibility of intentionally causing a lot of traffic?

I'm fairly sure that one of the tactics used in WW2 to get 'cribs' to
break ENIGMA was to intentionally do things that would cause the enemy
to send a message with known contents, like sending an apparently
valuable target within vision of a U-boat that could not attack it, in
the hope the U-boat would report.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 30 Oct 2014 20:39:48 -0700

> choice with attacker supplied data and sent over the very same TLS-protected

So SSL v3 was not intended for use with browsers, despite being
developed by Netscape for use in browsers? And later versions were
also not for use in browsers? And despite the fact that TLS 1.1 fixed
bugs in TLS 1.0 that were only exploitable through doing the very
thing you insist TLS wasn't designed to handle, TLS 1.1 wasn't
designed to work in browsers either? Isn't this an argument that
browsers should not use SSL v3, and servers shouldn't either?

Is this argument leading to "let's make a protocol that works for
browsers"? Or is it leading to "let's not use browsers"?

> delays, no additional load, no failed requests, no repeated requests

What makes you think that noisy attacks get noticed and stopped?

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 31 Oct 2014 14:15:33 +0100

Watson Ladd <[email-masked]>:

> that the Lord protects drunks, fools, and interns.

I don't think that's fair to Paul Kocher; see also
https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf
for a protocol analysis done by people that I think don't have a biology
background. (Was Paul an intern or a paid consultant at that time? I
thought the latter [cf.
http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kocher:Paul_C=]. He'd
been a consultant to RSA Data Security before, although the only thing I
seem to remember about his work at that time was that he found not much
wrong with RC4.)

It seems pretty safe to say that Phil Rogaway would have been able to spot
additional problems and improve the SSL 3.0 protocol, but this was years
before there was a systematic understanding of many of the relevant
concepts. Chosen-ciphertext attacks were a thing, but "authenticated
encryption" was unheard of. This was even before
http://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf.

Bodo

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 07:15:04 -0700

On Oct 31, 2014 6:18 AM, "Bodo Moeller" <[email-masked]> wrote:
> I don't think that's fair to Paul Kocher; see also https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf for a protocol analysis done by people that I think don't have a biology background. (Was Paul an intern or a paid consultant at that time? I thought the latter [cf. http://www.informatik.uni-trier.de/~ley/pers/hd/k/Kocher:Paul_C=]. He'd been a consultant to RSA Data Security before, although the only thing I seem to remember about his work at that time was that he found not much wrong with RC4.)

Paul Kocher did invent side channel analysis a few years later.
Contrast TLS response to protocol flaws to that of IPsec: The first
round of IPsec was terrible. So a second version was developed, which
was much better and is widely used today. By contrast, the improved
version of SSL v3 wasn't, and each successive version never fully
addressed the security issues.

>
> It seems pretty safe to say that Phil Rogaway would have been able to spot additional problems and improve the SSL 3.0 protocol, but this was years before there was a systematic understanding of many of the relevant concepts. Chosen-ciphertext attacks were a thing, but "authenticated encryption" was unheard of. This was even before http://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf

You're understating the degree of knowledge at the time, and
overstating the extent to which open questions needed to be answered
to see that SSL v3 was flawed. Again, read what Rogaway said about
IPsec, and ask "did this apply to SSL?"

No one would have caught the decryption oracle in PKCS 1.5 or
renegotiation, or Triple Handshake at the time. But all the attacks
we're discussing rely on record layer choices that were known at the
time they were made to have secure alternatives. Was the Rogaway IPsec
comment document not written in the 1994-1995 period?

The question is not why SSL v3 got it wrong. The question is why we
didn't get it right a few years later, and stop using broken
protocols. You wrote in 2004 that one byte could be extracted from a
SSL v3 ciphertext, thus breaking confidentiality completely. Yet it's
not until 2014 that this actually leads to action on depreciating SSL
v3.

Sincerely,
Watson Ladd

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 31 Oct 2014 15:24:52 +0100

You're understating the degree of knowledge at the time,

I don't think so. My intent was to highlight the difference between "known
at the time" and "widely known among experts at the time". As I pointed
out, you didn't have to be a biology major at the time to miss the
("known") problems.

> didn't get it right a few years later

These both are (different) questions. I had commented on your comments on
the former.

Bodo

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 07:39:11 -0700

On Fri, Oct 31, 2014 at 7:24 AM, Bodo Moeller <[email-masked]> wrote:
> at the time" and "widely known among experts at the time". As I pointed out,
> you didn't have to be a biology major at the time to miss the ("known")
> problems.

Are you suggesting that Rogaway was the only person who knew that
Encrypt then MAC was correct? I'd have to do a fairly extensive
archive crawl, but I highly doubt this: mathematicians are good at
communicating. In fact, I think most if not all of the researchers in
the field would have known this. But it's very hard to go back and
check.

---

From: Sean Turner <[email-masked]>
Date: Fri, 31 Oct 2014 13:12:16 -0400

> that the Lord protects drunks, fools, and interns.

Watson,

Please cease with the personal attacks.  As this is not the first time [0] you’ve been publicly ask you to stop, I have consulted with the AD and next time you engage in a personal attack you will be banned from the list for a period not to exceed 30 days [1].

J&S (as WG chairs)

[0] http://www.ietf.org/mail-archive/web/tls/current/msg12146.html
[1] http://datatracker.ietf.org/doc/rfc3934/

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 31 Oct 2014 10:17:29 -0700

SSL 3.0 is historic, but if but if someone wants to write a draft
prohibiting SSL 3.0 the working group can consider adopting it.  We are
closing down this thread since it has diverged off topic.

J&S (as WG chairs)

On Fri, Oct 31, 2014 at 10:12 AM, Sean Turner <[email-masked]> wrote:

> Please cease with the personal attacks.  As this is not the first time [0]
> you’ve been publicly ask you to stop, I have consulted with the AD and next
> time you engage in a personal attack you will be banned from the list for a
> period not to exceed 30 days [1].
>
> J&S (as WG chairs)
>

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 31 Oct 2014 10:55:32 -0700

> not until 2014 that this actually leads to action on depreciating SSL
Ah, back in 2004 most browsers still comes with SSLv2 enabled by default.TLS 1.0 was barely five years old.IE6 was the dominant browser and it came with TLS 1.0 disabled by default.It wasn't until late 2006 that Firefox 2.0 and IE7 was released that disabled SSLv2.SSLv2 had much worse security flaws than SSLv3 did.
Yuhong Bao

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Oct 2014 21:04:35 +0200

> On Oct 31, 2014, at 7:55 PM, Yuhong Bao <[email-masked]> wrote:
> 
> SSLv2 had much worse security flaws than SSLv3 did.

Other than the downgrade attack by a MITM, what else?

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 31 Oct 2014 16:47:00 -0700

> Other than the downgrade attack by a MITM, what else?

"Differences Between SSLv2, SSLv3, and TLS",
http://yaksman.org/~lweith/ssl.pdf. There's three or four pages of
problems enumerated by Weith.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 1 Nov 2014 06:55:17 +0200

> On Nov 1, 2014, at 1:47 AM, Jeffrey Walton <[email-masked]> wrote:
> 

Not using compression. As a security flaw. 

The truncation issue could be a real one, but a lot os HTTPS servers closed all sessions without an alert, so the truncation was possible with SSLv3 as well.

The padding and sake-key issues are real issues. Thanks.

It its defence, SSLv2 did not have the insecure renegotiation thing, which has caused more heartburn to more people than any cleartext pad length.

Yoav