1. 记录协议

TLS记录协议为TLS连接提供了两个安全服务：机密性和消息完整性。机密性通过对称密码加密SSL载荷实现，消息完整性通过对SSL载荷计算其消息认证码MAC实现。对称密码的密钥和MAC的密钥都是由握手协议确定的。

图7-2给出了TLS记录协议的整个操作。第一步是分段，每一个上层消息都被分成214字节或更少的块。第二步是对每块数据压缩，这一步是可选的。下一步计算压缩数据块的MAC并添加到数据块后面。接下来使用对称密码加密添加了MAC的数据块。最后一步是附加一个头部，其中包含版本和长度字段。

图7-2　TLS记录协议的操作

记录协议操作的内容类型包括改变密码规范协议、报警协议、握手协议、心跳协议和应用数据。前4种属于TLS协议，后面会讨论。需要注意的是，记录协议并不区分各种使用TLS的应用数据，由这些应用创建的数据的内容对TLS来说是不透明的。

处理后的数据利用TCP传输。目的端收到数据后，经过解密、验证MAC、解压缩和重新组合，完整的数据被交付给上层应用。

2. 改变密码规范协议

改变密码规范协议是使用TLS记录协议的4个TLS协议之一，也是最简单的协议。这个协议只包含一个消息，由一个值为1的一个字节组成。这个消息的唯一目的，是使挂起状态被复制到当前状态，而这会更新这个连接上使用的密码套件。

3. 报警协议

报警协议用于向对等实体传达与TLS相关的警告。如同其他使用TLS的应用，根据当前状态的规定，报警协议也会被压缩和加密。

报警协议的每一个消息由两个字节组成。第一个字节表示严重性，用值1表示警告（Warning），用2表示致命（Fatal）。如果级别是致命，则TLS立即终止连接。同一个会话中的其他连接可以继续，但是不会在这个会话中建立新的连接。第二个字节包含一个表明特定报警的代码。一个致命报警的例子是发现了不正确的MAC。一个非致命报警的例子是Close_notify消息，这个消息通知接收方本次连接中的发送方不再发送任何消息。

4. 握手协议

握手协议是TLS协议最复杂的部分。这个协议让服务器和客户端相互验证彼此的身份，并协商加密算法和MAC算法，以及用于保护TLS记录协议中发送的数据的密钥。握手协议在任何应用数据被传送之前使用。

握手协议包括一系列客户端和服务器之间交换的消息。图7-3显示了在客户端和服务器之间建立一个逻辑连接所需要的最初的消息交换。这个过程可分成四个阶段。

图7-3　TLS握手协议过程

第一阶段用于初始化一个逻辑连接，并建立与之关联的安全能力。客户端向服务器端发送一条Client_hello消息，它包含以下参数：(www.daowen.com)

（1）版本：客户端所支持的最高TLS版本。

（2）随机数：一个客户端生成的随机结构，包括一个32 bit的时间戳和由安全随机数生成器产生的28 Byte随机数。这些值在密钥交换期间用于防止重放攻击。

（3）会话ID：一个长度可变的会话标识符。值为非零时表示客户端希望更新一个已经存在的连接的参数，或者在这个会话上创建一个新的连接。值为0表示客户端希望在一个新的会话上创建一个新的连接。

（4）密码套件：这是一个客户端支持的密码算法组合列表，按照优先选用的递减顺序排序。列表中的每一个密码套件定义了一个密钥交换算法和一个密码规范（CipherSpec）。TLS支持的密钥交换算法如RSA、某种形式的Diffie-Hellman。TLS支持的密码规范包括的字段有密码算法（如DES、3DES、RC4、IDEA等）、MAC算法（如MD5、SHA-1）、密码类型（流密码或块密码）、散列值长度（0 Byte、16 Byte或20 Byte）等。

（5）压缩方法：这是一个客户端支持的压缩方法列表。

