TLS | XB Field Notes

In a full certificate-based HTTPS handshake without early data, ClientHello SNI selects TLS configuration and certificate; later HTTP Host participates in request routing.

SNI lets one IP host many TLS sites

Server Name Indication (SNI) sends the requested hostname in the TLS handshake, letting one IP address serve different certificates and sites. Without SNI, separate addresses were one solution, but a shared certificate covering several subject alternative names (SANs) or an appropriate wildcard could also serve multiple sites. The problem is ordering: in a full certificate-based HTTPS handshake without early data, certificate selection precedes the encrypted HTTP request that identifies the application. ...

A signed issuer response is cached before the client checks it, with a limited freshness timeline.

OCSP stapling delivers status evidence under a client policy

OCSP stapling lets a TLS server deliver a signed certificate-status response during a handshake. A client that would otherwise make an online OCSP request may avoid that request. The saving depends on the client’s revocation policy: not every browser performs an OCSP lookup for every connection, and not every certificate issuer still operates an OCSP service. Stapling is one transport for status evidence, not a replacement for certificate validation. ...

An unbalanced Merkle tree combines leaves A and B on the left and C on the right under a trusted root. B is the target; A and C are its ordered proof siblings in the fixed synthetic tree.

Certificate transparency makes issuance observable

Certificate Transparency makes public TLS certificate issuance observable. It does not determine whether a domain owner authorized an issuance, replace certificate-chain validation, or guarantee that every certificate everywhere is logged. A misissued certificate can have valid transparency evidence. The benefit is a public trail that monitors and affected owners can investigate. ...

A time axis separates an earlier correctly authenticated fresh ECDHE session from later theft of the long-term signing key. That key alone cannot recover past secrets if the ephemeral secrets stayed private.

The forward-secrecy boundary of TLS ECDHE

Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe. ...

A TLS boundary protects the client-to-resolver connection. The selected resolver can read the DNS question, and later recursion is not automatically encrypted.

DoT and DoH protect the connection to the resolver you authenticate

DNS over TLS and DNS over HTTPS protect DNS traffic on the encrypted connection between their endpoints. For a typical client, that connection ends at the selected resolver. The resolver can read the question and answer, and its later queries may follow different transports. Encrypting this hop does not automatically encrypt every recursive exchange or make the resolver unable to log the names it handles. ...

A trusted client certificate and private-key proof lead to a separate application-policy fork: reader is allowed with HTTP 200 while a valid guest is denied with HTTP 403. Copied software keys can be used elsewhere, so hardware identity needs additional mechanisms.

Client certificates authenticate control of a private key

Mutual TLS authenticates a client’s control of a certificate’s private key as well as the server’s identity. It does not inherently identify a physical device. A copied software key can be used elsewhere; hardware binding and device attestation require additional mechanisms. An enrollment policy can associate a key with a device, but TLS alone does not establish that association. ...

TLS 1.3 full and resumed handshake cards both say normally one TLS RTT without early data. The full handshake uses certificate authentication; resumption uses accepted PSK authentication and renews keys. Optional 0-RTT data can be replayed.

TLS 1.3 resumption reuses authentication state

Saving a round trip depends on the protocol and early-data mode. In TLS 1.3, an ordinary full handshake and a resumed handshake without early data normally both take one TLS round trip. Resumption can still reduce certificate transmission and authentication work. Enabling tickets does not make every HTTPS request start one RTT sooner. ...

TLS handshakes add latency you can shrink

HTTPS latency combines several stages, and a warm request may avoid some without making cryptography faster. DNS, connection acquisition, TCP setup, TLS authentication, server work, and response transfer have different clocks. First determine which stages actually ran. Request duration alone cannot distinguish an existing connection from a new connection that resumed a TLS session. ...