标签：TLS 公钥 加密 加解密 退钱 密钥 HTTPS 服务端 客户端

目录

• • 0. HTTPS
  • • 0.1. HTTPS解决了什么问题
    • 0.2. HTTPS如何解决问题
  • 1. 加密算法分类
  • 2. 工作机制解析
  • • 2.1. 选择加密算法
    • • 2.1.1. 对称加密
      • 2.1.2. 非对称加密
      • 2.1.3. 双向非对称加密
      • 2.1.4. 非对称加密 + 对称加密
    • 2.2. 身份认证
    • • 2.2.1. CA与数字证书
      • 2.2.2. 证书数据一致性
  • 3. 工作流程
  • • 3.1. SSL/TLS握手详细过程
    • • 3.1.1. 客户端发出请求（ClientHello）
      • 3.1.2. 服务器回应（SeverHello）
      • 3.1.3. 客户端回应
      • 3.1.4. 服务器回应
    • 3.2. HTTPS工作流程
  • 4. 总结

0. HTTPS

HTTPS是基于HTTP+TCP/IP，使用SSL/TLS来加密数据包的协议。关于通信模型分层及协议的关系可见上一篇文章，这里不再做阐述。

0.1. HTTPS解决了什么问题

众所周知，HTTPS是安全的 的HTTP，与HTTP相比，HTTPS提供了一下三个安全特性：

• 加密(Encryption)：通过可靠的数据加密使数据在传输过程中避免被窃听
• 数据一致性(Data integrity)：即数据的完整性，避免数据被篡改
• 身份认证(Authentication)：确认对方的身份，避免中间人攻击

0.2. HTTPS如何解决问题

HTTPS通过SSL/TLS实现了上述的三个安全特性。TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。SSL/TLS位于应用层与传输层之间。

1. 加密算法分类

SSL/TLS 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，非对称加密算法实现身份认证和生成会话密钥，对称加密算法使用会话密钥对数据加密，使用散列函数验证信息的完整性

算法	特点	应用	举例
非对称加密	1.两把密钥，公钥+私钥 2.加密和解密需要另外一把密钥 3.安全性较高，加解密速度较慢	1.会话密钥加密及协商 2.解密证书，身份认证	RSA, ECC, DH
对称加密	1.一把密钥 2.加密和解密使用同一把密钥 3.安全性较低，加解密速度较快	1.使用会话密钥加密通信数据	AES, DES, RC4
散列函数	1.函数加密不可逆 2.输出的唯一性 3.输出长度固定	1.CA证书数据防伪 2.对比数据，身份认证	MD5, SHA

表格1

注意，上面表格红字部分正好对应了HTTPS的三个安全特性

• 非对称加密：加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。
• 对称加密：需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用作加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文，最初用来加密的公钥不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密
• 散列函数：一种特殊的压缩算法，它能够把任意长度的数据压缩成一种固定长度的字符串。只能进行单向加密，加密后的数据无法解密，不能逆推出原文。

2. 工作机制解析

接下来是本文的重点，将会由浅及深讲解HTTPS加解密的核心工作机制，以及关注三个安全特性如何实现

2.1. 选择加密算法

2.1.1. 对称加密

因为对称加密通信双方均使用同一把密钥，而在向对方传输密钥的过程中可能被攻击者窃听，那么此时密钥就不安全了，因此只使用对称加密算法无法保证密钥的安全传输

2.1.2. 非对称加密

若使用非对称加密算法，服务端持有私钥，客户端持有公钥。
客户端向服务端通信：客户端将明文使用公钥加密发送到服务端，服务端再使用私钥解密，这个过程是安全的，因为若被拦截，攻击者由于没有服务端私钥而无法解密，如下图：

图1

那是否说明只用非对称加密就安全了呢？不是。考虑服务端回传数据。

服务端向客户端通信：服务端将明文使用私钥加密发送到客户端，客户端再使用公钥解密，密文若被攻击者拦截，因为公钥是公开的，所以攻击者自然就能窃取明文了，因此这个过程是不安全的，如下图所示：

图2

综上，如果只使用非对称加密算法，只能保证单向的通信安全，无法保证双向通信的安全性。那么，有没有其他安全的通信方式呢？

2.1.3. 双向非对称加密

沿着上一节2.1.2.的思路，既然只用非对称加密只能实现单向通信安全，假设如果客户端和服务端都各自拥有一对密钥，也就是服务端持有密钥对：公钥+私钥，客户端也持有密钥对：公钥k+私钥k。
客户端向服务端通信：客户端向服务端传输仍然使用图1流程（使用服务端的公钥+私钥），这个过程是安全的

服务端向客户端通信：服务端将明文使用客户端公钥（公钥k）加密发送到客户端，客户端再使用客户端私钥（私钥k）解密，这个过程也是安全的，因为即使密文被攻击者截获，因为攻击者没有客户端私钥，所以无法解密，如下图：

图3
按照这种 双向非对称加密方案，似乎是可行的，因为双向通信都得到了加密且不可破解，然而在实际应用中并没有采取该方案，这种方案存在两个主要问题：

