TLS and HTTPS from Scratch

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 13 — TLS and HTTPS from Scratch. Alice, every developer knows they need HTTPS — HTTP over TLS, meaning the regular web protocol wrapped in an encrypted layer. What don’t they know?

Alice: They don’t know what’s actually happening when that padlock appears. They don’t know which cipher suites — the sets of encryption algorithms — their server negotiates. They don’t know whether their configuration provides forward secrecy. And they definitely don’t know what happens when their certificate expires at 3am on the night before a court filing deadline.

Dan: Let’s start with the basics. What is TLS actually doing?

Alice: TLS — Transport Layer Security — provides three things. Authentication — proving the server is who it claims to be. Confidentiality — encrypting the data so nobody between client and server can read it. Integrity — ensuring data isn’t modified in transit. The handshake establishes all three before any application data flows.

Dan: Walk me through what happens when a browser connects to a legal SaaS application over HTTPS.

Alice: TLS 1.3 — the current version, finalised in 2018. The client sends a ClientHello containing its supported cipher suites and a key share. The server picks a cipher suite, sends back its certificate and its own key share. The client validates the certificate chain — is it signed by a trusted CA — a Certificate Authority, a trusted organisation that verifies server identities and issues digital certificates — is the domain correct, has it expired, has it been revoked. If everything checks out, both sides derive session keys from the combined key shares. One round trip. Application data flows encrypted.

Dan: That’s faster than previous versions?

Alice: TLS 1.2 took two round trips. TLS 1.3 also removed all the insecure options — no more RSA key exchange — an older method of sharing encryption keys — no CBC mode ciphers — an older encryption technique with known weaknesses — no MD5 or SHA-1, which are outdated hash functions that can now be forged. The protocol only allows five cipher suites, all of them using AEAD — authenticated encryption with associated data, which provides both confidentiality and tamper-proofing in one operation. You literally cannot negotiate an insecure configuration in TLS 1.3.

Dan: What about forward secrecy? I hear that term a lot.

Alice: Forward secrecy means that even if your server’s private key is compromised tomorrow, every past session remains secure. This works because each connection uses ephemeral — temporary — Diffie-Hellman key pairs. Diffie-Hellman is a mathematical method that lets two parties agree on a shared secret over an insecure channel without ever transmitting the secret itself. The session keys are derived from these ephemeral keys, not from the server’s long-term key. Once the connection closes, the ephemeral keys are discarded. In TLS 1.3, forward secrecy is mandatory. In TLS 1.2, it depends on the cipher suite — RSA key exchange doesn’t provide it.

Dan: Let’s talk about certificates. Let’s Encrypt made them free — what’s the catch?

Alice: No catch, but a responsibility. Let’s Encrypt certificates expire every 90 days. That short lifetime is intentional — it forces automation and limits the damage window if a key is compromised. The ACME protocol — Automated Certificate Management Environment — automates the entire process — domain validation, certificate issuance, installation, renewal. Tools like Certbot handle this. But you must set up monitoring. If renewal fails silently and the certificate expires, your application goes down hard. Browsers don’t show a degraded warning anymore — they block access entirely.

Dan: Real-world example of that going wrong?

Alice: Microsoft Teams. February 2020. A certificate expired and the entire service went down globally. For hours. Now imagine that happening to your e-filing platform on a court deadline. The filing doesn’t go through because browsers refuse to connect. Your client’s motion is late. Opposing counsel moves for default judgement. And the root cause was — nobody set up a renewal alert.

Dan: What are the common misconfigurations you see in legal SaaS deployments?

Alice: Four big ones. First — still supporting TLS 1.0 or 1.1. These were formally deprecated in 2021. They have known vulnerabilities — BEAST, POODLE, Lucky 13 — these are named attacks that exploit weaknesses in how older TLS versions encrypt data, allowing attackers to gradually recover the contents of encrypted communications. An attacker can force a downgrade and exploit them. Disable completely. Second — weak cipher suites. RC4, DES, 3DES, CBC mode without proper MAC — Message Authentication Code, a check that data hasn’t been tampered with — — all exploitable. Only allow AEAD ciphers. Third — mixed content. Your HTTPS page loads a script over HTTP. That single HTTP script gives a man-in-the-middle — an attacker positioned between the user and the server who can intercept traffic — full control of the page. Fourth — no HSTS header, so the browser doesn’t enforce HTTPS and a network attacker can SSL-strip the connection — silently downgrading it from encrypted HTTPS to unencrypted HTTP.

Dan: What about legacy court systems? Some of them haven’t upgraded their TLS in years.

Alice: Never downgrade your main application to accommodate them. Instead — dedicated outbound proxy with strict network isolation. That proxy speaks TLS 1.0 to the legacy court system and TLS 1.3 to your application internally. Log every connection. Maintain a deprecation timeline. Communicate to court IT that their configuration has a hard deadline. Your security posture doesn’t degrade because one integration partner is behind.

Dan: How should teams test their TLS configuration?

Alice: Qualys SSL Labs Server Test. Free, web-based, gives you a letter grade A through F with specific findings. An A+ requires TLS 1.2 or higher only, ECDHE key exchange — Elliptic Curve Diffie-Hellman Ephemeral, the modern method for securely agreeing on encryption keys — AEAD ciphers, valid SHA-256 certificate, and HSTS configured. For CI/CD integration, testssl.sh runs from the command line — you can fail a deployment if the TLS grade drops below A.

Dan: What about TLS 1.3’s zero round-trip resumption? I’ve heard that has security tradeoffs.

Alice: It does. 0-RTT lets a returning client send application data in the very first packet — before the handshake completes. Great for performance. But that data is replayable. An attacker who captures a 0-RTT request can replay it. For legal SaaS — never allow state-changing operations in 0-RTT. Document sharing, payment processing, filing submissions — these must require the full handshake. Only idempotent reads should use 0-RTT.

Dan: Any other legal-specific considerations?

Alice: Certificate pinning for high-value client applications. If you build a dedicated portal for a major litigation client, you can pin your specific certificate in the app — so even if an attacker compromises a CA and issues a fraudulent certificate for your domain, the pinned app rejects it. This is high-assurance territory, appropriate for clients where the stakes justify the operational complexity.

Dan: The summary here — TLS isn’t set-and-forget.

Alice: It’s a living configuration. Certificates expire. Cipher suites get deprecated. Protocol vulnerabilities are discovered. Test regularly. Automate renewal. Monitor continuously. For legal SaaS carrying privileged communications, your TLS configuration is as critical as your authentication system.

Dan: Next episode — API Gateway Patterns and Rate Limiting. How a single enforcement point protects your entire API surface from abuse.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.