HTTPS如何通过非对称加密传输对称密钥，CA的作用

戲子鬧京城°ぃ

已于 2023-01-04 16:36:17 修改

阅读量1.1k

点赞数 3

分类专栏：网络文章标签：网络 https 服务器

于 2022-07-10 21:13:46 首次发布

本文链接：https://blog.csdn.net/weixin_59280309/article/details/125710811

版权

网络专栏收录该内容

14 篇文章 0 订阅

订阅专栏

非对称加密传输对称密钥过程：

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

上图随机数R视为被传输的对称密钥。

我的单钥匙 M：用来之后我和小宇对称加锁方式通信用的，需要想办法安全传给小宇

小宇的双钥匙 CD：用来让我安全把 M 传给她，做法是把公开的钥匙 D 传给我，我用钥匙 D 加锁我的 M，这样只有她才能用自己的保密钥匙 C 解开，中间人无法得知。

坏蛋的双钥匙 XY：用来传给我伪造的钥匙 Y 让我误以为这是小宇传给我的钥匙 D。

班长的双钥匙 JK：用来加锁小宇的钥匙 D，防止中间的坏蛋篡改这个值。

这在安全领域，分别对应对称加密，非对称加密。

单钥匙就是对称加密，对称加密的速度很快，可以用于传输过程中的数据加密，防止中间人查看和篡改信息。但是如何将对称加密的秘钥安全传递过去，是个问题。

双钥匙就是非对称加密，非对称加密的速度慢，可以用于加密少量数据，同时也可以用于签名防止篡改，为什么呢？看后面。

非对称加密的秘钥中，公开让别人知道的就是公钥，比如小宇的钥匙 D 或班长的钥匙 K 等。

留在自己这里不让别人知道的就是私钥，比如小宇的钥匙 C 或班长的钥匙 J 等。

既可以用私钥加密数据，公钥解密数据。也可以用公钥加密数据，私钥解密数据。

公钥加密，私钥解密，这个叫加密，是为了保证内容安全，因为私钥只有自己知道，是为了保证这个信息不被中间人解开。

私钥加密，公钥解密，这个叫签名，是为了防止内容被篡改，因为公钥所有人都知道，所有人都能看到这个信息做验证。

CA的作用：

CA中心，即证书授权中心(Certificate Authority )，或称证书授权机构，作为电子商务交易中受信任的第三方。

包含：

用户身份信息

用户公钥信息

身份验证机构的信息及签名数据

数字证书分类：

签名证书----身份验证，不可抵赖性。

加密证书----加密，完整性与机密性。

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

一、TLS握手过程

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

所以安全上存在以下三个风险：

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险

二、RSA密钥协商握手过程

TLS 第一次握手

客户端首先会发一个「Client Hello」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。

TLS 第二次握手

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，还有选择压缩算法（安全性原因，一般不压缩），以及生成随机数（*Server Random*）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

这个密码套件有固定格式和规范的。基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」，一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是：

由于 WITH 单词只有一个 RSA，则说明握手时密钥交换算法和签名算法都是使用 RSA；
握手后的通信使用 AES 对称算法，密钥长度 128 位，分组模式是 GCM；
摘要算法 SHA256 用于消息认证和产生随机数；

TLS 第三次握手

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

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

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

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

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

可以发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

TLS 第四次握手

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

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

客户端验证证书

但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：

对于这种三级层级关系的证书的验证过程如下：

客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。
请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书是否已预载于根证书清单上。如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。
“GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。

总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。