本文主要是介绍HTTPS 的安全通信机制，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

一. 基础知识

• SSL：一般情况下，网站使用的都是明文方式传输数据，但是在涉及到一些隐私信息时（如银行交易），这个时候网站就会跳转到 SSL，SSl的功能就是提供加密数据。这样的话，TCP/IP协议只要做好的自己的事情，数据加密就全权委托给SSL协议完成

• TLS:TLS是对SSL的扩展和优化，他可以提供数据安全的同时，确保数据的完整性

• HTTPS:超文本传输安全协议。就是http+ssl/tls,可以理解为安全版http

• 对称加密：对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据

• 非对称加密：使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密

• 证书认证：个人生成的公钥和私钥是不被信任的，只有经过CA认证后后才会被认为是可信任的密钥。目前大多浏览器都内置了国际知名CA的根证书中心，如果我们的密钥被CA中心签名过，那么就是合法的数字证书。但其CA验证密钥过程复杂，所以很多人使用自签名的数字证书

非对称加密使用的是公钥加密和私钥解密机制

二. 图解https的传输过程

• 客户端发送请求报文开始SSL通信，报文中包含客户端支持的SSL版本，加密组件列表。

• 服务器可进行SSL通信时会发送响应报文。

• 之后服务器发送Certificate报文，报文中包含公开密钥证书。

• 最后服务器发送报文通知客户端最初的SSL握手结束

• SSL第一次握手结束后，客户端会用服务器的公开密钥加密一段随机密码串传输给服务器。

• 接着客户端会继承发送报文提示服务器，在此报文以后的通信将使用之前发送过去的随机密码串进行加密处理。

• 最后客户端发送结束报文。

• 服务器同样发送报文提示客户端，在此报文以后的通信将使用客户端之前发送过来的随机密码串进行加密处理。

• 服务器发送结束报文。

• 服务器和客户端的结束报文交换完后，SSL连接建立完成，开始HTTP请求。

1. 客户端发起https请求，连接到服务端的443端口
2. 服务端采用的https有一套数字证书，这个证书可以自己配置，也可以像证书管理组织申请，证书的本质是公钥（发给任何人）和私钥（服务端保留）
3. 服务端将公钥传送证书传递给客户端，证书中包含了很多信息，比如证书的颁发机构，过期时间，网址，公钥等
4. 客户端解析证书，由客户端的TLS完成，首先会验证公钥是否有效，比如颁发机构，过期时间等。如果有异常，就会弹出警告信息。（这个我们上网应该遇到过，一般都是提示说该网站的证书不可信任，是否继续等）。证书没问题后会随机生成随机值（这个很重要，用于对称加密），然后使用第三步中的证书对这个随机值进行非对称加密
5. 将证书非对称加密后的随机值传到服务器
6. 服务器使用私钥对其进行非对称解密后，得到客户端的随机值，然后把内容通过该随机值进行对称加密
7. 服务端将对称加密后的信息发给客户端
8. 客户端用之前的生成的随机值来进行对称解密，获取内容明文

三. SSL通信机制说明

1. SSL/TLS概览

SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下:

2. 密钥协商过程——TLS握手

SSL协议分为两部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。

由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。

2.1 客户端发出请求（ClientHello）

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

综上，在这一步，客户端主要向服务器提供以下信息：

1. 支持的协议版本，比如TLS 1.0版
2. 一个客户端生成的随机数，稍后用于生成"对话密钥"
3. 支持的加密方法，比如RSA公钥加密
4. 支持的压缩方法

2.2 服务器回应（SeverHello)

上图中，从Server Hello到Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。

服务端在接收到客户端的Client Hello之后，服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。

此外，对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。

跟客户端一样，服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。

最后服务端会发送一个Server Hello Done消息给客户端，表示Server Hello消息结束了。

综上，在这一步，服务器的回应包含以下内容：

1. 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
2. 一个服务器生成的随机数，稍后用于生成"对话密钥"
3. 确认使用的加密方法，比如RSA公钥加密
4. 服务器证书

2.3 客户端回应（Certificate Verify）

Client Key Exchange

如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。

Certificate Verify
接着，客户端需要对服务端的证书进行检查，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥。然后，向服务器发送下面三项信息：

1. 一个随机数。该随机数用服务器公钥加密，防止被窃听
2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验

上面第一项的随机数，是整个握手阶段出现的第三个随机数，它是客户端使用一些加密算法(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个Key叫 PreMaster Secret，很多材料上也被称作 PreMaster Key。

ChangeCipherSpec
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

在ChangecipherSpec传输完毕之后，客户端会使用之前协商好的加密套件和Session Secret加密一段 Finish 的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

2.4 服务器的最后回应（Server Finish）

服务端在接收到客户端传过来的 PreMaster 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成 Session Secret，一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。

2.5 几个secret

PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

Master secret
上面已经提到，由于服务端和客户端都有一份相同的PreMaster secret和随机数，这个随机数将作为后面产生Master secret的种子，结合PreMaster secret，客户端和服务端将计算出同样的Master secret。

Master secret是有系列的hash值组成的，它将作为数据加解密相关的secret的 Key Material 的一部分。Key Material最终解析出来的数据如下：

其中，write MAC key，就是session secret或者说是session key。Client write MAC key是客户端发数据的session secret，Server write MAC secret是服务端发送数据的session key。MAC(Message Authentication Code)，是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。

2.6 应用数据传输

在所有的握手阶段都完成之后，就可以开始传送应用数据了。应用数据在传输之前，首先要附加上MAC secret，然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后，使用Client write encryption key进行解密，客户端收到服务端的数据之后使用Server write encryption key进行解密，然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

这篇关于HTTPS 的安全通信机制的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！