SSL原理，SSL握手过程

约定不等于承诺〃 2021-09-28 09:40 627阅读 0赞

SSL原理

在一个网站部署了SSL证书之后，就相当于为这个网址配置两把密钥，一把叫做公钥，另一把叫做私钥。公钥的作用就是在用户将自己的信息留在这个网站时为这些信息加锁的钥匙，加了锁之后，这些信息就不能被轻易的读取，除非有专门的钥匙打开。而这把打开这个锁的钥匙，就是另一把密钥，也就是私钥。只有这把对应的私钥才可以打开公钥部下的锁，因此在这两把密钥的作用下，可以使客户的信息数据在网站中安全的传入并安全的浏览，不会被他人截取。

SSL消息按如下顺序发送：** **

1.Client Hello

客户发送服务器信息，包括它所支持的密码组。密码组中有密码算法和钥匙大小；

2.Server Hello

服务器选择客户和服务器都支持的密码组到客户。

3.Certificate

服务器发送一个证书或一个证书链到客户端，一个证书链开始于服务器公共钥匙证书并结束于证明权威的根证书。这个消息是可选的，但服务器证书需要时，必须使用它。

4.Certificate request

当服务器需要鉴别客户时，它发送一个证书请求到客户端。在网络程序中，这个消息很少发送。

5.Server key exchange

服务器当发送来的公共钥匙对钥匙交换不是很充分时，发送一个服务器钥匙交换消息。

6.Server hello done

服务器告诉客户完成它的初始化流通消息。

7.Certificate** **

假如服务器需要一个客户证书时，客户端发送一个证书链。(只有在服务器需要客户证书时)

**　**8.Client key exchange

客户产生用于对称算法的一个钥匙。对RSA客户用服务器公共钥匙加密这个钥匙信息并把它送到服务器。

9.Certificate verify

在网络程序中，这个消息很少发送，它主要是用来允许服务器结束对客户的鉴别处理。当用这个消息时，客户发送用密码函数的数字签名的信息到服务端，当服务端用公共钥匙解密这个消息时，服务器能够鉴别客户。

**　**10.Change cipher spec

客户发送一个消息告诉服务器改变加密模式。

**　**11.Finished

客户告诉服务器它已准备安全数据通信。

12.Change cipher spec

服务器发送一个消息到客户端并告诉客户修改加密模式。

13.Finished

服务器告诉客户端它已准备好安全数据通信。这是client-server握手协议最后一步。

**　**14.Encrypted data

客户同服务器用对称加密算法和密码函数，并用客户发送到服务器的秘密钥匙加密通信。

SSL握手过程

目的：

1. 客户端与服务器需要就一组用于保护数据的算法达成一致；   
　　　　2. 它们需要确立一组由那些算法所使用的加密密钥；   
　　　　3. 握手还可以选择对客户端进行认证。

过程：

1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；   
　　　　2. 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数；   
　　　　3. 客户端对服务器的证书进行验证(有关验证证书，可以参考数字签名)，并抽取服务器的公用密钥；然后，再产生一个称作pre\_master\_secret的随机密码串，并使用服务器的公用密钥对其进行加密(参考非对称加/解密)，并将加密后的信息发送给服务器；   
　　　　4. 客户端与服务器端根据pre\_master\_secret（随机密码串）以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。   
　　　　5. 客户端将所有握手消息的MAC值发送给服务器；   
　　　　6. 服务器将所有握手消息的MAC值发送给客户端。

![format_png][]

第5与第6步用以防止握手本身遭受篡改。设想一个攻击者想要控制客户端与服务器所使用的算法。客户端提供多种算法的情况相当常见，某些强度弱而某些强度 强，以便能够与仅支持弱强度算法的服务器进行通信。攻击者可以删除客户端在第1步所提供的所有高强度算法，于是就迫使服务器选择一种弱强度的算法。第5步与第6步的MAC交换就能阻止这种攻击，因为客户端的MAC是根据原始消息计算得出的，而服务器的MAC是根据攻击者修改过的消息计算得出的，这样经过检 查就会发现不匹配。由于客户端与服务器所提供的随机数为密钥产生过程的输入，所以握手不会受到重放攻击的影响。这些消息是首个在新的加密算法与密钥下加密 的消息。

