HTTPS原理---RSA密钥协商算法

HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。

HTTPS在HTTP与TCP层之间加入了TLS协议

 下面是RSA密钥协商算法的流程图

 

TLS第一次握手

客户端会发送一个Client Hello 的消息，其中会携带TLS版本、随机数、密码套件。

 

TLS 第二次握手

服务端收到客户端的Client Hello之后，会确认TLS版本号是否支持，并且从密码套件列表选择一个密码套件，以及生成随机数。

接着返回 Server Hello 消息，消息中有服务器确认的TLS版本号，也给出了服务器的随机数，然后还有密码套件。

密码套件基本形式 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法

TLS_RSA_WITH_AES_128_GCM_SHA256

 

接着服务端为了验证自己的身份，会发送Server Certificate 给客户端，这个消息里面含有数字证书。

随后服务端会发送Server Hello Done 消息告诉客户端已经把所所有东西都给它了

数据证书包含什么？

• 公钥；

• 持有者信息；

• 证书认证机构（CA）的信息；

• CA 对这份文件的数字签名及使用的算法；

• 证书有效期；

• 还有一些其他额外信息；

  那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

  为了让服务端的公钥被大家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

数据证书的签发和验证流程

 

• 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；

• 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；

• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

TLS 第三次握手

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (*pre-master*)，用服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

TLS 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了。