Re: [TLS] Prohibiting SSL 3.0

[Watson Ladd <[e-mail]>]

On Thu, Oct 30, 2014 at 7:31 PM, Martin Rex <[e-mail]> wrote:
> Watson Ladd wrote:
>>>
>>> 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"?
>
> 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.

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


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

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

>
>
>
> -Martin



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