
Dissecting the SSL handshake - majke
https://idea.popcount.org/2012-06-16-dissecting-ssl-handshake/
======
exDM69
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.

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

~~~
chris_wot
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.

~~~
ukgent2
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

~~~
Nick_C
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.

------
lemming
Relevant interestingness from Jeff Moser:
[http://www.moserware.com/2009/06/first-few-milliseconds-
of-h...](http://www.moserware.com/2009/06/first-few-milliseconds-of-
https.html)

~~~
spydum
That post was significantly more informative than the original -- thanks!

------
shanemhansen
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...](http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsessioncache)

------
obeattie
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...](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

~~~
majke
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.

------
the_mitsuhiko
> 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.

~~~
majke
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.

------
rada
Typo: _Windows XP doesn't send Renegotiation Info extension if without patch
MS10-049 applied_.

~~~
majke
Fixed. Thanks.

------
neilwillgettoit
This site has an ssl_error_bad_cert_domain. irony.
[https://www.ssllabs.com/ssltest/analyze.html?d=idea.popcount...](https://www.ssllabs.com/ssltest/analyze.html?d=idea.popcount.org)

------
baby
Something I still don't understand, how can they know what key they both use
if they don't exchange it in clear first?

~~~
notaddicted
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

There is an example with mixing paint colors that is pretty easy to
understand.

~~~
baby
it's also on KhanAcademy: [http://www.khanacademy.org/science/brit-
cruise/cryptography/...](http://www.khanacademy.org/science/brit-
cruise/cryptography/v/diffie-hellman-key-exchange)

------
bashzor
I don't find it very surprising that you can see what domain someone's
visiting; the system always needs to lookup the domain in a DNS query.

~~~
majke
Say that to the Tor exit node :)

