What is SSL/TLS?

How SSL/TLS works

Every TLS connection begins with a handshake. The client sends a ClientHello message listing the protocol versions it supports, its cipher suites in preference order, and extensions such as SNI (Server Name Indication), which names the site being requested. The server picks the parameters, proves its identity with a certificate, and the two sides derive shared symmetric keys through a key exchange such as ECDHE.

Certificates provide the authentication half of the protocol. A certificate binds a hostname to a public key and is signed by a certificate authority (CA) that browsers and operating systems already trust. The client checks the signature chain, expiry dates, and hostname match before continuing; a failure produces the familiar browser security warning.

Once the handshake completes, application data flows through fast symmetric ciphers such as AES-GCM or ChaCha20-Poly1305. TLS 1.3, the current version, shortens the handshake to a single round trip and encrypts more of it, which improves both latency and privacy compared with TLS 1.2.

Why SSL/TLS matters for proxies and scraping

When HTTPS traffic passes through a proxy, the proxy normally tunnels rather than decrypts. An HTTP proxy opens a tunnel with the CONNECT method and then relays encrypted bytes without reading them; a SOCKS5 proxy does the same at a lower level. The proxy learns the destination hostname and port but not the content of requests or responses, so end-to-end encryption stays intact. Every ProxyOmega port accepts HTTP, HTTPS, and SOCKS5 traffic, so TLS-encrypted requests tunnel through without any special configuration.

The handshake itself is also a major fingerprinting surface. The exact contents of a ClientHello — cipher order, extension list, supported curves — form a TLS fingerprint (the JA3 hash is the best-known formula) that anti-bot systems compare against known browsers. A scraper using a non-browser HTTP library can be flagged by its TLS fingerprint before it sends a single HTTP header, no matter how clean its proxy IP is.

Practical notes and common misconceptions

The name SSL survives mostly in marketing. SSL 2.0 and 3.0 were retired years ago because of serious vulnerabilities, and what actually runs on modern servers is TLS 1.2 or 1.3 — an "SSL certificate" is really a TLS certificate.

A standard forward proxy cannot read HTTPS payloads. Decryption requires a TLS-intercepting proxy that terminates the connection and re-encrypts it with its own certificate, which only works if that certificate is installed on the client device — a setup used in corporate networks and debugging tools, not in commercial proxy services.