5

If I understand correctly, SSL/TLS doesn't just encrypt traffic, but also offers a framework for (optionally?) authenticating servers and clients.

So, if I, for example, open an HTTPS connection through Tor, could the SSL/TLS handshake give away any information about my identity to the HTTPS-server that I am connecting to? Like my local IP address, or some other unique ID that it assigns to my system, etc...

Could this depend on the connection settings used? If so, is there a way to configure Java's SSLEngine to make sure that it doesn't leak any information about the system it is running on?

migrated from crypto.stackexchange.com May 19 '18 at 8:54

This question came from our site for software developers, mathematicians and others interested in cryptography.

9

TLS always authenticates the server (except in some variants that are never used on the web because they're only useful in very specific environments). This is necessary because if neither party authenticates the other, then they cannot ensure that they have an encrypted connection, as opposed to each having an encrypted connection to a man-in-the-middle who decodes and forwards the traffic. The server in an HTTP connection is not anonymous anyway.

TLS only authenticates the client if the client offers to be authenticated. This feature is not commonly used on the public web, mostly on intranets, and more commonly with protocols other than HTTP (for example email clients). Your client is not going to accidentally send a certificate that authenticates it: it would have to create a certificate first, and it would typically not use the same certificate with another client. Of course if you use a client program that you don't trust, it may reveal information about you, but doing it by creating and using a client certificate is a very unlikely method.

TLS itself doesn't send any directly identifying information about the client, but like with any other layer of the protocol it can reveal information indirectly through fingerprinting. The fingerprinting of a TLS client is mostly about which features it advertises to the server (which cryptographic algorithms and optional protocol features it supports). For anonymity, your best bet is to stick with the Tor browser in its default configuration, so that your fingerprint matches the fingerprint of everyone else using the same configuration. If you use another client, then sticking to that client's default will likewise usually minimize the information leaked through fingerprinting.

0

In the scenario of using Tor, the first node you connect to will have your source IP address since it needs to know where to send the return packets to. As far as I know Tor relay nodes do not assign any unique identifiers to hosts. The anonymity of Tor does not come from the use of SSL/TLS but from funneling your traffic through 3 points in order to obfuscate your IP.

Direct connections with servers using SSL/TLS, you still will have your source IP address being revealed. Added to that, anyone sniffing may also be able to identify the site you are visiting (even if they can not decrypt the packets), i.e. SNI field of the handshake. This will degrade anonymity since it will allow a profile of the person to be built.

Keep in mind that SSL/TLS does not primarily aim to provide anonymity. Anonymity is achieved through the practice of disciplined behavior and tools/protocols (with SSL/TLS being one of them). A compromise in any part can leak information. This is why true anonymity is nearly impossible.

On its own, SSL/TLS can leak information and be used to build a profile about a user. Used in conjunction with other tools it can provide a powerful layer of security to your anonymity (i.e. using SSL/TLS through privacy focused OSes like Tails or Qubes).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.