Protocols

What is SSL/TLS?

SSL and TLS are the protocols that encrypt and authenticate traffic between a client and a server. SSL is the deprecated original; TLS is what runs today, with TLS 1.2 and TLS 1.3 the only versions current software should negotiate. The handshake proves the server's identity with a certificate, then agrees the keys used for the session.

A connection opens with a ClientHello that lists the versions the client supports, its cipher suites, the elliptic curves and signature algorithms it accepts, and extensions including SNI, which names the target host in the clear so a server holding many certificates can choose one. The server replies with the suite it picked and its certificate chain, both sides derive keys, and application data follows. TLS 1.3 (RFC 8446) cut that to a single round trip, removed static RSA key exchange and renegotiation, and encrypts most of the handshake once the ServerHello has gone out.

SSL 2.0 and 3.0 are long dead, and RFC 8996 deprecated TLS 1.0 and 1.1, which browsers and CDNs now refuse. The SSL name survives in library names like OpenSSL and in everyday speech. Certificate validation is the half people forget. Encryption without checking the chain, the hostname and the expiry protects nothing against an active attacker, which is exactly the gap a TLS-inspecting middlebox uses when it re-signs traffic with a CA that the machine has been configured to trust.

For proxy users the ordering inside that ClientHello is what gets noticed. A TLS fingerprint such as JA3 or JA4 hashes the version, cipher list, extension list and curve list into a short identifier, and a request claiming to be Chrome while presenting the fingerprint of Python's ssl module is sorted out immediately. Rotating exit IPs changes nothing here, because the fingerprint comes from your client rather than from the network. That is why HTTP clients built to mirror a real browser's TLS stack exist at all.

Errors read differently depending on where the break sits. A certificate error names the chain or the hostname, while a handshake failure usually means the two sides have no cipher suite or protocol version in common. Running openssl s_client -connect host:443 -servername host prints the negotiated version, the full chain and the ALPN result. That settles most arguments in one command. Behind a CONNECT tunnel the proxy takes no part in the handshake, so a TLS error through a proxy is nearly always a client or origin problem.

Where you meet it

You touch TLS whenever a scraper fails on a page a browser loads without complaint. Check the negotiated version first, then the client fingerprint, which is where most automation gives itself away long before anyone reads its headers. Certificate pinning inside a mobile app is the other frequent wall, since intercepting that traffic with your own CA makes the app refuse to connect, which is the behaviour its developers intended.

Common questions

What is the difference between SSL and TLS?

They are the same idea at different ages. SSL was the original protocol from Netscape and its last version, SSL 3.0, is deprecated and unsafe. TLS is the standardised successor, currently at 1.2 and 1.3. When a product says SSL today it almost always means TLS; the older name outlived the protocol it named.

Can a website see my TLS fingerprint through a proxy?

Yes. The proxy relays the ClientHello unchanged, so the cipher suites, extensions and their ordering reach the origin exactly as your client wrote them. Changing IP address does not change the fingerprint. Matching a real browser requires an HTTP client or browser engine that produces the same handshake.

Should I still support TLS 1.2?

For a client, yes, since plenty of servers have not moved to 1.3. For a server you operate, supporting 1.2 and 1.3 covers nearly everything in use while keeping 1.0 and 1.1 disabled. Anything still requiring SSL 3.0 or TLS 1.0 is old enough that the compatibility problem is not yours to solve.

Related terms

HTTPS Proxy
An HTTPS proxy carries encrypted TLS traffic between a client and a destination site, usually by opening a tunnel with the HTTP CONNECT method to port 443. The proxy relays raw bytes without reading the request path, headers or body. The term also describes a proxy whose own listening port accepts a TLS-encrypted client connection.
TLS Fingerprint
A TLS fingerprint is an identifier derived from the ClientHello a client sends when it opens an HTTPS connection: the TLS version offered, the ordered cipher suite list, the extension list, supported elliptic curves and signature algorithms. JA3 and JA4 are the common encodings of it. Different HTTP clients and browsers produce visibly different values.
HTTP Proxy
An HTTP proxy is a server that forwards HTTP requests on a client's behalf, parsing the protocol rather than blindly relaying bytes. The client sends the full target URL in the request line, or issues a CONNECT to tunnel an HTTPS session. Proxies conventionally listen on ports such as 8080 or 3128; port 80 belongs to the origin web server.
SOCKS5
SOCKS5 is a session-layer proxy protocol, defined in RFC 1928, that relays TCP connections and can relay UDP datagrams for any application rather than only web traffic. It negotiates an authentication method first, then takes a target given as an IPv4 address, an IPv6 address or a domain name and forwards bytes without interpreting them.
SOCKS4
SOCKS4 is the earlier version of the SOCKS proxy protocol. It relays TCP connections only and addresses targets by raw IPv4 address, with no authentication beyond a user ID string the proxy may ignore. The SOCKS4a extension adds hostname support. SOCKS5 superseded it, and current clients keep SOCKS4 only for legacy endpoints.
HTTP/2
HTTP/2 is a binary version of HTTP that carries many concurrent requests as multiplexed streams over a single TCP connection and compresses headers with HPACK. It keeps HTTP's methods, status codes and header semantics unchanged, so only the wire format differs. Browsers negotiate it during the TLS handshake through ALPN, advertising the identifier h2.
HTTP/3
HTTP/3 is HTTP carried over QUIC, which runs on UDP and builds the TLS 1.3 handshake into the transport itself. It keeps HTTP semantics and HTTP/2-style multiplexing while removing TCP's head-of-line blocking, so a lost packet stalls only its own stream. Clients discover it from an Alt-Svc header or an HTTPS DNS record and negotiate it as h3.
QUIC
QUIC is an encrypted transport protocol that runs over UDP instead of TCP and carries HTTP/3 traffic, normally on UDP port 443. It combines the transport and TLS 1.3 handshakes into one exchange and multiplexes independent streams without head-of-line blocking. The protocol identifies a connection by an ID rather than by an address and port pair.

Real 4G/5G mobile and residential IPs

PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.

View pricing Browse the glossary