Cenzic 232 Patent
Paid Advertising
web application security lab

Improving HTTPS Side Channel Attacks

41 more posts left until the end…

In regards to the previous post and the impending Blackhat speech with Josh Sokol, I thought I’d spend some time enumerating some of the possibilities for reducing the chatter over SSL/TLS that the browser introduces. There are a few things that an attacker generally doesn’t care about (not always, but generally). They generally don’t care about images, CSS, JavaScript, favicons, and most of the HTTP headers. That is, those parts of the HTML and HTTP request/response are generally less interesting than the content itself or what the user is sending. So there’s a few tricks we can use to force the user’s browser to cache the content prior to intentionally navigating there (call it pre-caching for lack of a better term).

Firstly, there’s a pretty good chance that an attacker can connect to the SSL/TLS encrypted website site in question and see what the HTTP response headers look like. Minus cookies, URL and POST data, an attacker can get a pretty accurate picture of what the HTTP response looks like. The attacker can also identify what sort of key exchange the user will be using with the site in question through a little enumeration. So the amount of data sent on the wire is smaller, and the data that is sent can be isolated to the few unknown components.

Next, an attacker can create an iframe (from a MITM’d HTTP website - the side channel) to the SSL/TLS encrypted site in question to pre-load all the images, JavaScript, CSS, favicons, and so on, that typically muddy the encrypted HTTP data flying in both directions. Lots of times the files in question are inconsequential to the page in question from the attacker’s perspective. But because browsers share sockets for multiple requests, often the chatter for these static objects can make determining what is on the wire much more difficult.

So by forcing the user’s browser to pre-cache the content, an attacker can get down to just the pages they are interested in and a few GET requests that return 304 Not Modified responses. That’s a much smaller footprint for the unrelated data than it would be if it weren’t cached. Now, it may not always be a good idea to pre-cache. Sometimes the content will be hosted on other subdomains or domains, and therefore won’t create the same amount of chatter over the socket, because it isn’t pulling that content from the same IP. Other times it may be useful to detect that a user is on a certain page, because some of the content is a very specific to that page in question and is a known size - alerting the attacker to the fact that the user being monitored is on the page in question.

In this way an attacker is really getting down to the exact parts of the data they are interested in. Obviously the earlier an attacker can do this the better - trying to cache after the fact doesn’t make a lot of sense, although using timing attacks an attacker may be able to tell where the user has been, interestingly enough (Chris Evans did a good writeup on this a while back).

10 Responses to “Improving HTTPS Side Channel Attacks”

  1. Tom T. Says:

    “Next, an attacker can create an iframe (from a MITM’d HTTP website - the side channel) to the SSL/TLS encrypted site in question”

    OK, you’ve MITM’d some HTTP website. I visit my online bank, which is all HTTPS. How can you force mybank.com, or my browser, to run your iframe? — given that best practice is never to have any other windows or tabs open when doing secure, sensitive browsing, and also to close the browser, delete all cache, cookies, etc. (default config for mine), and start a fresh browser for sensitive actions. . … Unless you’ve found some injection vuln, XSS vuln., etc. in mybank.com, in which case, any number of far more straightforward attacks would work, no?

  2. Sheridan Says:

    Sorry not related to the article really:

    I think I may have missing something, 41 posts until the end? Are you taking very early retirment or something? What’s the deal RSnake?

    It’d be a real shame to see this blog go. It’s varied between invaluable, interesting and way over my head in the time I’ve been reading it.

  3. RSnake Says:

    @Tom T - The iframe would appear prior to switching into HTTPS (lots of banks have pages that are HTTP that switch you into HTTPS only once you click the login button which takes you to the sign-in page). But most people don’t understand that tabs can be used to an attacker’s advantage. That is also a likely scenario. Relatively no one cleans cache/cookies prior to and after logging into their bank, so that’s not even worth talking about - I mean it works for guys like us, but not for the average person.

    @Sheridan - No, not retirement. I’ll still be running my company, hitting up conferences and so on. But I won’t be posting to ha.ckers.org anymore. I’m glad you got value from the site though. Hopefully your time reading this site empowers you and others to seek out the knowledge on your own and teach one another when you find something that the community should know.

  4. AppSec Says:

    @RSnake:
    I have a habit of disappearing and not reading for awhile, so I just wanted to take a minute and wish you luck.

    I was sincere about the offer to help with the log analyzer tool, so please let me know the best way to get in touch with you regarding it.

    Hope we hear you on the ‘net in other ways.

  5. antani Says:

    @RSnake: I’m just guessing but perhaps I catch what’s going on.

    What happens when somebody work too much and don’t benefit from the right environment (free time, friends, inputs)? Ideas vaporize. And ideas are somehow important to entertain people with amusing security stuff.

    So for the sake of God don’t retire from thinking, just take this blog less seriously, stabilize things on the work and build the environment that makes you happy. You’ll be back better than before :)

    This is why writing 41 more entries while not being in the right mood has no sense at all IMHO. Stop now and don’t feel forced to do something!

    All work and no play makes Jack a dull boy.

  6. RSnake Says:

    @AppSec - I’m not leaving security, so yes, the log analyzer is still need (if not by me, then by many other professionals around the world).

    @Antani - I wish it were that simple. I’ll talk about it more at the end. I don’t feel forced to stop the blog though, I want to, and have wanted to for a while now. So I picked a good goal to get to and then I’ll feel like I’ve accomplished what I set out to do.

  7. antani Says:

    @RSnake: Understood. Then best wishes for what is going to be!

  8. MrAnderson Says:

    @RSnake: It is sad to see the scene disappear like this one site at a time, one blog at a time, but everything in this world that has a beginning has an end (the Oracle would say, I guess), so I wish you best luck, you did a very good job with this blog. I’ve also decided to put up my own blog on security and the such. If you want to have a look and tell me what do you think about it, it will be really appreciated.
    The link to it is http://penetrationtest.altervista.org/blog it is in italian, but you can always use google translator. Anyways you can always have a look at the layout and the tools :P let me know

  9. Tom T. Says:

    @ RSnake: “The iframe would appear prior to switching into HTTPS (lots of banks have pages that are HTTP that switch you into HTTPS only once you click the login button which takes you to the sign-in page).”

    See my comment at the next blog (I think), “Places to MITM”. (awaiting moderation due to containing links, in case this comment shows before the other one does). More and more banks are abandoning that unsafe practice, due to unfavorable publicity from the peeps mentioned in my comment to that post — and from yourself — and from all of the other community whose exposure pressures the careless web admins to be more careful.

    Which is another reason it’ll be sad to see this blog go. Sometimes we don’t know how much good we’ve done (this gets very Zen, with the ripples in the water and all :) ) — who might have read your blog and pressured her/his bank, what bank employee might have stumbled across it or been sent a link — and so on for all the other vulns, attacks, and careless coding.

    Maybe if you removed all pressure from yourself to post at all, you’d feel like posting once in a while. The loss of any inquisitive mind’s thoughts is a shame.

    “Hopefully your time reading this site empowers you and others to seek out the knowledge on your own and teach one another when you find something that the community should know.”

    And you are one more set of (very sharp) eyes to seek and share that knowledge. But whatever you decide, GL to you, and thanks for the many interesting thoughts, usually from a unique, “outside the box” perspective.

  10. Johan Says:

    Dang thats a shame, though alot of the things you write about go a bit over my head I do enjoy reading this blog and thanks to that I started upgrading some (read: ‘nearly all’) of the security on the websites I work on,

    Oh well… All good things come to an end I guess,