大家好，又见面了，我是你们的朋友全栈君。

• SSL协议为不同的高层协议(http、FTP)提供安全服务
• SSL握手协议、SSL修改密文协议和SSL告警协议的目的是为了 管理 和SSL相关的密文交换
• 连接：两台主机之间提供特定类型的数据传输，是点对点的关系；连接是短暂的，每一个连接都会和一个会话相互关联
• 会话：是指客户和服务器之间的关联，会话是通过握手协议创建的；会话是加密安全参数的一个集合，包含 加密算法、临时的加密密钥等信息；会话可以为多个连接所共享，就可以避免为每个连接建立都要进行安全参数的协商带来的昂贵的时间代价。如果服务器和客户端之间建立了多个安全的SSL连接，这些连接可以共享一个会话，也可以共享不同的会话。
• SSL协议提供  机密性和报文完整性两种服务

SSL握手协议

• 握手协议是客户机和服务器用SSL连接通信时使用的第一个子协议，握手协议包括客户机与服务器之间的一系列消息。SSL中最复杂的协议就是握手协议。该协议允许服务器和客户机相互验证，协商加密和MAC算法以及保密密钥，用来保护在SSL记录中发送的数据。握手协议是在应用程序的数据传输之前使用的。
• 每个握手协议包含以下3个字段
  • Type：表示10种消息类型之一
  • Length：表示消息长度字节数
  • Content：与消息相关的参数

SSL的流程(整体)

• 第一步，客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
• 第二步，服务器 确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
• 第三步，客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务器。
• 第四步，服务器使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。
• 第五步，客户端和服务器根据约定的加密方法，使用前面的三个随机数，生成”对话密钥”（session key），用来会话密钥对称加密接下来通信过程中的对话。

SSL的流程(拆分)

1.1 建立安全能力

• SSL握手的第一阶段启动逻辑连接，建立这个连接的安全能力。首先客户机向服务器发出client hello消息并等待服务器响应，随后服务器向客户机返回server hello消息，对client hello消息中的信息进行确认。
• Client hello消息包括Version，Random，Session id，Cipher suite，Compression method等信息。

ClientHello 客户发送CilentHello信息，包含如下内容：

• （1）客户端可以支持的SSL最高版本号
• （2）一个用于生成主秘密的32字节的随机数。（等会介绍主秘密是什么）
• （3）一个确定会话的会话ID。
• （4）一个客户端可以支持的密码套件列表。
• （5）一个客户端可以支持的压缩算法列表。

补充

•  密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。用“With”这个词把密钥交换算法、加密算法、散列算法分开，例如SSL_DHE_RSA_WITH_DES_CBC_SHA,表示把DHE_RSA(带有RSA数字签名的暂时Diffie-HellMan)定义为密钥交换算法；
• 把DES_CBC定义为加密算法；把SHA定义为散列算法。

 ServerHello 服务器用ServerHello信息应答客户，包括下列内容

• （1）一个SSL版本号。取客户端支持的最高版本号和服务端支持的最高版本号中的较低者。
• （2）一个用于生成主秘密的32字节的随机数。（客户端一个、服务端一个）
• （3）会话ID
• （4）从客户端的密码套件列表中选择的一个密码套件
• （5）从客户端的压缩方法的列表中选择的压缩方法

这个阶段之后，客户端服务端知道了下列内容：

• （1）SSL版本
• （2）密钥交换、信息验证和加密算法
• （3）压缩方法
• （4）有关密钥生成的两个随机数。

1.2 服务器鉴别与密钥交换

 服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：
（a）证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
（b）服务器密钥交换（可选）：这里视密钥交换算法而定
（c）证书请求：服务端可能会要求客户自身进行验证。
（d）服务器握手完成：第二阶段的结束，第三阶段开始的信号

补充

