Re: [TLS] Prohibiting SSL 3.0

[Watson Ladd <[e-mail]>]

On Thu, Oct 30, 2014 at 6:03 PM, Martin Rex <[e-mail]> wrote:
> Yuhong Bao wrote:
>> 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).
>
> 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

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.

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

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.

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

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

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

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?

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

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

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

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.

>
> If there was ever reason to "Panic", this was back in 2001 when the
> 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
> [e-mail]
> 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