Https技术刨析

谈到https，我们肯定就想到http协议，这两者长得这么像，其内部实现确实天壤之别！

先谈http，再来说https和其的区别？

一、Http概述：

• HTTP：是互联网上应用最为广泛的一种应用层网络协议，用于在 Web 应用程序之间传输数据。HTTP 使用 TCP/IP 协议族来传输数据，它是一种文本协议，通过请求和响应的方式来传递数据。用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

为什么能减少网络传输？

• HTTP 有很好的缓存机制，可以减少网络传输。例如，在 HTTP 响应头中设置了适当的缓存控制信息（如过期时间），浏览器就可以缓存页面内容，下次访问相同的页面时，就可以直接从缓存中读取，而不需要再次从服务器请求数据，从而减少了网络传输。

• 此外，HTTP 还支持压缩和分块传输编码，可以进一步减少网络传输。

• 相对于其他二进制协议，如 FTP 和 SMTP，HTTP 的数据包较小，因为它是一种文本协议，而且它只传输需要传输的内容。

1、那么Http有什么缺点呢？

HTTP是一种无状态的协议，数据传输过程不进行加密，是以明文的方式在网络中进行传输，很容易被黑客窃取、篡改和监听，因此在传输敏感信息时存在安全风险。

如下图，当我们需要访问北京的某个服务器，可能需要经过若干个路由器进行转发，那么在这过程中就可能存在某些人对传输中的信息进行拦截，窃取或者篡改。

常见的有：

• 数据包嗅探：通过嗅探工具对网络进行监听，攻击者可以截获http协议的数据包，然后进行窃取或者篡改。

• 数据包分析：通过对http协议的分析，攻击者可以查看传输的数据内容，包括敏感信息。

• 中间人攻击：中间人攻击可以让攻击者站在网络通信的中间位置，将双方通信的数据截获、篡改和窃取，用户和服务器双方都无法感知到攻击的存在。

• ARP欺骗攻击：ARP欺骗攻击可以使攻击者的MAC地址与目标主机的IP地址进行绑定，从而可以拦截网络流量，窃取或篡改数据。

• DNS劫持攻击：DNS劫持攻击可以使攻击者在用户访问特定网站时将其重定向到恶意网站，从而窃取用户敏感信息。

在这过程当中，以明文形式传播不仅存在极大的风险，而且破获信息的成本极小。

甚至在早期一些网络运行商都会做这种事，早期我们的电脑经常会因为可能浏览了某个网页，随后广告就一发不可收拾的弹出（无能为力，只能重装系统）。

其原理也很简单，在传输的过程中，我拦截了你的请求，然后在里面加入广告弹窗代码数据，甚至可能是病毒脚本，然后再把http响应发送给你。

2、Https的崛起

随着互联网发展越来越快，人们也意识到网络安全以及传递数据的价值越来越大这一问题。http是不涉及安全性的，所以为了保证个人隐私的安全，于是就出现了https。

当时吃到第一波红利的是互联网浏览器的领导者——网景公司。在1994年在自己的浏览器中支持了https，s表示的就是secure（安全）。

二、Https技术鉴赏

既然http不安全，那么怎么让其变得安全呢？

加密！通过明文的方式自然很容易被人知道其传输的 数据内容，那我们就不通过明文传输，将明文加密成字符串，这样就不容易让人轻易的获取 我们传输的内容（不容易，不是说不可能！）

那么怎么进行加密呢？接下来我们来看下。

1、Https的加密形式

采取的是双向加密方式，通过公钥对信息进行加密，通过私钥对信息进行解密，流程如下：

也是非对称加密，而不是对称加密。

很显然，在发送公钥到客户端的过程中，还是可能存在被攻击者获取。但是，公钥只是用来加密，并没有解密的作用，所以看上去这个方法天衣无缝！（但只是看上去）。

这样我们可以怎么破解呢？下来我们会说到。

 

以下这张图就是https的大致原理：

也被称之为安全套接字层SSL(Secure Socket Layer)，而这个密钥协商的过程也被称为SSL握手，SSL3.0也称为TLS1.1，TLS1.2升级的主要内容就是淘汰了MD5和SHA-1，这两种哈希函数。具体原因就是提升安全性。

2、中间人攻击

刚才有说到这一攻击方式，接下来具体来说明。

刚刚只说到的双向加密并不能真正保证安全性，因为在将公钥传递给客户端的过程中，可能会被黑客拦截，并且替换成黑客自己的公钥，将服务器的公钥保存起来，然后将黑客自己的公钥发给用户，用户通过黑客的公钥对数据进行加密，然后再把加密后的密文发送给服务器，在这过程中又被黑客拦截，黑客再用自己的私钥将密文进行解密，得知其信息后，黑客可以查看用户发送的信息，或者篡改信息，再将信息通过服务器的公钥进行加密，将加密后的密文发送到服务器，服务器接收到之后用私钥解密。

