[TLS] The Web Security model vs.TLS (was Re: Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard)

[Watson Ladd <[e-mail]>]

On Wed, Jan 21, 2015 at 10:11 PM, Martin Rex <[e-mail]> wrote:
> Bodo Moeller wrote:
>>
>> If even just a *single* high-value site that you, personally, use does
>> support the SCSV, you'll benefit from the SCSV (provided that you're using
>> a browser that does a downgrade dance for compatibility with other servers
>> and sends the SCSV in downgraded Client Hello messages).
>
>
> I've been looking long and hard, but I'm having difficulties
> to see a noticable benefit.   OK, a Poodle demonstration of the CBC
> padding weakness will no longer work, and maybe a minor fraction of
> the script kiddies will spend their time on other activities.
>
> But for the security of the typical web browser, and I'm not currently
> aware of any TLS clients other than web browsers that are doing
> downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.
>
>
> The real problem, that is a prerequisite to Browser attacks like Poodle
> (and BEAST and CRIME predecessors) are
>
>    1) a browsers aggressive willingness to execute *ANYTHING* from
>       *ANYWHERE* that looks like active content
>
>    2) provisioning of a cross-site-request-forgery (CSRF) facility,
>       where the browser will share/insert the user's authentication
>       credentials into *EVERY* GET/POST, irrespective where that
>       request originates
>
> For a number of sites, being able to perform crafted GETs and POSTs,
> for which the browser will automatically provide/perform the
> authentication on behalf of the user, will provide ample room
> to cause trouble or damage to the end user.  No existing nor future TLS
> protocol version and no existing or future TLS cipher suites
> can prevent exploitation of such a Browser (mis)feature.

Go ahead and exploit this "vulnerability" you are discussing against
Paypal, Gmail, Facebook, or Amazon. You won't be able to. While there
is much to criticize the web security model for, and plenty of
websites are open to CSRF, characterizing the issue as unresolved is
wrong: there are standard, effective, protections that are regularly
used.

Would you use the fact that ASN.1 parsers routinely give RCE as an
argument against deployment of TLS, or removing broken ciphers? What
about the significant information leaks caused by TLS's disclosure of
timing and sizes of data transfers between client and server?
Ultimately, if you want to look for excuses, the failure of operating
systems to even attempt to provide basic security properties is a
problem.

Is there any historic or imaginable security issue in TLS, which this
logic can't be employed to dispose of? Renegotiation bug: well, it's a
consequence of internal layering we can't possibly be expected to know
about. Triple handshake: oh, the real problem is not validating every
certificate chain you see during the events. The fact that the
implementers were never advised of these issues in the first place is
conveniently omitted.

There is plenty to be said about the languid pace with which the IETF
addresses known security issues, the general apathy with which
designing for security is greeted in general, and the slow adoption of
known solutions, but none of this is an excuse for worsening the
problem.

I agree that if browsers could use existing extensions as indicators
of functioning servers, that would be a better approach that provides
security benefit to far more connections.

>
> A single Poodle attack on a browser requires the attacker to be on-path
> between browser and server, for which the attacker intends to recover the
> users basic authentication credentials or SSL session cookie through
> repeated guessing -- and to perform active attacks on thousands of
> network connections between browser and server, creating thousands
> of otherwise quite rare TLS MAC errors in the server's logfile.

You assume people a) read logs, b) recognize these errors c) connect
them to an attack, d) have an action to take and e) take it. This is
unlikely.

You also assume that being "on-path" is a constraint. It isn't.
Sitting in between the user and the website are dozens of poorly
secured routers, many with default passwords and hard coded SSH keys.
These routers are more than capable of mounting Poodle.

>
> When (ab)using the browsers CSRF facility directly, rather than for noisy
> and boring Poodle, it will be sufficient to piggy-back one single arbitrary
> page that the user's browsers happens to load (or can be lured to load).
> When properly done, the attack will be indistinguishable from a genuine
> action of the user for the server, and be noticable for the user only
> by forensic inspection.  The browser's CSRF facility may even
> allow (ab)use of TLS PSK credentials or TLS client certificates,
> a form of credential that can not be attacked/recovered by Poodle.

I hadn't thought of that last idea. Should be easy enough to test.

>
>
> Attacking an *arbitrary* page is still quite trivial depressingly often,
> because so many sites force their users to use plaintext HTTP for at
> least parts of their stuff -- effectively throwing all security
> overboard each time.
>
> lots of online shops.  a popular auction site.
>
> Today I visited the site of a popular video/phone/chat software.
> Even when accessing their site via https: the "Sign in" and "Join us"
> URLs (at the upper right of all pages of the site) will _force_ the
> user through plaintext-HTTP.   The link to their Download section
> is https, but in the download section, the actual green software
> download button, again, forces you through plaintext-HTTP -- OUCH!

So what? I don't see why Johnny with the screen door on his house
means that the bank shouldn't have a bank vault. There are plenty of
outdated Wordpress versions out there: does that mean we shouldn't
stop SQL injections?

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