1.使用非对称加密算法的加解密速度很慢且消耗资源，如果采取双向非对称加密会更慢

2.非对称加密方案的公钥可靠性来自CA生成证书认证（在接下来的章节会讲），若每个客户端/用户的公钥也需要采取这种认证方式，显然认证成本会大大增加
那么有没有其他方法呢？

2.1.4. 非对称加密 + 对称加密

回到2.1.2.节，我们已经知道非对称加密可以实现单向的安全加密，且在实际应用中我们需要考虑通信的效率问题，再回看表格1，我们看到对称加密的加解密速度较快，要是有一种方案能把非对称加密的安全性和对称加密的效率这两种优越性结合起来就好了。

我们假设可以使用对称加密来实现双向通信，那么通信双方必定使用同一把密钥来加解密，然而在2.1.1.节我们已经论证了只使用对称加密算法无法保证密钥的安全传输，若有一种机制来保证对称加密密钥传输的安全，那么我们前面遇到的问题也就迎刃而解了。我们留意到非对称加密可以实现单向的安全加密，那么我们是否可以利用非对称加密这个特性来安全地传输对称加密密钥并使用该密钥来加密通信呢？答案是可以，我们看以下实现步骤：

1. 客户端收到服务端的公钥，验证通过后，生成会话密钥，并使用公钥加密
2. 将加密的会话密钥发送到服务端
3. 服务端接收到加密的会话密钥，使用私钥解密，得到会话密钥
4. 此时客户端与服务端均持有会话密钥，后续通信均使用会话密钥加密

这种实现是否足够安全呢？我们来看下关乎安全的传输步骤2和4。

在步骤2中，因为加密的会话密钥是使用公钥加密，故即使被攻击者拦截，由于没有私钥也无法解密，所以步骤2是安全的。如下图：

图4

在步骤4中，通信双方均使用会话密钥加密，由于确认了会话密钥之后，通信双方在后续的会话中已经不需要传输密钥了，因此即使被攻击者拦截也无法解密，所以这个步骤也是安全的。如下图：

图5

至此，我们使用非对称加密 + 对称加密实现了一种兼顾安全和效率的加密机制，公钥+私钥属于非对称加密算法，会话密钥属于对称加密算法。实际上，SSL/TLS的加密机制基本上也是采取了这种算法，也称为混合加密，只不过实际工作中会增加一些细节，但大致上就是上述的思路。

那么，采取混合加密是否就意味着安全了？在混合加密的机制中，公非对称加密中的公钥扮演了十分重要的地位，在上面的讨论中，我们并没有论及公钥本身的安全，有人可能有疑问，公钥不是由服务器给到客户端的吗，况且，如果公钥被更改，服务端也无法正常解密了。考虑以下场景：

1.客户端请求通信，服务端发送公钥
2.通信遭遇攻击，攻击者拦截公钥，攻击者生成自己的一对公钥+私钥，我们暂且称为公钥A+私钥A，并且将公钥替换为公钥A传送给客户端
3.客户端接收到公钥A，认为已经接收到服务端公钥，并用公钥A加密内容回传给服务端，此时客户端并不知道公钥已经被替换
4.攻击者拦截回传的加密内容，使用自己的私钥A解密加密内容，此时攻击者已经成功窃取通信，并且可以随意修改，然后再次用真正的服务端公钥加密内容，回传给服务端
5.服务端接收到被窃听和篡改的内容，使用自己的私钥解密，此时服务端并不知道内容已经被窃听和篡改

以上步骤如下图所示：

图6

在上述的场景，攻击者在客户端和服务端均不知情的情况下神不知鬼不觉地窃听和篡改了通信内容，这种场景被称为中间人攻击。

看来只采用混合加密还是有可能遭受中间人攻击的，那么有没有解决的方法呢？答案是有的，关键点就是在客户端接收到的公钥是真伪，我们需要这样一个能够对服务器公钥进行认证的机制，并且这个机制是要独立和可信的。

2.2. 身份认证

在2.1.节我们讨论了加密算法，并确定混合加密机制的安全性，但同时由于服务端公钥可能遭受中间人攻击又使得该机制存在安全漏洞，因此我们需要可以对公钥进行可靠的认证

2.2.1. CA与数字证书

为了解决公钥认证的问题，于是出现了CA，CA（Certificate Authority）是颁发数字证书的权威证书认证机构。CA机构通过服务端提供的相关信息生成数字证书，证书内容包含了持有人的相关信息，服务器的公钥，签署者签名信息（数字签名）等，最重要的是公钥在数字证书中。

一个数字证书中含有三个部分：证书内容，散列函数，加密密文。

证书内容：包含持有人信息 、证书有效期和服务器公钥 等

加密密文：证书内容使用散列函数进行HASH得到摘要，再将摘要使用CA私钥进行加密，也叫数字签名

图7

2.2.2. 证书数据一致性

有了数字证书，我们还需要知道如何去验证真伪。首先需要保证数据一致性，即数据的完整性，只有接收到的数据是没有被篡改过的，那么接收到的信息才有意义。可按照以下步骤验证：

