Tls

Server Name Indication (SNI) sends the hostname during the TLS handshake, so one IP address can serve many different certificates and sites. Before SNI, the math was brutal: one certificate per IP, one IP per site, and IPv4 addresses spent like water. Name-based virtual hosting worked for plaintext HTTP but broke for TLS, because the server had to choose a certificate before the encrypted request revealed which site the client wanted. SNI resolves the paradox by moving the hostname earlier — into the handshake itself, ahead of encryption. ...

Pushing the check to the server removes a whole round trip and a separate request, though a missing staple still lets clients fall back and query. The server fetches once OCSP stapling is about the client skipping a validation round-trip. When a client checks a TLS cert, it would normally ask the CA’s OCSP responder ‘is this certificate still good?’ — a query that adds latency and a dependency on a Certificate Authority being reachable. With stapling, the server fetches that signed OCSP response once, caches it, and simply sends it along inside the TLS handshake (certificate_status extension). The browser no longer needs the extra network call, so validation gets cheaper and the failure modes of the OCSP responder stop slowing every handshake. ...

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. ...

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. ...

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. ...

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. Treat the title’s device identity as an enrollment policy, not something TLS establishes automatically. ...

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. The title is not a promise that enabling tickets makes every HTTPS request start one RTT sooner. ...

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. ...