SSL/TLS — What It Is, Protocols, and How Encryption Works

What is SSL/TLS?

SSL (Secure Sockets Layer) is a protocol developed by Netscape in 1995 to secure web traffic. The first version, SSL 1.0, was never publicly released; SSL 2.0 (1995) and SSL 3.0 (1996) were used until the early 2000s but contained critical vulnerabilities. SSL was succeeded by TLS (Transport Layer Security) — an improved version standardized by the IETF. TLS 1.0 (1999) was based on SSL 3.0, while subsequent versions TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018) gradually moved away from the original architecture, adding new encryption algorithms and fixing vulnerabilities. Today, SSL is considered obsolete, and all modern systems use TLS, although both protocols are often referred to together as SSL/TLS out of habit.

History of the Protocol

The history of SSL/TLS began with the need for secure data transmission in the early web. In 1994, Netscape developed SSL 1.0 for its Navigator browser, but the protocol was never published due to serious security issues. SSL 2.0 was released in 1995 and saw practical use, yet it contained numerous vulnerabilities: lack of protection against Man-in-the-Middle attacks, weak encryption algorithms, and susceptibility to truncation attacks. SSL 3.0 (1996) fixed most problems, but by 2014 the POODLE vulnerability was discovered, after which the IETF officially declared all SSL versions obsolete. TLS 1.0–1.3 progressively improved cryptographic strength, performance, and privacy, with TLS 1.3 reducing the handshake from two round-trips to one — critically important for mobile applications with unstable connections.

How SSL/TLS Handshake Works

Handshake is the process of establishing a secure connection between a client and a server. It consists of several sequential steps during which the parties agree on the protocol version, select encryption algorithms, exchange keys, and authenticate each other. In TLS 1.3, the handshake takes just one network round-trip (1-RTT), while TLS 1.2 required two (2-RTT).

The first step is the client sending a ClientHello — a message containing a list of supported TLS versions, cipher suites, and a random number. The server responds with a ServerHello containing the chosen version and cipher, its X.509 certificate, and a digital signature. The client verifies the certificate through the certificate authority (CA) chain, generates a session key, and sends it encrypted with the server's public key from the certificate. After confirmation from the server, secure data transmission begins. The entire handshake takes 1–3 milliseconds on modern devices, making it imperceptible to the user.

X.509 Certificates and the Chain of Trust

The foundation of TLS authentication is the Public Key Infrastructure (PKI) built on X.509 format certificates. Each certificate contains: a domain name (Common Name or Subject Alternative Name), the server's public key, the issuer name (Certificate Authority), an expiration date, and the CA's digital signature. The client verifies the server's certificate along the chain of trust: from the server certificate to the root CA, whose certificate is embedded in the operating system. On Android devices, root certificates are stored in the system keystore, updated via Google Play Services; on iOS — via iOS Updates. If any link in the chain is broken (expired certificate, domain mismatch, unknown CA), the client terminates the connection. For self-signed certificates (used in development), explicit trust is required — on Android via Network Security Config, on iOS via NSExceptionDomains in Info.plist. The certificate chain validation process also includes revocation status checking through CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol), although on mobile devices OCSP requests are often skipped to speed up the connection — this is a trade-off between security and performance that architects should consider.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()