Closed Bug 787492 Opened 12 years ago Closed 12 years ago

Combining SPDY, HTTP URLs, and TLS client certificates leads to a vulnerability

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: abarth-mozilla, Unassigned)

References

Details

We might have a problem when we mix together SPDY, HTTP URLs, and TLS client certificates. I haven't verified that we actually have this problem, but I wanted to file a bug so that you all are aware of the issue. == Scenario == A) The example.com web server hosts both HTTP and HTTPS content. B) Some HTTPS content is sensitive and the server uses TLS client certificates to authorize access to the sensitive content. C) The server enables SPDY. == Thread Model == An active network attacker. == Bad Outcome == The attacker obtains the sensitive content. == Attack Details == 1) Suppose Alice has a TLS client certificate installed in her browser that authorizes her to access the sensitive content. 2) The attacker directs Alice to visit http://example.com/. 3) The attacker intercepts the connection and replies with a malicious HTML document, injecting script into the http://example.com security origin in Alice's browser. 4) The attacker directs Alice to visit http://example.com/sensitive-content.html. 5) The network attacker lets Alice's request reach the example.com web server. 6) The web server performs an opportunistic upgrade to SDPY and establishes a TLS connection between Alice's browser and the example.com web server on port 443. 7) As part of setting up the TLS connection, Alice's browser supplies her TLS client certificate. 8) Having received an HTTP request for /sensitive-content.html on port 443, the server checks the TLS client certificate associated with the connection. 9) The server determines that Alice's client certificate authorizes her to retrieve sensitive-content.html. 10) The server sends sensitive-content.html to Alice's browser. 11) The attacker's script running in the http://example.com security origin reads the contents of sensitive-content.html, which is also in the http://example.com security origin. 12) The attacker's script sends the contents of sensitive-content.html to the attacker's server. == Discussion == If the server doesn't use SPDY (i.e., assumption C fails), then the attacker cannot obtain sensitive-document.html because the server will send the document only TLS connections that have Alice's client certificate, and all such connections will originate from the https://example.com origin. The problem arises because Alice's TLS client certificate is attached to TLS connections that arise from http://example.com origins. When the server relies upon the TLS client certificate to authenticate the client endpoint, the server is implicitly relying upon the fact that the document will be in an HTTPS security origin. The attack doesn't rely upon any details of SPDY. Any use of TLS connections used for HTTP security origins would have the same issue. (For example, ekr's proposal at the recent NSS face-to-face has the same trouble.) Most pieces of web technology (e.g., cookies) don't have this issue because they operate in terms of URLs (or origins). TLS client certificates are "special" because they operate at a lower layer. In particular, TLS client certificates aren't restricted to a set of URLs (excluding origin-bound certificates, which respect the same-origin policy and therefore don't have this problem). == Possible Solution == The easiest solution is probably to ban the use of TLS client certificates for TLS connections established for HTTP URLs.
Also filed with Chromium: https://code.google.com/p/chromium/issues/detail?id=145989
thanks adam - I actually think firefox is ok here in that we mis-implement alternate protocol. You're talking about alternate-protocol when you discuss "opportunistic upgrade" right? Our implementation of that right now is actually a full redirect to an https channel. I'm not saying that's better overall (it was a misreading of an underspec'd aspect of the protocol document), but it should make this a nop. But this is certainly a welcome and germane thought as we think about fixing it and http/2, etc..
What matters is the URL of the content, not whether we check the validity of the server's certificate. None of the steps in the attack involve the attacker supplying any certificates.
I've chatted with a few others, and I believe the attack requires a server bug when a SPDY server incorrectly does not validate the scheme for the resource requested. If it sees the scheme is http, it should not use any TLS client credential in serving the request.
Actually, now that I think about it, I think this means that the Firefox implementation is vulnerable, since to the SPDY server, the resource requested *will* have a https scheme, so the server should respect the TLS client certificate for that resource, even though it originally had a http scheme. Does that sound right to people?
(In reply to Adam Barth from comment #3) > What matters is the URL of the content, not whether we check the validity of > the server's certificate. None of the steps in the attack involve the > attacker supplying any certificates. it's not just the server cert verification, our implementation does the moral equivalent of a 307 redirect with an https:// location .. If that isn't sufficient I need a pointer in understanding how this is different than an interception of any http/1 subresource and substituting it with a 307/location=https://example/sensitive response completely independent of spdy or A-P.
Suppose Firefox uses SPDY-over-TLS to retrieve http://www.example.com/foo.html, where foo.html is the following: <script> alert(window.location.href); </script> <div>Secret number: 3943948394</div> What string is alerted? My understanding is that the string "http://www.example.com/foo.html" will be alerted. More to the point, suppose that http://www.example.com/bar.html contains the following HTML: <iframe src="foo.html"></iframe> <script> window.onload = function() { alert(frames[0].document.body.innerHTML); }; </script> Further suppose that bar.html is retrieved over plain HTTP (neither SPDY nor TLS is used for the transport) but foo.html is retrieved using SPDY-over-TLS. What does bar.html alert? Specifically, is bar.html able to learn the secret number?
I think this vulnerability exists independent of spdy/alt-protocol.. precondition: goto https://www.ducksong.com/ and create an exception for the lame self signed cert I have on that host so you can run step 2.. 2] goto http://www.ducksong.com/misc/tls/bar.html it contains: <iframe src="https://www.ducksong.com/misc/tls/sensitive.html"></iframe> <script> window.onload = function() { alert(frames[0].document.body.innerHTML); }; </script> both firefox and chrome show the contents of sensitive.html and presumably they would both use a client cert to fetch it if one was configured. there is no spdy or a-p in use on that host. Insertion of this code into http://[..]bar.html is no more priv'd than step 3 of comment 0, right? And the result is a superset of cases to be concerned about. I suspect that if this attack didn't work then the FF A-P implementation would also be immune. as usual I'm probly missing something and am all ears..
> > as usual I'm probly missing something and am all ears.. too little sleep - neither firefox nor chrome did the alert(). (which is good - and expected). my sleepiness confused seeing the iframe with the alert() - very different. Sorry for the alarm bell. (In reply to Patrick McManus [:mcmanus] from comment #8) > > > I suspect that if this attack didn't work then the FF A-P implementation > would also be immune. > so I need to test this using A-P on http://sensitive.. that'll take a little bit of time, but I think it will be ok.
Can you explain what you think will prevent bar.html from reading the contents of foo.html?
(In reply to Adam Barth from comment #10) > Can you explain what you think will prevent bar.html from reading the > contents of foo.html? http://foo.html is redirected to https://foo.html and therefore http://bar.html cannot read its contents. I have verified that is true with http://foo returning {307, https://foo}.. but haven't done it with A-P instead of 307 yet. But the code is modeled to execute the same call chain which should update foo's uri on the redirect.
Ah, interesting. Yes, if you do a redirect to https://www.example.com/foo.html, then you'll be fine. Is there a way to tell in the Firefox UI whether SPDY-over-TLS is being used? If I go to http://www.google.com/ and type in a search in Firefox 15, I would have expected that to use SPDY-over-TLS, but the address bar still says "http://www.google.com/..."
Adam, are you signed in to Google? Google does the https:// homepage redirect for signed in users.
I am not signed in. I'm using a clean install of Firefox. Does http://www.google.com/ not use SPDY?
No, http://www.google.com does not send a Alternate-Protocol response header for opportunistic upgrade to SPDY over TLS. For signed in users, http://www.google.com will redirect to https://www.google.com.
it might help to explain the a-p misunderstanding. I thought it was for the use case of someone that had a great spdy https:// site but didn't want to publish https:// urls (or do unconditional redirects to them) because they would regress performance for folks using non-spdy browsers with http://. In that thinking A-P is essentially a conditional redirect if you know spdy. So of course you want it redirected to https:// to get all the glory of that scheme - thinking about it as http over tls never really came into it. Now I know the background of a-p is as much about bringing spdy to mixed-content environments as anything else. Obviously, that changes the thinking somewhat. I'm generally a fan of http over tls - but that's not what's implemented and its on my radar (since just vancouver actually) to get this reconciled. So this bug report is still quite helpful.
Ok. Sounds like Resolved Invalid. Thanks for talking it over with me.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Group: core-security
You need to log in before you can comment on or make changes to this bug.