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

[[e-mail] (Martin Rex)]

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.

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.

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.


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!


-Martin