Dissecting the SSL handshake(idea.popcount.org)
idea.popcount.org
Dissecting the SSL handshake
https://idea.popcount.org/2012-06-16-dissecting-ssl-handshake/
10 comments
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.
Interesting,
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?
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.
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.
My Approach is not very scintific I am very new to all this magic, I used the following websites
http://www.google.co.uk/search?q=whats+my+ip this should bring up Googles view of your IP
http://www.whatsmyip.org/ A classic view of IPaddy
http://www.xhaus.com/headers For a view of the headers currently being leaked by the browser
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
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.
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?
Are you using Chrome? Maybe Chrome is automatically upgraded to SPDY instead of using standard HTTP ...
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?
Without knowing the testing methodology of the original poster, it's hard to say for certain :-)
"Google has a way of getting IP from User_Agent."
Perhaps they've finally developed something along the lines of panopticlick (https://panopticlick.eff.org/) for tracking purposes.
Perhaps they've finally developed something along the lines of panopticlick (https://panopticlick.eff.org/) for tracking purposes.
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
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
Relevant interestingness from Jeff Moser: http://www.moserware.com/2009/06/first-few-milliseconds-of-h...
That post was significantly more informative than the original -- thanks!
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.
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...
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...
Reading this, it seems to imply that key exchange in TLS is an insecure process. This is not the case. Several (secure) key exchange mechanisms may be used, such as http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
That was not my intention. I just wanted to spread the dark knowledge - there is more stuff in the unencrypted TLS handshake than most people know.
> 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>
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.
Without SNI you can only have one domain name per IP so that security consideration is not really an issue.
Well, you can use UCC/SAN certificates to support multiple domains under one IP.
Well, what about wildcard certificates?
* 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.
* 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.
One certificate per IP.
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.
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.
This site has an ssl_error_bad_cert_domain. irony. https://www.ssllabs.com/ssltest/analyze.html?d=idea.popcount...
Something I still don't understand, how can they know what key they both use if they don't exchange it in clear first?
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
There is an example with mixing paint colors that is pretty easy to understand.
There is an example with mixing paint colors that is pretty easy to understand.
it's also on KhanAcademy: http://www.khanacademy.org/science/brit-cruise/cryptography/...
this is neat! But it seems like they're doing huge calculations for that.
p is a prime number because it needs to be a cyclic group! It all makes sense :D
p is a prime number because it needs to be a cyclic group! It all makes sense :D