刚才所描述的每一步都需要通过一条或多条握手消息来实现。在此先简要地描述哪些消息与哪几步相对应，然后详细描述每条消息的内容。下图描述了各条消息：

![format_png 1][]

第1步对应一条单一的握手消息，ClientHello。

第2步对应一系列SSL握手消息，服务器发送的第一条消息为ServerHello，其中包含了它所选择的算法，接着再在Certificate消息中发 送其证书。

最后，服务器发送ServerHelloDone消息以表示这一握手阶段的完成。需要ServerHelloDone的原因是一些更为复杂的握手变种还要在Certifacate之后发送其他一些消息。当客户端接收到ServerHelloDone消息时，它就知道不会再有其他类似的消息过来了，于是就可以继续它这一方的握手。

第3步对应ClientKeyExchange消息。

第5与第6步对应Finished消息。该消息是第一条使用刚刚磋商过的算法加以保护的消息。为了防止握手过程遭到篡改，该消息的内容是前一阶段所有握手 消息的MAC值。然而，由于Finished消息是以磋商好的算法加以保护的，所以也要与新磋商的MAC密钥—起计算消息本身的MAc值。

注意，上图中省略了两条ChangeCipherSpec消息。

SSL记录协议：

在SSL中，实际的数据传输是使用SSL记录协议来实现的。SSL记录协议是通过将数据流分割成一系列的片段并加以传输来工作的，其中对每个片段单独进行 保护和传输。在接收方，对每条记录单独进行解密和验证。这种方案使得数据一经准备好就可以从连接的一端传送到另一端，并在接收到的即刻加以处理。

在传输片段之前，必须防止其遭到攻击。可以通过计算数据的MAC来提供完整性保护。MAC与片段一起进行传输，并由接收实现加以验证。将MAC附加到片段 的尾部，并对数据与MAC整合在一起的内容进行加密，以形成经过加密的负载(Payload)。最后给负载装上头信息。头信息与经过加密的负载的连结称作 记录(record)，记录就是实际传输的内容。下图描述了传输过程：

![format_png 2][]

1.记录头消息：

记录头信息的工作就是为接收实现(receiving implementation)提供对记录进行解释所必需的信息。在实际应用中，它是指三种信息：内容类型、长度和SSL版本。长度字段可以让接收方知道 他要从线路上这取多少字节才能对消息进行处理，版本号只是一项确保每一方使用所磋商的版本的冗余性检查。内容类型字段表示消息类型。

2. SSL记录类型：

SSL支持四种内容类型：application\_data、alert、handshake和change\_cipher\_spec。

使用SSL的软件发送和接收的所有数据都是以application\_data类型来发送的，其他三种内容类型用于对通信进行管理，如完成握手和报告错误等。

内容类型alert主要用于报告各种类型的错误。大多数alert(警示)用于报告握手中出现的问题，但也有一些指示在对记录试图进行解密或认证时发生的错误，alert消息的其他用途是指示连接将要关闭。

内容类型handshake用于承载握手消息。 即便是最初形成连接的握手消息也是通过记录层以handshake类型的记录来承载的。由于加密密钥还未确立，这些初始的消息并未经过加密或认证，但是其 他处理过程是一样的。有可能在现有的连接上初始化一次新的握手，在这种情况下，新的握手记录就像其他的数据一样，要经过加密和认证。

change\_cipher\_spec消息表示记录加密及认证的改变。一旦握手商定了一组新的密钥，就发送change\_cipher\_spec来指示此刻将启用新的密钥。

各种消息协同工作：

正如我们所看到的，SSL是一种分层协议，它以一个记录层以及记录层上承裁的个同消息类型组成。而该记录层又会由某种可靠的传输协议如TCP来承载。下图描述了该协以的结构：

![format_png 3][]

![format_png 4][]

SSL单向认证过程

![70][]

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息

2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3、客户端使用服务端返回的信息验证服务器的合法性，验证通过后，则继续进行通信，否则终止通信，验证内容包括:

