An alleged SSL/TLS protocol vulnerability

[Posted September 20, 2011 by corbet]

Here are articles in the Register and Threat Post on a new attack that, it is said, can extract cookies from SSL streams. Details are scarce, but it seems to be a man-in-the-middle attack that injects a bit of JavaScript into the victim's browser. That JavaScript can then take advantage of the fact that SSL connections are reused across page fetches to carry out a known-plaintext attack against that connection. TLS versions 1.1 and 1.2 are apparently not vulnerable, but, alas, nobody uses those versions. Those wanting to do some digging can learn a bit more from conversations on the TLS list and Hacker News.

An alleged SSL/TLS protocol vulnerability

Posted Sep 20, 2011 23:44 UTC (Tue) by rickmoen (subscriber, #6943) [Link] (25 responses)

1. This is fundamentally just another XSS mode that permits a man in the middle bit of JavaScript to conduct a chosen-plaintext decryption of cookie data encrypted using an AES cipher-block-chained-(CBC-)mode block cipher. Therefore, the RequestPolicy Firefox extension is your friend, being a general preventative against XSS malarky.

2. You know that 'This page contains both secure and nonsecure items' warning you keep ignoring? Stop doing that.

3. As effective as RequestPolicy is, that plus NoScript is even better.

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 0:43 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (12 responses)

"You know that 'This page contains both secure and nonsecure items' warning you keep ignoring? Stop doing that."

And if the site issues unencrypted ads when the user asks for https (as LWN itself did for quite a while), then what? The only options are either to stop using the site or to assume that everything is insecure.

We've done a very good job of training users to ignore warnings related to https, because those warnings appear so often during normal operation (because misconfigurations that generate the messages occur so often).

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 1:22 UTC (Wed) by ewen (subscriber, #4772) [Link] (2 responses)

Assume everything is insecure if you're getting mixed HTTP/HTTPS. Because, well, it is, given that the HTTP portion could be replaced in transit with anything. As I saw pointed out a little while back, intercepting and replacing the Javascript loaded for, eg, the central copy of JQuery or Google Analytics, on the wire, would give a surprising amount of exploitation reach for not much effort once you're a MITM.

IIRC from a recent security conference talk, browser vendors are already leaning towards just blocking mixed HTTP/HTTPS content. (AFAICR the next Internet Explorer is going to block it, and Chrome/Mozilla are leaning that way once some of the more user-affecting breakage can be cleaned up.) Possibly things like this will push that a step closer. At which point sites with mixed content will have a stronger incentive to Not Do That (tm) -- their site will just not be loadable by more and more modern browsers.

Ewen

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 4:32 UTC (Wed) by lindahl (guest, #15266) [Link]

I would love this solution -- our big problem at blekko with mixed content on our own website is that the 3rd parties that we work with don't have HTTPS for all of their stuff that we use. A browser ban would be perfect for helping us get the point across.

I surveyed a lot of HTTPS websites as part of our HTTPSPreferred(R) feature (mostly banks), and almost half of them threw a mixed http/https warning.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 7:10 UTC (Wed) by hpro (subscriber, #74751) [Link]

Would an initial approach with the browser declining to fetch any content over HTTP when the page itself is HTTPS not work? Like if an ad image is served HTTP on a HTTPS page, it would just not be loaded.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 1:28 UTC (Wed) by rickmoen (subscriber, #6943) [Link] (8 responses)

Joe --

Figuring out the occasional anomaly and understanding why it's there differs significantly from ignoring it, in my perhaps limited experience. Please note that I merely said 'stop ignoring'; I didn't say 'refuse to ever, under any circumstances, tolerate'.

Other alternatives to 'ignoring' are probably also possible.

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 16:33 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (7 responses)

In my case I do attempt to figure it out, but most users don't have multiple decades of experience on computer networks. Ideally the browsers should do more to help users distinguish cases that are likely to be misconfiguration from cases that are likely to be fraud. A security system that gives too many false positive warnings tends to be ignored.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 16:46 UTC (Wed) by rickmoen (subscriber, #6943) [Link] (5 responses)

Joe --

Personally, I have the great and good fortune that the unending travails, hapless fate, and proverbial helplessness of 'most users' is simply not my problem. In my experience, concentrating on assisting people willing to take at least a very minimal amount of initiative increases the quality of my life, and enhances my satisfaction and ability to get things done, immensely. That is one of the advantages of Linux itself, for example.

I do wish you the very best of luck in your effort to make the Internet safe for 'most users'.

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 22, 2011 12:16 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (4 responses)

Someone who has installed a non-default browser has probably already taken "at least a very minimal amount of initiative". However, even highly self-starting people are not immune to warning fatigue, and the more intrusive the false positives get, the less likely even highly competent people are to leave the warnings enabled.

And remember: J. Random Luser's incapability, ineptitude, and inability to self-motivate is, in fact, your problem. It's not directly your problem, but it is your problem.

An alleged SSL/TLS protocol vulnerability

Posted Sep 22, 2011 17:48 UTC (Thu) by rickmoen (subscriber, #6943) [Link] (3 responses)

mpr22 wrote:

...even highly self-starting people are not immune to warning fatigue, and the more intrusive the false positives get, the less likely even highly competent people are to leave the warnings enabled.

Let me tell you how the world of https looks, as I encounter it: The number of https sites I use that are meaningfully security-sensitive is about 20 or 30. (I don't reuse passwords among sites. I run the HTTPS Everywhere extension, NoScript, AdBlock Plus.) Number of https sites, from among those 20 or 30, that generate warnings about mixed http/https content: literally zero, as it happens.

If I did encounter warnings on, say, some banking or similar sites among the 20 or 30 prior to a few days ago, I would 'stop ignoring' them by finding out why they were occuring and fixing them if possible. There would have been no 'warning fatigue'. As it happens, a few days ago I decided to add RequestPolicy as a general XSS/CSRF preventative, and it make the entire problem discussed here go away completely.

Now, certainly I would appreciate seeing a general cleanup where Same Site policies are enforced without needing RequestPolicy, NoScript, etc. as bandaids. It strikes me that making browsers back off to http any time there's mixed content might be a logical next step, but the exact general implementation is, thankfully, not my problem either. Your assertion that someone in a situation like mine inevitably will make some ghastly error on account of 'warning fatigue' is simply factually incorrect. Which brings me to your other contention:

J. Random Luser's incapability, ineptitude, and inability to self-motivate is, in fact, your problem. It's not directly your problem, but it is your problem.

I prefer to think of it as a 'consulting opportunity'. Anyway, is this some sort of fatuous ideological advocacy? It sounds very much like the corporate-exhoratation genre, such as when one-time Blyth Software CEO and self-promoting dullard Michael Minor told all of us 1980s technical employees that we were 'all salesmen'. (The same logic suggested that we were also all janitors, all accounting clerks, and all receptionists.)

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 22, 2011 17:55 UTC (Thu) by rickmoen (subscriber, #6943) [Link]

By 'Same Site policies", I meant Same Origin policy, but just could not remember the correct name off the top of my head.

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 23, 2011 9:44 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (1 responses)

J. Random Luser's ineptitude is your problem because his computer is a botnet zombie generating negative utility for everyone who has systems facing or nearly-facing the public Internet.

An alleged SSL/TLS protocol vulnerability

Posted Sep 24, 2011 2:22 UTC (Sat) by rickmoen (subscriber, #6943) [Link]

Ah, so it's 'my problem' to roughly the same extent that rabies in the critter population above my town is 'my problem'. And this news flash merited your injecting a public service announcement into an LWN thread about technology. Well, as they say in the American South, 'Bless your heart.'

Rick Moen
rick@linuxmafia.com

An alleged SSL/TLS protocol vulnerability

Posted Sep 24, 2011 3:01 UTC (Sat) by thedevil (guest, #32913) [Link]

So, how do you figure this out? Educate me. I know that (some of) you view it as a consulting opportunity, well I promise to advertise diligently for you if you help me :-)

I just opened a newspaper site because I'm flying 2 days from now and an airline strike was brewing, and I got the mixed content warning. I don't have weeks to do the investigation, or even hours. I need the information now.

How can I get at this? I have these extensions: Perspectives, Error console, DOM inspector, Web console, Live HTTP headers. None of these seem to give a simple way to trace and list connections without a huge load of extra junk that needs filtering.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 6:45 UTC (Wed) by butlerm (subscriber, #13312) [Link] (6 responses)

Wouldn't it be far superior for websites to proxy all cross-hosted advertising and other content? Then there would be only one HTTPS connection to worry about, instead of half a dozen, each with a substantial HTTPS connection setup time.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 8:18 UTC (Wed) by noah123 (guest, #58540) [Link] (3 responses)

Proxying content should be avoided as it could compromise the Same Origin policy.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 15:34 UTC (Wed) by butlerm (subscriber, #13312) [Link] (2 responses)

That assumes the proxied content has to include Javascript. We would all be better off if advertisements did not. A proper proxy implementation would filter it out.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 16:03 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (1 responses)

Possibly one could also proxy every proxied domain to a separate subdomain to avoid that problem.
E.g. example.org.my-https-proxy.example and annoying-advertisement.example.my-https-proxy.example

An alleged SSL/TLS protocol vulnerability

Posted Sep 24, 2011 19:51 UTC (Sat) by butlerm (subscriber, #13312) [Link]

The problem with doing that if that you have separate HTTPS startup latency for every separate ad provider, which on some sites seems to be half a dozen or more. If you can safely proxy advertising content, pages will load much faster.

If advertisers just can't live without Javascript, perhaps the W3C could standardize on a technique to sandbox scripts originating from the same domain, even running on the same page.

An alleged SSL/TLS protocol vulnerability

Posted Sep 22, 2011 13:28 UTC (Thu) by mrshiny (guest, #4266) [Link] (1 responses)

The advertisers want requests directly from the browser because that lets them use cookies and do fingerprinting and other things like that, which can't be done when the ad is proxied by the site. So I doubt most advertisers will go with that.

An alleged SSL/TLS protocol vulnerability

Posted Sep 24, 2011 19:57 UTC (Sat) by butlerm (subscriber, #13312) [Link]

Perhaps that is a hint that what advertisers are doing now is a security violation. In any case, deploying ads using https to half a dozen third party domains is going to be so slow that a lot of people are going to have second thoughts.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 6:52 UTC (Wed) by josh (subscriber, #17465) [Link]

Note that this attack does not require injecting JavaScript into the SSL site. The man-in-the-middle just has to inject JavaScript into any plain HTTP site open at the same time, and from there that JavaScript can poke at the SSL site in a way that helps the man-in-the-middle packet sniffer figure out how to decrypt your SSL session.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 10:44 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

If a page contains mixed secure and insecure items, the insecure ones could still be loaded, but with Javascript disabled.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 12:39 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

The problem is that the user doesn't know what the mix is. Telling them "some of what you see can be trusted" isn't worth very much under any circumstances.

That isn't a theoretically insurmountable problem, but the truth is that our existing systems already assume the user is far smarter and more interested than they are, so making it worse is probably the wrong direction.

An alleged SSL/TLS protocol vulnerability

Posted Sep 21, 2011 16:36 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

It would only be feasible if the browser, rather than the user, did this (disable unencrypted Javascript on mixed secure/insecure pages).

An alleged SSL/TLS protocol vulnerability

Posted Sep 26, 2011 22:40 UTC (Mon) by bjartur (guest, #67801) [Link]

Thing is, XSS practically taints *the whole page*. You can't trust any of it. God forbid you from running code from it sans review.