当客户端发出Client_hello消息后，客户端等待服务器的Server_hello消息，该消息包含了与客户端Client_hello消息同样的参数，但是参数值有变化。对于Server_hello消息，版本参数包含客户端建议的较低版本和服务器支持的最高版本。随机数参数由服务器生成并且与客户端的随机数参数无关。如果客户端的会话ID参数是非零值，则服务器也会使用这个值；否则服务器的会话ID参数将包含一个新的会话ID值。密码套件参数包含服务器从客户端建议的密码套件中选择的一个密码套件。压缩方法参数包含服务器从客户端建议的压缩方法中选择的一个压缩方法。

第二阶段的细节依赖于所使用的公钥密码方案。如果需要被认证（身份验证），服务器首先向客户端发送它的证书，这个消息包括一个X.509证书或一个X.509证书链。如果需要的话，服务器接着会发送额外的密钥信息。在某些情况下，服务器也会向客户端请求证书。第二阶段最后一条消息，也是必须有的消息，是Server_hello_done消息。这个消息由服务器发出，用于告诉客户端服务器的Hello消息及其他相关消息结束。发出这个消息后，服务器将等待客户端的响应。

在第三阶段，收到服务器的Server_hello_done消息后，客户端应该核实服务器是否提供了合法的证书（如果需要的话），并检查Server_hello消息中的参数是否可以接受。如果所有这些都满足，根据所使用的公钥密码方案，客户端将向服务器返回一条或多条消息。如果服务器请求了证书，客户端将发送一个证书消息作为这个阶段的开始。如果没有合适的证书可用，客户端就发送一个No_certificate警报消息。接下来客户端向服务器发送一个Client_key_ exchange消息，它是这个阶段必须发送的消息，消息的内容依赖于密钥交换的类型。最后，客户端发出一个Certificate_verify消息，指示对客户端证书进行明确验证。仅当客户端证书具有签名功能时才会发送该消息。

第四阶段完成安全连接的建立。客户端发送一个Change_cipher_spec消息，将挂起的CipherSpec复制到当前的CipherSpec中。注意，这个消息并不属于握手协议，而是使用改变密码规范协议发送的。之后，客户端立即在新的算法、密钥及其他秘密值之下发送Finished（结束）消息。Finished消息用于核实密钥交换和认证过程是成功的。

作为对客户端发送的这两个消息的回应，服务器发送它自己的Change_cipher_spec消息，将挂起的CipherSpec转移当前的CipherSpec，并发送它自己的Finished消息。到此，握手过程结束。客户端和服务器可以开始交换应用层数据了。

5. 心跳协议

在计算机网络中，心跳是指由硬件或软件产生的周期性的信号，用于表明操作正常，或用于同步系统的其他部分。心跳协议常常用来监视一个协议实体的可用性。对于SSL/TLS协议，心跳协议在2012年确定。

心跳协议运行在TLS记录协议之上，包括两个消息类型：Heartbeat_request（心跳请求）和Heartbeat_response（心跳响应）。心跳协议的使用是在握手协议的第一阶段确定的。每个对等端都要表明它是否支持心跳。如果支持，则对等端要指出它是否愿意接收Heartbeat_request消息并使用Heartbeat_response消息进行响应，或仅愿意发送Heartbeat_request消息。

Heartbeat_request消息可以在任何时候发送。无论何时收到该请求消息，都应及时地用相应的Heartbeat_response消息回复。Heartbeat_request消息包括载荷长度、载荷和填充字段。载荷是一个长度介于16 Byte～64 KByte的随机内容。对应的Heartbeat_response消息必须包括接收的载荷的精确副本。填充字段也是随机内容。填充字段让发送方能够发现一条路径的最大传输单元（MTU）：通过发送不断增加填充的请求，直到不再有回应（因为路径上的某台主机无法处理那条消息）。

心跳有两个目的。第一，它向发送方确保接收方还活着，即使底层的TCP连接可能已经有一段时间没有任何活动了。第二，连接空闲期间，心跳会在连接上产生活动，这可以避免禁止空闲连接的防火墙关闭连接。

对载荷交换的要求被设计到心跳协议中，以支持其在无连接的TLS版本（即DTLS，Datagram Transport Layer Security）中使用。因为无连接服务会丢失数据包，载荷使得请求者能够将响应消息与请求消息进行匹配。为简单起见，相同版本的心跳协议与TLS和DTLS一起使用，因此，TLS和DTLS都需要有载荷。