HTTPS & SSL/TLS

What is HTTPS/TLS — and Why Does Every Other Security Mechanism Depend On It?

HTTPS is HTTP running over TLS (Transport Layer Security) — the same request/response protocol, but every byte on the wire is encrypted, integrity-checked, and tied to a verified server identity before a single header is exchanged. "SSL" is the name everyone still uses out of habit; the actual protocol has been TLS since 1999, and every version of SSL itself (2.0, 3.0) is now considered broken and disabled by every modern browser and server.

This matters to every other page in this section. A password sent over plain HTTP is readable by anyone on the network path. A JWT in an Authorization header is a bearer token — whoever has the bytes has the access, no password needed. A session cookie is exactly the same. None of the authentication mechanisms covered elsewhere in this Bible provide any protection on their own if the channel carrying them is not encrypted — TLS is not one security feature among several, it is the precondition that makes the others meaningful.

// BEFORE — checkout form posts over plain HTTP
@PostMapping("/checkout")
public ResponseEntity<OrderConfirmation> checkout(@RequestBody CheckoutRequest request) {
    // The session cookie, the JWT in the Authorization header, and the card
    // details in the request body all travel as plaintext bytes on the wire.
    // Any router, ISP, or Wi-Fi eavesdropper between browser and server can
    // read every one of them — no exploit required, just a packet capture.
    return orderService.process(request);
}

// AFTER — the channel itself is the control, enforced at the security layer
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .requiresChannel(channel -> channel.anyRequest().requiresSecure())
        .headers(headers -> headers.httpStrictTransportSecurity(hsts -> hsts
            .includeSubDomains(true)
            .maxAgeInSeconds(31536000)))
        .build();
    // Now the same checkout endpoint rejects plain HTTP outright, and every
    // subsequent visit is told by HSTS to never even attempt HTTP again.
}

The TLS Handshake — How Two Strangers Agree on a Secret

TLS solves a specific bootstrapping problem: the browser and the server have never spoken before and share no secret, yet they need to agree on a symmetric encryption key strong enough to protect an entire session — without an eavesdropper who sees every message being able to derive that same key. Asymmetric cryptography (the server's certificate key pair) solves the bootstrap; a symmetric cipher does the actual bulk encryption, because asymmetric operations are far too slow to encrypt every request and response.

/*
 * TLS 1.3 handshake (1 round trip — the current standard, RFC 8446):
 *
 * Client → Server : ClientHello (supported cipher suites, a key share)
 * Server → Client : ServerHello (chosen cipher suite, its own key share,
 *                                its certificate, a "Finished" message)
 *                   — both sides can now derive the same symmetric session key
 *                     from the exchanged key shares (Diffie-Hellman)
 * Client → Server : Finished — handshake complete, application data now flows,
 *                   already encrypted with the session key
 *
 * TLS 1.2 needed 2 round trips for the equivalent negotiation, and permitted
 * legacy cipher suites (RC4, static RSA key exchange with no forward secrecy)
 * that TLS 1.3 removed outright. This is why "downgrade attacks" — tricking
 * a client into negotiating TLS 1.0/1.1 or a weak cipher — were a real class
 * of vulnerability against 1.2 deployments and are largely closed by 1.3
 * refusing to offer the weak options at all.
 */

Certificates and the Chain of Trust

A TLS certificate (X.509 format) binds a public key to a domain name and is itself signed by a Certificate Authority (CA). The browser doesn't trust your certificate directly — it trusts a short list of root CAs baked into the OS or browser, and verifies a signature chain from your certificate up to one of those roots.

/*
 * The chain, leaf to root:
 *
 * shop.example.com certificate   ← the "leaf" cert, issued to your domain
 *        │  signed by
 *        ▼
 * Intermediate CA certificate    ← issued by the CA, rarely the root itself
 *        │  signed by
 *        ▼
 * Root CA certificate            ← pre-trusted, shipped with the OS/browser
 *
 * A server must send the leaf AND the intermediate certificate(s) — the root
 * is never sent, since the client already has it. Forgetting to include the
 * intermediate is one of the most common TLS misconfigurations: it works
 * fine in browsers that cache the intermediate from a previous visit to any
 * site using the same CA, and fails mysteriously for API clients, mobile
 * apps, and curl, which don't have that cache.
 */

Configuring HTTPS in Spring Boot

Two legitimate topologies exist, and conflating them is the source of most production TLS confusion.

Topology A — Spring Boot terminates TLS directly

# application.yml — the embedded Tomcat/Netty server holds the certificate
server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:keystore.p12
    key-store-password: ${KEYSTORE_PASSWORD}   # never hardcode — inject via environment/secrets manager
    key-store-type: PKCS12
    key-alias: shop-example-com
    protocol: TLS
    enabled-protocols: TLSv1.3,TLSv1.2   # explicitly exclude TLS 1.0/1.1

Topology B — TLS terminates upstream (load balancer / reverse proxy)

## nginx / ALB / Cloudflare terminates HTTPS; the app receives plain HTTP
## on a private network segment the public internet cannot reach directly.
## This is the far more common production setup — certificate rotation,
## OCSP stapling, and cipher policy are centralized at the edge instead of
## being redeployed with every service.

# application.yml — tell Spring the original request was HTTPS even though
# the connection it actually received was plain HTTP from the load balancer
server:
  forward-headers-strategy: framework   # trusts X-Forwarded-Proto / X-Forwarded-For

Enforcing HTTPS and HSTS at the application layer

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            // Reject any request that didn't arrive over HTTPS (or a trusted
            // X-Forwarded-Proto: https from the load balancer)
            .requiresChannel(channel -> channel.anyRequest().requiresSecure())

            // HSTS tells the browser to never attempt plain HTTP for this domain
            // again, for the given max-age — this closes the window where a
            // user typing "example.com" gets an initial plaintext request
            // that a network attacker could intercept before any redirect.
            .headers(headers -> headers
                .httpStrictTransportSecurity(hsts -> hsts
                    .includeSubDomains(true)
                    .preload(true)
                    .maxAgeInSeconds(31536000)   // 1 year — the realistic minimum for HSTS preload list eligibility
                )
            )
            .build();
    }
}

Mutual TLS (mTLS) — When the Server Also Needs to Verify the Client

Standard TLS only authenticates the server to the client — the browser verifies it's really talking to shop.example.com, but the server accepts connections from anyone. mTLS adds a second certificate check in the other direction: the client also presents a certificate, and the server verifies it against a trusted CA before accepting the connection. This is the right tool for service-to-service traffic where both parties are known in advance — the classic e-commerce example is your order service calling an internal payment or inventory service, or a payment provider's webhook endpoint verifying that a callback genuinely originated from the provider's infrastructure and not from a forged request.

# application.yml — require and verify a client certificate
server:
  ssl:
    enabled: true
    key-store: classpath:server-keystore.p12
    key-store-password: ${KEYSTORE_PASSWORD}
    trust-store: classpath:client-truststore.p12   # the CA that signs YOUR internal services' client certs
    trust-store-password: ${TRUSTSTORE_PASSWORD}
    client-auth: need   # NEED = reject the connection outright without a valid client cert

Common Misconfigurations

Best Practices and Common Pitfalls

Interview Questions