SSL（Secure Sockets Layer，安全套接字层）和TLS（Transport Layer Security，传输层安全协议）是工作在传输层与应用层之间的安全协议，其核心使命是为TCP连接提供端到端的数据加密、身份认证和数据完整性保护。通俗而言，当一个用户在浏览器地址栏输入以"https://"开头的网址时，浏览器与服务器之间建立的加密通道就是由TLS协议负责构建的。TLS是SSL的继任者，IETF于1999年在SSL 3.0的基础上发布了TLS 1.0，二者在协议框架上一脉相承，但在密码学细节和安全性上存在显著差异。
在TCP/IP协议栈中，TLS位于传输层（TCP）之上、应用层协议（HTTP、SMTP、IMAP、FTP等）之下。这一分层设计的精妙之处在于，TLS对上层应用完全透明——HTTP协议本身不需要任何修改，只需将通信端口从80切换到443，底层TCP连接上的所有数据就被自动加密。这种透明性是TLS能够大规模部署的关键原因。从OSI七层模型来看，TLS跨越了会话层和表示层的职能：它既要完成握手协商（会话层职责），又要执行数据加解密（表示层职责）。
SSL协议由网景公司于1994年创建，经历了1.0（未公开发布）、2.0和3.0三个版本。SSL 2.0存在严重的协议设计缺陷，包括缺乏对握手消息的完整性保护，导致中间人可以在不被察觉的情况下降级加密套件。SSL 3.0修补了大部分已知问题，引入了更健壮的握手协议，但其使用的RC4流密码和CBC分组加密模式后来也被证明存在BEAST攻击和POODLE攻击等漏洞。IETF接管后发布的TLS 1.0基本等同于SSL 3.1，但此后每个版本都有实质性改进：TLS 1.1增加了对CBC攻击的防护，为每个记录引入显式初始化向量；TLS 1.2是一次里程碑式升级，引入了对AEAD（带关联数据的认证加密）加密模式的支持，弃用了MD5-SHA-1混合哈希，允许双方协商哈希算法；TLS 1.3则是自TLS 1.0以来最彻底的协议重构，将握手往返时延从2-RTT压缩到1-RTT，删除了所有不再安全的旧式加密算法（包括RSA密钥交换、CBC模式、RC4等），强制使用前向安全。
软考中涉及TLS的考点，几乎全部基于TLS 1.2和TLS 1.3的特性。考生需要准确记住各版本的安全改进点，尤其是TLS 1.2与1.3的核心差异——后者删除了静态RSA密钥交换、引入了PSK（预共享密钥）和0-RTT模式，这些往往是选择题中区分选项的关键细节。
TLS握手是协议最为核心的环节，它的任务是在客户端和服务器之间协商一套双方都支持的加密参数，完成身份认证，并最终生成一组共享的会话密钥。整个握手过程可以拆解为几个清晰的阶段，每一阶段都有明确的密码学目的。
第一阶段是客户端发起协商。客户端发送ClientHello消息，携带三个关键信息：一是客户端支持的TLS最高版本号；二是客户端生成的32字节随机数，用于后续密钥派生；三是客户端支持的加密套件列表，按优先级排列，每个套件定义了一组算法组合——比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256表示使用ECDHE做密钥交换、RSA做身份认证、AES-128-GCM做对称加密、SHA-256做哈希。此外，ClientHello还可以携带支持的压缩方法列表、会话ID（用于会话恢复）以及扩展字段（如SNI服务器名称指示、支持的椭圆曲线列表、签名算法列表等）。SNI扩展是一个极其重要但常被忽略的细节：当一台物理服务器上托管多个HTTPS站点时，服务器在收到ClientHello之前还无法确定客户端要访问的是哪个站点，因此也无法选择合适的证书。SNI扩展通过在ClientHello中明文发送目标域名，使服务器能够在握手阶段就选择正确的证书。值得注意的是，在TLS 1.2中SNI是明文传输的，这意味着域名信息在握手阶段并未加密，存在隐私泄露风险，这一问题直到TLS 1.3的Encrypted SNI（ESNI）才部分解决。
第二阶段是服务器回应与证书交付。服务器收到ClientHello后返回ServerHello消息，确定了本次连接的三个参数：选定的TLS版本、服务器生成的另一个32字节随机数、以及从客户端列表中选定的一个加密套件。紧接着服务器发送Certificate消息，将其X.509数字证书链发送给客户端。证书链从服务器证书开始，逐级向上到中间CA，最终到客户端本地信任存储中的根CA。这个证书链的完整性和每一级的签名有效性是客户端验证服务器身份的基础。如果服务器要求验证客户端身份（双向认证），它还会发送CertificateRequest消息。接下来服务器发送ServerKeyExchange消息，这一步的内容取决于选定的密钥交换算法。如果选择的是ECDHE（椭圆曲线Diffie-Hellman临时密钥交换），服务器在此消息中发送其临时公钥，并用证书对应的私钥对关键参数进行数字签名——这个签名的存在使得客户端可以确认这些参数确实来自证书持有人，而非中间人伪造。最后服务器发送ServerHelloDone，表示本轮消息结束。
第三阶段是客户端密钥交换与验证。客户端在验证服务器证书链有效后，发送ClientKeyExchange消息，包含客户端临时生成的公钥参数。以ECDHE为例，客户端生成自己的临时椭圆曲线密钥对，将公钥通过此消息发送给服务器。此时，客户端已经拥有对方的临时公钥和自己的临时私钥，通过ECDH算法计算出一个共享秘密值，称为Pre-Master Secret。服务器收到ClientKeyExchange后也能计算出同样的Pre-Master Secret。接下来双方分别使用两个随机数（ClientHello.random和ServerHello.random）加上Pre-Master Secret，通过一个伪随机函数（PRF）派生出Master Secret，再从Master Secret派生出四把会话密钥：客户端写入加密密钥、服务器写入加密密钥、客户端写入MAC密钥、服务器写入MAC密钥。这种分别派生不同方向密钥的设计称为"密钥分离"，它防止了某种重放攻击——即使攻击者录制了客户端到服务器的加密流量，也无法将其回放为服务器到客户端的伪造消息。此后客户端发送ChangeCipherSpec消息，通知服务器后续所有消息将使用协商好的密钥加密。紧接着客户端发送Finished消息，这是第一条用新密钥加密的消息，其中包含此前所有握手消息的哈希值，服务器通过验证这个哈希确认握手过程没有被篡改。
第四阶段是服务器确认。服务器同样发送ChangeCipherSpec和Finished消息。双方各自验证对方的Finished消息后，握手正式完成，后续应用数据进入加密传输阶段。
密钥交换是TLS握手中密码学深度最高的环节，软考命题对这一部分的考察也越来越细致。TLS 1.2支持两大类密钥交换方式：RSA密钥交换和DH（Diffie-Hellman）族密钥交换。RSA密钥交换的原理是客户端生成Pre-Master Secret，用服务器证书中的RSA公钥加密后发送给服务器。这种方式简洁但存在致命弱点——不具备前向安全性。因为所有会话的Pre-Master Secret都依赖同一个服务器RSA私钥保护，一旦服务器的私钥在未来某个时间泄露，攻击者可以解密此前录制的全部历史会话。2013年斯诺登事件后，前向安全成为行业基本要求，RSA密钥交换在TLS 1.3中被彻底移除。
DH族密钥交换解决了前向安全问题。DH的基本思想是：双方在不安全的信道上交换公开参数，各自只需保留私钥，最终双方能独立计算出相同的共享秘密，而信道上的窃听者无法从公开参数推导出这个秘密。DHE（临时DH）在每次会话中生成全新的DH参数，即使服务器长期私钥泄露，历史会话也不受影响。ECDHE是DHE的椭圆曲线版本，在同等安全强度下提供更小的密钥尺寸和更快的运算速度，是目前主流的密钥交换方式。TLS 1.3仅保留ECDHE和DHE两种密钥交换方式，彻底告别了静态RSA。
完整的TLS握手需要两次往返（2-RTT），加上TCP三次握手的一次往返，一个全新的HTTPS连接在能够传输应用数据之前需要3-RTT的延迟。对于频繁访问同一站点的用户，这个开销不可忽视。TLS 1.2提供了两种会话恢复机制：基于Session ID的服务器端缓存方式，以及基于Session Ticket的无状态方式。Session ID机制下，服务器在首次握手完成后生成一个会话ID并发送给客户端，同时将会话参数保存在服务器本地。客户端下次连接时在ClientHello中携带这个会话ID，服务器查找到匹配的会话参数后即可跳过完整的握手。这种方式的局限在于需要服务器端存储，在负载均衡场景下各服务器之间共享会话状态成为一个工程难题。
Session Ticket机制将这个问题解决得更优雅：服务器将加密后的会话状态打包为一个Ticket发送给客户端，客户端下次连接时在ClientHello的SessionTicket扩展中携带这个Ticket。服务器使用仅自己持有的密钥解密Ticket后即可恢复会话，不需要任何服务器端存储。TLS 1.3进一步优化为PSK（预共享密钥）模式，支持0-RTT早班数据——客户端在发送ClientHello的同时就可以发送加密的应用数据，将首字节延迟压缩到1-RTT。但0-RTT有一个重要的安全代价：0-RTT数据不提供前向安全，且可能被攻击者重放，因此只适用于幂等的GET请求。
TLS协议在不同的安全需求场景下，认证模式和部署拓扑有显著差异。理解这些差异不仅是实际工作中配置HTTPS服务的基础，也是软考中区分认证场景类题目的关键。
最常见的HTTPS场景是单向认证——服务器向客户端出示证书证明自己的身份，客户端不需要证书。在这种模式下，ClientHello发起后，服务器发送Certificate消息，客户端使用本地信任存储中的根CA证书逐级验证证书链的有效性。验证通过后，客户端继续密钥交换流程。浏览器地址栏中的小锁图标、证书详情中的"颁发给"字段，都是单向认证体系下的安全界面。单向认证已经能够有效防御主动中间人攻击——攻击者无法伪造一个由受信任CA签发的目标域名证书。
双向认证（mTLS，mutual TLS）在此基础之上增加了客户端身份证明环节。服务器在Certificate消息之后发送CertificateRequest，要求客户端也出示证书。客户端随后在Certificate消息中发送自己的证书链，并在CertificateVer
本篇完！