• 这里重点介绍一下服务端的验证和密钥交换。这个阶段的前面的（a）证书 和（b）服务器密钥交换是基于密钥交换方法的。而在SSL中密钥交换算法有6种：无效（没有密钥交换）、RSA、匿名Diffie-Hellman、暂时Diffie-Hellman、固定Diffie-Hellman、Fortezza。
• 在阶段1过程客户端与服务端协商的过程中已经确定使哪种密钥交换算法。
• 如果协商过程中确定使用RSA交换密钥，那么过程如下图：

•  这个方法中，服务器在它的第一个信息中，发送了RSA加密/解密公钥证书。不过，因为预备主秘密是由客户端在下一个阶段生成并发送的，所以第二个信息是空的。注意，公钥证书会进行从服务器到客户端的验证。当服务器收到预备主秘密时，它使用私钥进行解密。服务端拥有私钥是一个证据，可以证明服务器是一个它在第一个信息发送的公钥证书中要求的实体。

1.3 客户机鉴别与密钥交换：

客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：

• （a）证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。
• （b）客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。
• （c）证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。

 1.4 完成

• 客户机启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。

密钥生成的过程

• 这样握手协议完成，下面看下什么是预备主密钥，主密钥是怎么生成的。为了保证信息的完整性和机密性，SSL需要有六个加密秘密：四个密钥和两个IV。为了信息的可信性，客户端需要一个密钥（HMAC），为了加密要有一个密钥，为了分组加密要一个IV，服务也是如此。SSL需要的密钥是单向的，不同于那些在其他方向的密钥。如果在一个方向上有攻击，这种攻击在其他方向是没影响的。生成过程如下：

记录协议 

• 记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务：
• （1）保密性：使用握手协议定义的秘密密钥实现
• （2）完整性：握手协议定义了MAC，用于保证消息完整性

记录协议的过程：

3、警报协议

• 客户机和服务器发现错误时，向对方发送一个警报消息。如果是致命错误，则算法立即关闭SSL连接，双方还会先删除相关的会话号，秘密和密钥。每个警报消息共2个字节，第1个字节表示错误类型，如果是警报，则值为1，如果是致命错误，则值为2；第2个字节制定实际错误类型。

总结

• SSL中，使用握手协议协商加密和MAC算法以及保密密钥 ，使用握手协议对交换的数据进行加密和签名，使用警报协议定义数据传输过程中，出现问题如何去解决。

SSL/TLS握手过程可以分成两种类型：

• SSL/TLS 双向认证，就是双方都会互相认证，也就是两者之间将会交换证书。
• SSL/TLS 单向认证，客户端会认证服务器端身份，而服务器端不会去对客户端身份进行验证。

注意事项

• 生成对话密钥一共需要三个随机数。(客户端生成随机数、服务器生成随机数、客户端使用服务器公钥加密的随机数)；考虑到中间人攻击，中间人可以获得客户端生成随机数、服务器生成随机数和对称加密使用的算法，安全性完全依靠第三个加密的随机数（客户端使用服务器公钥加密的随机数）,尽管只要服务器的公钥足够长，破解的难度很大。因此部分 算法使用 DH密钥交换算法 ，参见 参考链接；不需要使用第三个参数，仅仅根据 先前传递的随机数 计算这个 随机数
• 握手之后的对话使用”对话密钥”加密（对称加密），服务器的公钥和私钥只用于加密和解密”对话密钥”（非对称加密），无其他作用。
• 服务器公钥放在服务器的数字证书之中。

•  第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数，然后双方各自算出Premaster secret。这样就提高了安全性

Session恢复

• 如果出于某种原因，对话中断，就需要重新握手。这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID

• session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。
• session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

session ticket 

• 客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了

参考链接

• SSL握手过程详解 – 简书
• 使用wireshark观察SSL/TLS握手过程–双向认证/单向认证_NowOrNever-CSDN博客
• 图解SSL/TLS协议_NowOrNever-CSDN博客
• DH密钥交换算法_NowOrNever-CSDN博客_dh算法
• SSL协议详解 – 麒麟 – 博客园