What was not mentioned in the article was why the ClientHello and ServerHello messages include a bunch of random data. The reason is to prevent a replay attack, where Mallory has intercepted Alice and Bob's previous transmission and fools Alice into thinking that she's talking with Bob by re-transmitting Bob's messages from the previous attack. The random data has to be signed with your key so the other party can be sure it's you sending that data. This kind of liveness guarantees are used quite often in public key cryptography.
This method of fingerprinting bypasses "elite" anon proxies and gives away IP addresses and OS of the host. Google currently employs a number of tricks to get real IP addresses, you can run a connection via a proxy and 99% of websites you visit will only get the Proxy IP, Google has a way of getting IP from User_Agent (not sure how but I was building my own proxy last week and found this out).
Will check the tor bundle later (as they are better configured) but I believe they will be harden against this, I dont know how I could make firefox in a default configuration stop leaking this information without cripping my install, anyideas?
Aside from SNI (which the article mentions HAS to be submitted in plaintext) you might be able to randomize the supported ciphers. Just like faking the User Agent String, you might be able to randomly select a cipher suite equal to that of another browser (and that your browser supports as well).
Randomizing the ciphers is not a good idea. First, their order is significant - in theory the server should pick up the first it knows. Second, limiting supported ciphers inevitably may lead to incompatibility with some websites (as they may support only ciphers that were omitted).
I'm curious to see how you tested this... the user-agent should only ever emit the browser (product) and a comment after this. It should never show the IP address of your machine!
Were you doing the test on all browsers, or was it only Chrome? I'm curious as to what's going on here, because if Google have worked out how to get your IP address even when going through an SSL-capable proxy (not something I'd normally recommend, btw...) then I'd suggest they are sending something else over the wire.
Mind you, if you have not disabled the X-Forward-For header on your proxy, then this may be how Google knows your originating IP address. You should be able to tell by running a packet trace between the proxy and the Google site you are accessing.
Perhaps they're just probabilistically getting your IP address by clustering your user agent+browsing habits+etc against the set of IPs it's seen that cluster come from via AdSense embedding on other sites?
Now I was setting up my proxy as I was doing these said tests so it was work in progress, First checked it all
out with no changes to the headers. Then I started stripping the headers a few at a time to see the differences
between the above websites and a few others. Now my IP changed as soon as I did an x-forward no change in the
proxy configration. At this stage 99% of websites get the IP of the proxy, I was happy. however Google still
was giving me my real IP. More header striping later and pinned it down to the user_agent. I know the user agent
does not contain any IP information but I think google must be using it as part of the IDing of the broswer profile
My main point today was that this SSL handshaking leaks lots of information that appears to be able to see
real IP behind a proxy. The bad man in side of myself now wonders if I could knock up a script like
https://p0f.popcnt.org/ that can see passed a proxy to get real IP addresse not that I would have anywhere
interesting to put it, guess it is just the fun of doing it.
Now I completely believe that my proxy could be just badly setup, so I also tested the p0f page on a number of
elite proxies (public not private or paid) and the p0f page gives up the real IP every time.
As i said, I will try the tor broswers to night (sidenote I only really test firefox because Chrome and IE lift
proxy settings from the local system where as firefox is customizable
Oh i used your header page, very nice http://my-addr.com/ip (thank you), all headers are empty and it has the correct IP (proxyed)
Sorry for spelling, :/ notepad lacks a spell:checker
Are you sure your browser or proxy is configured to use https? In my case, HTTP://p0f.popcnt.org is correctly anonymised, while HTTPS://p0f.popcnt.org is not and leaks my originating IP address.
I was concerned, so I tried a bit of troubleshooting before realising I configured Firefox to use no proxy for HTTPS traffic (because I don't want my banking to go through the proxy). So really, there was no problem.
Bizarre! Try finding an extension to change the default user agent in Firefox (there are quite a few) and try it again... I'm curious to see if it still works! What happens if you try a few different browsers? Same issue?
You can't hide your IP address from the proxy, but assuming the proxy is not passing it along in an X-Forwarded-For or similar header, your browser will not pass the IP address along in the HTTP request (and never in the User Agent). You do need to disable all 3rd-party plugins and prevent cookies from being passed as they may separately reveal the IP address.
This page will display the proxy headers which might be passing your IP, but more likely it's flash or java or something else sending it: http://my-addr.com/ip
SSL/TLS is super interesting. Because we often aren't set up to monitor it, it's kind of a black box in terms of performance. Here's some interesting stuff I've found lately:
1. In order to establish a chain of trust, the server is going to be sending your browser at least 2 (server cert, ca) if not more certificates, which contain a fair amount of plain text, so there is some bandwidth overhead here.
2. The most computationally expensive part of SSL setup is the challenge/response key verification step, which generally involves RSA (public/private keys) rather than AES (symmetric keys).
3. SSL session reuse is an interesting feature, on one hand it allows you to skip (2), but if those session keys aren't stored securely server side, it opens up an attack vector. So just remember to make sure those values are as secure as your server's private key.
> Reading this, it seems to imply that key exchange in TLS is an insecure process.
The key exchange in itself is an insecure process that may be attacked with a man in the middle attack. However, this is a known limitation of the key exchange protocol which is fixed by adding a public key signature to the key exchange messages so TLS is not vulnerable overall. </oversimplification>
> When using SSL, the remote domain name is transferred over the wire in plain text. Anyone able to sniff the traffic can know exactly what domains you're looking at, even when you're using HTTPS.
Without SNI you can only have one domain name per IP so that security consideration is not really an issue.