IPSec通过安全关联实现IP分组安全关联两端之间的安全传输过程，TLS通过建立安全连接实现数据在两个应用进程之间的安全传输过程。TLS建立安全连接时，实现安全连接两端应用进程之间的双向身份鉴别过程，保证经过安全连接传输的数据的保密性和完整性。TLS基于TCP建立两个应用进程之间的安全连接。
对于许多客户/服务器（Client/Server，C/S）应用结构，实现双向身份鉴别与保证相互交换的数据的保密性和完整性是非常重要的，如访问网络银行，一是需要通过双向身份鉴别防止用户登录伪造的银行网站，并因此泄漏账号、密码等私密信息；二是必须保证经过网络传输的私密信息的保密性和完整性。为了对客户和服务器之间传输的数据进行加密和源端鉴别，客户和服务器之间必须约定加密密钥和鉴别密钥、加密算法和鉴别算法等。
客户可以通过注册过程和服务器约定上述参数，如果这样，服务器必须为每一个注册客户保留上述安全参数，这一方面增加了服务器的存储负担，另一方面也增加了泄密这些安全参数的可能性。因此，有必要为每一次客户机和服务器之间的数据传输过程动态产生上述安全参数，而且这些安全参数在每一次数据传输过程结束后自动失效，这将大大增强客户机和服务器之间数据传输的安全性，但必须有一套用于完成双向身份鉴别和安全参数协商的协议，传输层安全（Transport Layer Security，TLS）就是这样一种协议。
TLS记录协议用于封装上层协议消息，通过TLS记录协议传输的上层消息可以实现源端鉴别、保密性和完整性。
TLS握手协议是一种实现身份鉴别和安全参数协商的协议。客户端和服务器端通过TLS记录协议传输数据前，需要通过TLS握手协议完成双向身份鉴别过程，并约定压缩算法、加密算法、MAC算法、加密密钥、MAC密钥等安全参数。
通信双方约定新的安全参数后，通过TLS改变密码规范协议通知对方开始使用新约定的安全参数。
报警协议用于传输出错消息，如解密失败、无法确认证书等。
通信双方第一次启动握手协议时，初始安全参数为不压缩、不加密、不计算MAC。
TLS记录协议
内容类型：上层消息类型，如TLS握手协议消息、HTTP消息等。
主版本号：对于TLS，固定为3。次版本号：对于TLS，固定为1。
压缩数据长度：加密操作前上层消息长度。
由于上层消息的长度可以任意，但TLS压缩后的数据的长度不能超过2''B，当单个TLS记录协议报文无法容纳上层消息时，必须对上层消息分段，保证每一段上层消息能够封装成单个TLS记录协议报文。如果通信双方需要对传输的数据进行加密和完整性检测，必须根据压缩后的数据计算消息鉴别码（MAC），并对压缩后的数据和MAC进行
加密运算，这就要求通信双方在进行如图6.17所示的封装过程前，必须通过TLS握手协议约定如下安全参数。
（1）压缩算法。用于压缩分段后的上层消息。
（2）加密算法。用于加密压缩后的数据和MAC，加密的目的是实现数据保密性。
（3）MAC算法。用于计算MAC，MAC的作用是实现源端鉴别和数据完整性。
（4）服务器端写密钥。服务器端加密数据和MAC时使用的密钥。
（5）客户端写密钥。客户端加密数据和MAC时使用的密钥。
（6）服务器端写MAC密钥。服务器端计算MAC时使用的密钥。
（7）客户端写MAC密钥。客户端计算MAC时使用的密钥。
（8）初始向量。采用分组密码体制的加密算法和加密分组链接（Cipher-Block Chaining，CBC）模式时，作为初始向量。
（9）序号。每发送一个TLS记录协议消息，序号增1，序号参与计算MAC过程。值得指出的是，服务器端至客户端传输方向和客户端至服务器端传输方向可以使用不同的加密密钥和MAC密钥。服务器端写密钥作为服务器端至客户端传输方向的加密密钥，服务器端写MAC密钥作为服务器端至客户端传输方向的MAC密钥。同样，客户端写密钥作为客户端至服务器端传输方向的加密密钥，客户端写MAC密钥作为客户端至服务器端传输方向的MAC密钥。
握手协议实现身份鉴别和安全参数协商过程
整个操作过程分为4个阶段，
阶段1：用于双方对压缩算法、加密算法、MAC算法及TLS协议版本达成一致。客户C在客户Hello消息中按优先顺序列出客户C支持的算法列表及TLS协议版本，服务器V从客户C支持的算法列表中按优先顺序选择一种自己支持的算法作为双方约定的算法，在双方支持的TLS版本中选择较低的TLS版本作为双方约定的TLS版本，并通过服务器 Hello 消息将双方约定的算法、TLS版本回送给客户C。
阶段2：验证服务器证书。用于完成对服务器V的身份鉴别。TLS支持多种鉴别服务器V身份的机制，这里以基于证书＋私钥的鉴别机制为例讨论:
服务器 V 身份鉴别过程。服务器 V 身份鉴别过程就是确认客户C访问的服务器V就是域名为
IDv的服务器的过程。基于证书＋私钥的鉴别机制鉴别服务器V身份的过程如下：服务器V向客
户C提供由认证中心颁发的IDv和公钥PKV绑定关系的证书
但确定公钥PKV和IDv的绑定关系并不能证明服务器v的绑定关系，只有在证明了服务器V拥有和公钥PKV对应的私钥SKV后，才能证明服务器V的域v。因此，阶段2并没有完成对服务器 V的身份鉴别。
阶段3：生成主密钥与验证客户证书
如果服务器V要求鉴别客户C的身份，阶段3一开始就由客户C通过客户证书消息向服务器V发送证书链，证书链包含的证书保证服务器V能够验证证明IDc和公钥PKC绑定关系的证书。
同样，客户C发送的证书链只能证明IDc和公钥PKC之间的绑定关系，要证明客户C的用户名为IDc，还需证明客户C拥有和公钥PKC对应的私钥SKC。
客户C为了确认服务器V拥有和公钥PKV对应的私钥SKV，用公钥PKV加密客户C选择的预主密钥（Pre-Master Secret，PMS）（Y=Exv（PMS）），并通过交换密钥消息将密文 Excv（PMS）发送给服务器V，由于预主密钥是计算其他密钥的基础，因此，只有双方具有相同的预主密钥才能保证双方产生相同的安全参数，而服务器V得到预主密钥的唯一前提是，拥有和公钥PKV对应的私钥SKV（Dxv（Y）=Dsxv（Exv（PMS））=PMS）。这就证明，只要双方成功协商安全参数，客户C访问的就是域名为IDv的服务器。
为了证明这一点，客户C发送的证实证书消息中包含客户C用私钥SKC对双方交换的握手协议消息的报文摘要进行解密运算后得到的密文（Y=Dxc（MD（握手协议消息））。由于服务器V保留了双方交换的握手协议消息，通过将对密文用PKC加密运算后的结果和自己对保留的双方交换的握手协议消息报文摘要运算后的结果进行比较，就可断定客户C是否拥有SKC。
阶段四：双方身份鉴别和安全参数切换
要证明服务器V拥有和公钥PKV对应的私钥SKV，只需证明服务器V得到了预主密钥PMS。要证明服务器V得到了预主密钥PMS，只需证明服务器V计算所得的主密钥 MK和客户C计算所得的主密钥MK相同。因此，服务器V向客户C发送的结束消息中包含PRF（MK，"server finished"，MD5（握手协议消息）|SHA-1（握手协议消息））计算结果，客户C根据自己计算所得的主密钥MK重新计算PRF（MK，"server finished"，MD5（握手协议消息）|SHA-1（握手协议消息）），如果计算结果和服务器V发送的结束消息中包含的计算结果相同，服务器V的身份得到确认，同时，也证明相互传输的握手协议消息的完整性。
