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

[Bodo Moeller <[e-mail]>]

Martin Rex <[e-mail]>:

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

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

Yes and no.  While it is certainly true that this is an unfortunate problem
with the protocols that browsers use today, the kind of cross-site request
forgery that you describe is commonly prevented by adding appropriate
additional verification tokens (that the attacker couldn't obtain or
predict or otherwise caused to be added) into legitimate requests,
supplementing the credentials (such as HTTP basic authentication passwords
or HTTP cookies) that would also go into the requests caused by the
attacker.  (Often enough, of course, the need for such protection is
missed, or tokens are added but not verified, etc.)

With such protection in place, browsers attacks like BEAST and POODLE can
undermine the security you'd otherwise achieve.  So in the reality of the
web today, browser attacks like BEAST and POODLE *are* relevant if they are
possible.  You might wish that this wasn't the case, but there's certainly
no near-term resolution of the basic CSRF issues in sight.

[As an aside, note that the "cross-site" jump may be only from
http://www.example.com/foo to https://www.example.com/bar if we assume that
the attacker controls the network, so it's a "cross--web-origin" attack
rather than a "cross-site" attack.]

Bodo