TLS secures communication between applications. A client initiates a connection to a server, and both negotiate a secure session that provides authentication, confidentiality, and message integrity. section 9.0 section 9.1.2
TLS divides its work into two phases:
- Handshake: negotiate parameters, authenticate the server, perform a key exchange, and derive symmetric keys. section 9.2 section 9.2.1
- Post-handshake communication: encrypt application messages with authenticated encryption and the keys produced by the handshake. section 9.2 section 9.2.2
- Certificate authentication: validate a server certificate chain against trusted root certificate authorities, commonly through a browser trust store. section 9.2.1
TLS 1.3 begins with ClientHello and ServerHello messages that negotiate key exchange, signature, hash, and authenticated-encryption algorithms. It uses ephemeral key exchange for session separation and can reduce latency by sending a speculative public key or, with a pre-shared key, encrypted 0-RTT data. section 9.2.1 section 9.2.2
A minimal TLS client
A Go client can dial google.com:443 with crypto/tls, obtain a secure connection, and close it after errors are handled. A TLS server can require TLS 1.3, attach TLS configuration to an HTTP server, and load cert.pem and key.pem. section 9.1.2
Prefer TLS 1.3 or TLS 1.2. Older SSL and TLS versions carry known vulnerabilities and demand difficult mitigations. Treat 0-RTT as replayable, use it only for safely replayable operations, and consider certificate or public-key pinning when you control the client. section 9.3 section 9.6
