Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with your friend's Facebook and Tinder sessions

robertheaton.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Fun with your friend's Facebook and Tinder sessions

#51

Post by Mawaai »

neftaly wrote: post #22
jjarmoc wrote: post #12

Earlier quoted context omitted.

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.

Well, if you can intercept the request to the server to can also change that parameter of the TLS certificate hash.

Re: Fun with your friend's Facebook and Tinder sessions

#52

Post by _nedR »

sayemm wrote: post #26

Really clever hack and entertaining blog post! Love this author's writing, esp this other post of his on Playing to Win - http://robertheaton.com/2014/11/03/why-you-should-read-playi... A hacker at heart.

Thanks for the link. Although there were some points in the article where i was not sure he was being serious or sarcastic.

Just began reading the actual book Playing to Win (Its available free for online reading: http://www.sirlin.net/ptw ). It has already struck me as very intelligently written and insightful when you view its lessons as applying to life (at least the competitive aspects of it) rather some video game.

Re: Fun with your friend's Facebook and Tinder sessions

#53

Post by philbarr »

robheaton wrote: post #40
thret wrote: post #39

Earlier quoted context omitted.

Shouldn't the brown-eyed people kill themselves on day 101? Or are they supposed to reason that they, and they alone might have some other coloured eyes.

This is true - it depends on whether they know there are exactly 2 different eye colours on the island. I should clarify that!

Also, since you're not allowed to talk about it, if you work out you have blue eyes you could just keep your mouth shut.

They do seem to be going to an awful lot of effort to top themselves.

Re: Fun with your friend's Facebook and Tinder sessions

#54

Post by btown »

pbhjpbhj wrote: post #20
Xcelerate wrote: post #5

Earlier quoted context omitted.

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

Can't you just sniff for a browser fingerprint and if too many characteristics have altered end the session?

The problem is that the proxy that the attacker is using could ostensibly alter the outgoing messages from his phone's web browser to mimic the browser fingerprint of Steve's desktop perfectly.

Re: Fun with your friend's Facebook and Tinder sessions

#56

Post by btown »

venaoy wrote: post #25
jjarmoc wrote: post #12

Earlier quoted context omitted.

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.

Do any cloud SSL terminators like Amazon ELB support forwarding the channel IDs on to the application servers (i.e. in a custom header)? For that matter, is there a configuration setting for i.e. Nginx if you want to roll your own SSL terminator to do this? Having trouble finding good documentation about how to handle this from the server side.

Re: Fun with your friend's Facebook and Tinder sessions

#57

Post by danielweber »

rjaco31 wrote: post #49
danielweber wrote: post #34

Earlier quoted context omitted.

In the story, BurpSuite was used only on the attacker's machine for ease of use. You could also hand-craft the requests using curl. Cert pinning doesn't help when someone installs their own certificate authority. It stops other CAs that came bundled with the browser from working, but if it stopped self-installed certificates from working it never would have gotten off the ground because many organizations demand the…

Cert-pinning in the application for their own server is totally doable, that's exactly what Google is doing with Chrome.

If you install your own CA into Chrome, it will overrule the cert-pinning that Chrome does. This is very on purpose.

Re: Fun with your friend's Facebook and Tinder sessions

#58

Post by [deleted] »

Mawaai wrote: post #51
neftaly wrote: post #22

Earlier quoted context omitted.

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.

Well, if you can intercept the request to the server to can also change that parameter of the TLS certificate hash.

[deleted]

Re: Fun with your friend's Facebook and Tinder sessions

#59

Post by neftaly »

Mawaai wrote: post #51
neftaly wrote: post #22

Earlier quoted context omitted.

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.

Well, if you can intercept the request to the server to can also change that parameter of the TLS certificate hash.

Is that actually true, though (especially w.r.t. Forward Secrecy)? Don't both parties generate separate halves of a symmetric key independently, preventing any one party from forcing the use of a particular key on a new session?
Post reply on HN