a、证书是否过期

b、发行服务器证书的CA是否可靠

c、返回的公钥是否能正确解开返回证书中的数字签名

d、服务器证书上的域名是否和服务器的实际域名相匹配

4、客户端向服务器发送自己所能支持的对称加密方案，供服务器进行选择

5、服务器在客户端提供的加密方案中选择加密程度最高的加密方式

6、服务器将选择好的加密方式通过明文方式返回给客户端

7、客户端接收到服务器返回的加密方案后，使用该加密方案生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器

8、服务器收到客户端返回的加密信息后 ，使用自己的私钥进行解密，获取对称加密密钥。在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中的信息安全。

SSL双向认证过程

![70 1][]

1、客户端向服务器发送连接请求（SSL协议版本号、加密算法种类、随机数等信息）

2、服务器给客户端返回服务器端的证书，即公钥证书，同时也返回证书相关信息（SSL协议版本号、加密算法种类、随机数等信息）

3、客户端使用服务端返回的信息验证服务器的合法性（首先检查服务器发送过来的证书是否是由自己信赖的CA中心所签发的，再比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户端认可这个服务端的合法身份），验证通过后，则继续进行通信，否则终止通信，具体验证内容包括:

a、证书是否过期  
     b、发行服务器证书的CA是否可靠  
     c、返回的公钥是否能正确解开返回证书中的数字签名  
     d、服务器证书上的域名是否和服务器的实际域名相匹配

4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端

5、验证客户端的证书，通过验证后，会获得客户端的公钥

6、客户端向服务器发送自己所能支持的对称加密方案，供服务器端进行选择

7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

8、将加密方式通过使用之前获取到的公钥（客户的公钥）进行加密，返回给客户端

9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后获取该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端

10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全

SSL单向认证和SSL双向认证的区别

SSL单向认证只要求站点部署了SSL证书就行，任何用户都可以去访问（IP被限制除外等），只是服务器提供了身份认证。SSL双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户去访问，安全性相对高一些。

双向认证SSL协议要求服务器和用户双方都有证书。单向认证SSL协议不需要客户拥有CA证书，只需将服务器验证客户证书的过程去掉，以及在协商对称密码方案、对称通话密钥时，服务器发送给客户的是没有加过密的（这并不影响SSL过程的安全性）密码方案。这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够安全，这也是强调使用128位加密通讯的原因。

一般Web应用都是采用SSL单向认证的，原因很简单，用户数目广泛，且无需在通讯层对用户身份进行验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端（相对而言）做身份验证，这时就需要做SSL双向认证。

参考：[https://www.cnblogs.com/zimmer/p/4343632.html][https_www.cnblogs.com_zimmer_p_4343632.html]

[https://blog.csdn.net/qq\_31825569/article/details/79956967][https_blog.csdn.net_qq_31825569_article_details_79956967]

[https://blog.csdn.net/liuhuai12345/article/details/51657996][https_blog.csdn.net_liuhuai12345_article_details_51657996]

[format_png]: /images/20210923/02c8445176e84b749401fd844d4cf774.png
[format_png 1]: /images/20210923/a20a5ce213a546e58596625b6056db88.png
[format_png 2]: /images/20210923/c6ecce6586234556ab6182575bb338ca.png
[format_png 3]: /images/20210923/9a1c8bad854e47f8a28109e92424c39c.png
[format_png 4]: /images/20210923/6dec492cbb554f9886970af9bc81f378.png
[70]: /images/20210923/f8b12aca75474bab9f0b878c1a9f036b.png
[70 1]: /images/20210923/7afb365e43934d97b03703eeb906e69b.png
[https_www.cnblogs.com_zimmer_p_4343632.html]: https://www.cnblogs.com/zimmer/p/4343632.html
[https_blog.csdn.net_qq_31825569_article_details_79956967]: https://blog.csdn.net/qq_31825569/article/details/79956967
[https_blog.csdn.net_liuhuai12345_article_details_51657996]: https://blog.csdn.net/liuhuai12345/article/details/51657996