Dissecting the SSL handshake
idea.popcount.org
idea.popcount.org
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?
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.
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
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.
Perhaps they've finally developed something along the lines of panopticlick (https://panopticlick.eff.org/) for tracking purposes.
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
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.
4. In order to skip (2) many servers such as apache have support for a type of "memcached like" distributed key value store allowing instances to share session data called dc. http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsession...
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>
Without SNI you can only have one domain name per IP so that security consideration is not really an issue.
* Without SNI you know - guy A spoke to guy B, who is say facebook.
* With SNI you know - guy A spoke to guy B, who is facebook, and asked for myfavouriteuniquepics.facebook.com.
SNI may reveal some information.
Whether the from SNI or the cert itself, there could be a lot of info to be learned about what the user was trying to access.
There is an example with mixing paint colors that is pretty easy to understand.
p is a prime number because it needs to be a cyclic group! It all makes sense :D