1. 取出接收到的数字证书的加密密文部分，将加密密文使用CA公钥解密，解密后得到证书内容摘要
2. 取出接收到的数字证书的证书内容部分，将证书内容使用散列函数进行HASH得到摘要
3. 将步骤1和步骤2的摘要进行对比，如果一致，说明数据是完整的，没有被篡改过，可信任。

可以发现，这几个验证步骤，基本上就是2.2.1.节的逆向操作，如下图：

图8

但是针对上述验证步骤，细心的你有可能会提出如下问题：

1. 数据一致性的验证基于CA公钥，那么CA公钥的真伪又如何保证，如何保证可靠的传输到客户端呢？
2. 即便CA公钥为真，但是所有人都能拿到CA公钥，也就意味着所有人都能拿到证书内容，那么如果攻击者修改了证书内容并重新生成摘要，那么客户端在验证的时候是不是也可以通过呢？

针对上面两个问题，有：

问题1：因为CA机构是一种权威信任机构，所以操作系统或浏览器会内置CA的证书和公钥，因此可以确保CA公钥是可靠的

问题2：如果攻击者篡改了证书某些内容，那么必然需要将篡改过的证书内容重新HASH并加密（见图7）得到数字签名，但由于攻击者没有CA私钥，所以无法加密，如果强行加密，那么客户端使用CA公钥解密（见图8）就会失败

所以基于非对称加密+散列函数的证书认证是可靠的，其中CA机构起到了核心作用，而验证证书数据一致性这一步骤又是所有数据可靠的前提，完整的验证步骤主要包括：

• 证书的有效期
• 证书域名与实际域名是否匹配
• 发行服务器证书的CA是否可靠(查询内置的CA证书)
• 证书数据的一致性，即对比摘要是否相等（通过CA公钥解密及散列函数进行HASH）

3. 工作流程

我们已经从第2节论证和认识了SSL/TLS的核心工作机制，HTTPS的完整工作流程就是基于上述的核心机制，接下来我们来看看完整的工作流程。

3.1. SSL/TLS握手详细过程

图9

3.1.1. 客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

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

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

3.1.2. 服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容：

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

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供客户端证书。

3.1.3. 客户端回应

客户端收到服务器回应以后，首先验证服务器证书，验证过程参考2.2.2.节，如果验证不通过就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息：

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

在前3个步骤，一共出现了3个随机数，其中随机数3，也就是pre-master key使用公钥加密。这时客户端和服务端就有了3个随机数，接着双方就用事先商定的加密方法，使用3个随机数各自生成后续会话所用的同一把会话密钥（对称加密）。

为什么一定要用3个随机数来生成会话密钥呢，可以参考这篇文章的解释：

不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

3.1.4. 服务器回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的会话密钥。然后，向客户端最后发送下面信息：

1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（对称加密）（ChangeCipherSpec）
2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的HASH值，用来供客户端校验（Finished）

可以发现，SSL/TLS的整个握手过程，其核心机制就是在第2节我们详细阐述的混合加密算法+身份认证，其中非对称加密就是服务端的私钥+公钥，对称加密就是随机数1+随机数2+pre-master key生成的会话密钥，pre-master key由客户端生成，传输到服务端的过程中使用公钥加密

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用会话密钥加密内容。

图10

备注：本节（3.1.节）主要参考和摘录自阮一峰老师的SSL/TLS协议运行机制的概述一文，大家有兴趣的话可以阅读原文。

3.2. HTTPS工作流程

其实HTTPS工作流程的核心就是SSL/TLS握手过程，SSL/TLS握手过程稍微抽象一点，下图结合具体通信内容和动作展示了较为完整的HTTPS工作流程（当然完整的工作流程还涉及到TCP/IP等其他层，本文重点讨论HTTPS的加解密），可以对照SSL/TLS握手过程做进一步的理解：

图11

上图从这里引用

4. 总结

在第1节，我们从HTTP与HTTPS的差异点出发，提出了HTTPS的3个特性，然后介绍了常见的加密算法；

第2节，我们由浅入深探讨了各种加密算法的可行性，及实现加密安全额外需要的身份认证，得出了混合加密+身份认证的可靠通信机制；

第3节，基于第2节我们对可靠加密机制的认知，我们梳理了SSL/TLS握手及HTTPS完整通信的具体步骤。

回过头来我们看看，第2.1.节得出的混合加密算法对应了HTTPS的加密特性，而2.2.节的身份认证对应了HTTPS的身份认证特性，2.2.节、3.1.3.及3.1.4.的摘要比对对应了HTTPS的数据一致性，至此我们完整涉及了HTTPS的3个特性。

参考文章：
看完这篇 HTTPS，和面试官扯皮就没问题了
《大前端进阶 安全》系列 HTTPS详解（通俗易懂）
一文看懂HTTPS、证书机构（CA）、证书、数字签名、私钥、公钥
分分钟让你理解HTTPS
SSL/TLS协议运行机制的概述
维基百科：HTTP
维基百科：HTTPS

属于自己的文字，理解，观点，欢迎交流

标签：TLS,公钥,加密,加解密,退钱,密钥,HTTPS,服务端,客户端
来源： https://blog.csdn.net/EasonMu/article/details/123006207

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。