TLS / SSL
The encryption that protects HTTPS traffic, which a proxy tunnels through untouched rather than reading.
TLS, the successor to SSL, is the encryption behind the padlock in a browser. It secures the connection between you and a website so no one in between can read or alter it. Almost all web traffic now runs over it, which shapes what a proxy can and cannot do.
Because TLS is end-to-end between you and the destination, an HTTP proxy cannot read inside an HTTPS request; it opens a tunnel with the CONNECT method and passes the encrypted stream through blind. This is a feature, not a limit: it means the proxy relays your secure traffic without being able to see your data.
TLS also leaves a fingerprint, the specific way a client negotiates the encryption, which detection systems increasingly use. That is a separate topic from the encryption's protective job, and the one that makes the TLS handshake interesting to anyone thinking about how proxied traffic is identified.
The naming causes more confusion than it should. SSL was the original protocol, superseded by TLS in the 1990s, and every version of SSL has been deprecated for years as insecure. What everyone still calls an SSL certificate is a TLS certificate, and a service advertising SSL almost certainly means TLS. The current versions in use are TLS 1.2 and TLS 1.3, and the older name simply refused to die.
What is worth understanding about the proxy relationship is precisely how much the operator can still see, because people over-estimate the protection in one direction and under-estimate it in the other. The contents of your requests and responses are genuinely unreadable. But the hostname you asked to connect to travels in the CONNECT request in the clear, and so do the timing and volume of your traffic. That is meaningful metadata, and it is why the operator's identity still matters on encrypted connections.
TLS 1.3 improved this somewhat by encrypting more of the handshake itself, and further work aims to conceal the server name too, though deployment is uneven. For now, assume any intermediary knows where you went and when, even when it cannot know what you did there.
The genuinely useful thing to take away is that TLS protects you from the proxy and simultaneously exposes you to the destination. It stops the operator reading your data, and the ClientHello that opens every connection announces what your client is before a single encrypted byte flows. Same protocol, protection in one direction and identification in the other.
Frequently asked questions
What is the difference between TLS and SSL?
TLS replaced SSL, and every SSL version has been deprecated as insecure for years. The name survived in common usage, so an SSL certificate is a TLS certificate and a service advertising SSL support means TLS. The versions actually in use today are TLS 1.2 and TLS 1.3.
Can a proxy see my HTTPS traffic?
Not the contents. It relays encrypted bytes it cannot read. It does see the hostname you asked to reach, because that travels in the CONNECT request before encryption begins, along with the timing and volume of your traffic. That metadata is substantial, which is why an operator's trustworthiness matters even on encrypted connections.
Does TLS protect me from the proxy operator?
From reading your data, yes, and that is a real protection. From knowing where you went and when, no. If a proxy setup requires you to install its certificate, that protection is gone entirely, because it can then decrypt everything, which is exactly how corporate inspection proxies work and why installing one is not a small decision.
Why does TLS matter for detection if it is encrypted?
Because the opening message of the handshake is sent in the clear. Your client announces which versions, cipher suites and extensions it supports, and in what order, before anything is encrypted. That declaration differs between browsers and libraries, which makes it a fingerprint, and it is read before your request exists.
Back to the full glossary.