上述所说的情况就是，黑客充当了中介，如果用服务器给的公钥不能知道用户的信息，那我就把服务器的公钥拦截下来，把自己的公钥给用户来进行加密，这样黑客有对应的私钥（如果是对称加密，就只有一把钥匙）就可以解密出用户的信息，然后篡改完再用服务器的公钥加密发送给服务器。

问题的根本在于，公钥不能表明自己属于谁？

3、数字证书和CA机构

• 为什么解决上述的问题，就出现了一种CA机构，服务器先把公钥以及自己的信息以及使用公钥的人的信息发送给这个CA机构，由CA机构都过这些信息生成数字证书，同时也会生成公私钥对，不同的是通过私钥进行加密，公钥进行解密。

数字证书包含明文信息以及加密后的密钥。

• 生成TLS数字证书后，会将证书发送给服务器，再由服务器进行

3.1、数字证书的验证过程

3.1.1、验证数字证书的合法性通常包括以下步骤：

1. 验证证书的有效性：首先需要检查证书是否在有效期内，是否被吊销等信息。这可以通过证书中的 CRL（证书撤销列表）或 OCSP（在线证书状态协议）来检查。

2. 验证证书的颁发者是否可信：需要检查证书中的颁发者是否被信任。如果证书的颁发者是未知或不被信任的颁发机构，则需要更深入的检查证书的完整性。

在验证数字证书的过程中，可以查看证书中的颁发者是否被信任。这个信息通常会包含在操作系统或浏览器的信任库中，也可以通过在浏览器中查看证书的详细信息来确认。

1. 验证证书中的主题信息是否正确：主题信息指的是证书中包含的与证书持有者有关的信息，如主机名或域名等。需要确保这些信息与请求证书的网站或服务匹配。

2. 验证证书中的数字签名是否正确：最后需要验证证书中的数字签名是否正确，从而确保证书中的信息没有被篡改。

数字证书中的数字签名是通过使用证书颁发机构（CA）的私钥对证书内容进行签名得到的。因此，验证数字证书的合法性需要使用CA的公钥对数字签名进行解密，并使用相同的哈希算法对证书内容进行哈希，将明文的哈希值与数字证书解密后的的信息的哈希值进行比较，以验证数字签名的合法性。

具体步骤如下：

1. 从数字证书中获取签名算法和签名哈希算法。

2. 使用CA的公钥对数字证书中的数字签名进行解密，得到签名值。

3. 对数字证书的内容进行哈希，并生成哈希值。

4. 将生成的哈希值与数字证书中的签名值的哈希值进行比较。

5. 如果两个值相同，则证书合法；否则，证书不合法。

需要注意的是，如果数字证书中的数字签名不是使用CA的私钥进行签名的，那么这个数字证书就是伪造的，验证过程将无法通过。

补充：证书中的公钥是服务器用自己的私钥生成的加密公钥，用于加密客户端发来的随机数等信息。数字签名的验证需要用到证书中的CA机构的公钥进行解密验证，而不是服务器的公钥。

但是拥有CA机构的数字证书还是不能确保绝对安全，将安全全部交在CA机构也不是很安心，如果内部出现人员腐败，为不合法的人或机构签发数字证书，那也是很危险的。所以又加了一个CT机制。

这样的操作看上去就是一种套娃机制，因为CT机制就是又新建了一个日志服务器，用来跟CA机构共同监督数字证书的透明性，同样也是有一对公私钥。CA机构可能颁发错误的SSL，那CT机制就不会颁发错误的SCT吗？

4、去中心化——CT机制

为了解决上述可能发生的问题，CT机制采取的是去中心化策略。这就要引出一个概念：区块链技术——任何中心化节点都是不可信任的。

日志服务（CT）采用区块链中常用的 Merkle tree（默克尔树）来防止篡改，在数字证书中加上SCT信息。

4.1、默克尔树的数据结构

如下图：

• 首先根据证书颁发的顺序依次排列，然后求出其证书的hash值

• 再将相邻的两个hash值进行合并，不断重复

• 最后得到一个根哈希值，只要确保这个跟哈希值不变，就可以知道证书是否被进行篡改过

因为被篡改过的证书哈希值肯定发生变化，最后肯定会影响到根节点。（极端情况下的概率非常低，修改相邻两个证书，让其hash值保持平衡，这实际上属于哈希函数的碰撞问题，而且是选择前缀碰撞，MD5已经被证明是可以的，但是其他哈希函数仍然没有被证实可以被破解，前文已经说到了MD5等不安全的哈希函数已经从TLS1.2中移除。只要哈希算法的安全性没有被打破，这棵树就是安全的）

        也就是说日志服务是一个只能添加的账本系统，而是数据是完全公开的，所有人都可以查询或者验证。从2018年开始由google浏览器牵头，开始必须要加入CT机制，各家浏览器开始强迫执行检查数字证书中的CT检查，也就是说不携带SCT信息的证书将被浏览器辨别为不安全的。

参考：

https技术鉴赏_哔哩哔哩_bilibili

程序员小猪