A secure transport connection has a setup moment and a working moment. During the handshake, participants negotiate, authenticate, and agree on symmetric keys. Afterward, the post-handshake phase uses those keys to encrypt their messages. section 9.2
The phase has a deliberately narrow job:
- Protect application communication with authenticated encryption. section 9.2
- Reuse the symmetric keys produced by the handshake instead of negotiating them for every message. section 9.2
- Carry ordinary secure communication after negotiation and authentication have completed. section 9.6
A browser connection
When a browser connects to a web server, the handshake establishes a secure connection and derives keys. The post-handshake phase then encrypts the browser's continuing traffic, such as requests and responses. section 9.2 section 9.6
Figure 9.1 At a high level, secure transport protocols first create a secure connection during a handshake phase. After that, applications on both sides of the secure connection can communicate securely.
The phase boundary is easiest to see as a two-step diagram: create the secure connection first, then communicate through it. section 9.2
This pattern appears beyond TLS. SSH, WPA, IPSec, and OpenVPN typically separate an initial handshake from later protected communication, although each adds its own details. Reimplementing the pattern carelessly can create serious weaknesses. section 9.4
