Wonder if the match referenced at the end is true. Fun read.
Monica and Steve have two kids. As they weren't referred to as "twins", I'm going to assume that they're not. Assuming Monica got pregnant on the first date and again immediately after she gave birth (which is perfectly possible, but an unusual choice and very strenuous on the mother) that puts the episode 18 months ago, no later than July 2013. Considering that Tinder was launched around August 2012 and assuming Mon…
I wonder if it's feasible to reference the TLS/SSL session against the session cookie? While the HTTPS session itself is probably transient, you can tell something is up if the same session cookie is being used with two different HTTPS keys.
You're describing the concept behind channel bound cookies. https://tools.ietf.org/html/rfc5929 As far as I know, it's not supported by any current browser (I welcome feedback to the contrary) but is included in SChannel. Given that we've only recently (arguably) gotten away from SSLv3, I don't have high hopes that it will be viable to require channel binding in the very near term.
Cool – hadn't heard of that before. I was thinking more along the lines of a purely server-side approach:
$_REQUEST["salted_SHA_hash_of_symmetric_TLS_key"]
You'd save the current key to a DB, and manually check it in future requests.
I'm trying to think about whether there's a way for Facebook and/or Tinder to mitigate this attack without degrading user experience. Because the auth token used is from the response to the last request ever made from Steve's computer, having a changing auth token on each request wouldn't help in this scenario. Restricting an auth token to an IP address wouldn't work since both users are presumably behind the same NA…
It seems like the most reasonable mitigation would be to disallow Burp Suite from working at all by using SSL cert pinning. (I'm actually pretty surprised that they don't do this already -- I know that Google pins certs for their own apps in Chrome.) This, of course, would not completely stop the issue. But, it would make the author's job that much harder, since he'd have to emulate the Tinder protocol without the as…
That wouldn't help either: In this article, the Facebook is uninstalled prior to authorization to ensure the Facebook request is forced to go through the browser. So you might be able to get away with HSTS certificate pinning, but that could likely easily be cleared out (unless it's preloaded... i dunno if you can clear HSTS preloads in Safari, or if they even have such a thing). Even then I suspect the authorization could be spoofed somehow, as all of these measures only matter on the attacker's machine
I wonder if it's feasible to reference the TLS/SSL session against the session cookie? While the HTTPS session itself is probably transient, you can tell something is up if the same session cookie is being used with two different HTTPS keys.
You're describing the concept behind channel bound cookies. https://tools.ietf.org/html/rfc5929 As far as I know, it's not supported by any current browser (I welcome feedback to the contrary) but is included in SChannel. Given that we've only recently (arguably) gotten away from SSLv3, I don't have high hopes that it will be viable to require channel binding in the very near term.
Chrome v24+ does support all you need for channel-bound cookies: it supports TLS Channel IDs (previously known as Origin-Bound Certificates). To actually bind cookies, it is the server's responsibility to extract the channel ID from the TLS/SSL handshake, and bind the cookies to it.
If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)
If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)
Couldn't the author just copy Steve's private key to his computer then?
Not if it's a hardware key. You give the processor something you want to encrypt, but you can't look at the actual key itself (the only way to do that would be with an electron microscope).