Linux 基础：HTTPS 原理与加密机制详解

HTTPS 基础概念

概述

本文从 HTTPS 是什么、为什么需要 HTTPS 的角度，基于 HTTP 协议认识 HTTPS，介绍加密原理，包括对称加密和非对称加密，引出五种不同的通信方加密方式及证书相关概念。

一、认识 HTTPS

HTTPS 也是一个应用层协议。它是在 HTTP 协议的基础上引入了一个加密层，可以理解为 SSL+TLS+HTTP 构成。

二、为何要加密

由于 HTTP 的内容是明文传输的，明文数据会经过路由器、WiFi 热点、通信服务运营商、代理服务器等多个物理节点。如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。因此我们需要对信息进行加密。

早期的 HTTP 在网络中明文传递，是暴露的，能被修改。

其中：

• 加密就是把明文（要传输的信息）进行一系列变换，生成密文！
• 解密就是把密文再进行一系列变换，还原成明文！

在这个加密和解密的过程中，往往需要一个或者多个中间的数据辅助进行这个过程，这样的数据称为密钥（正确发音 yuè 四声，不过大家平时都读作 yào 四声）。

因此：

HTTPS 就是在 HTTP 的基础上进行了加密，进一步来保证用户的信息安全。

三、加密方式

3.1 对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密。

常见对称加密算法（了解）：DES、3DES、AES、TDEA、Blowfish、RC2 等。 特点：算法公开、计算量小、加密速度快、加密效率高。

因此：

我们只需要记住：加密密钥和解密密钥是同一把，这在某种意义上成为了它的缺点。

一个简单的对称加密：按位异或。

假设明文 a=1234，密钥 key = 8888，则加密 a ^ key 得到的密文 b 为 9834，然后针对密文 9834 再次进行运算 b ^ key，得到的就是原来的明文 1234。（对于字符串的对称加密也是同理，每一个字符都可以表示成一个数字）。当然，按位异或只是最简单的对称加密，HTTPS 中并不是使用按位异或。

3.2 非对称加密

需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

常见非对称加密算法：RSA, DSA, ECDSA。 特点：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。 最大的缺点就是运算速度非常慢，比对称加密要慢很多。

因此：

这里只需要记住：公钥加密只有私钥解开，私钥加密只有公钥解开。

3.3 数据摘要与数据指纹

数字指纹（数据摘要），其基本原理是利用单向散列函数（Hash 函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被篡改。

摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）。 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比，比如数据库管理使用摘要。

四、HTTPS 加密方式

4.1 只使用对称加密

也就是我们只使用一把密钥进行通信。

理想情况：

实际情况：

这种理想上被中间人截取的也只能是密文，无利用价值，但是服务端和每个客户端都要有个密钥来维护，这样就比较麻烦，因此一般采取的是先发送密钥进行协商，但是这样就被中间人获取密钥了，因此这种方案是不可行的。

因此就导致了这样：

4.2 双方使用一个非对称加密

服务端发送信息前提是先要和浏览器协商（把公钥发给它），然后用私钥加密，给浏览器，这样信息就暴露了（服务器到浏览器的信息暴露），但是浏览器拿到后，进行发送用公钥加密（只能私钥解密），此时无法暴露，服务器就能正常收到信息。

比如：

4.3 双方都使用非对称加密

交换公钥，公钥加密，私钥解密。

它们俩互相交换了公钥（用于加密），有没有可能中间人也用公钥进行加密然后比如从客户端发给服务端，这样服务端也就分不清了或者中间人用自己的公钥给客户端，然后进行信息窃取。

总结：

因为非对称加密效率低，而且还有安全问题。

4.4 非对称加密 + 对称加密

也就是服务端先把公钥给客户端，客户端用它进行对称密钥加密然后给服务端（中间人无私钥，无法解密），最后他俩就用这个对称公钥进行加密。

过程如图所示：

这样看似是没有毛病的，但是有没有可能中间人把自己的公钥 m 给 client，然后不就得到了这个被 m 加密的 x 了，然后再用 s 进行加密给服务端这个 x，之后 s 与 c 用 x 通信不就被中间人掌握了吗。

结局就成了这样：

因此：

关键问题还是防止中间人攻击，也就是如何确保 client 收到的公钥来自 server 而不是中间人呢？

4.5 两次非对称加密与一次对称加密

引入证书

这种方式的前两次非对称加密都是为了保证最后一次对称加密的安全性。 证书 = 签名 + 明文

CA 认证

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

下面看一下申请证书过程图：

这里需要记住：

• 签名只有 CA 机构能做（因为只有它才有对应私钥）。
• 签名和解签名的密钥和服务端的密钥不是同一种。
• CA 的私钥由 CA 使用进行签名，CA 的公钥由浏览器自备进行解签名验证。
• 服务端和客户端通信的时候，客户端会先请求，此时服务端就去 CA 机构申请一个证书，这个证书就是保证 client 拿到的一定是 server 的公钥。

证书有没有可能被篡改

那么此时浏览器拿到证书如何核对有没有在 server 与 client 传播过程中被中间人修改呢？

CA 机构在形成证书的时候会拿着私钥对明文信息散列后的摘要进行加密作为签名。然后当客户端收到证书后会拿着 CA 公钥对签名解密拿到的数据和明文信息散列后进行对比；如果相同就证明没有被修改，拿着公钥进行传递对称密钥。被修改了就警告。保证了 client 一定拿到 server 的公钥。

如图：

但是如果中间人修改 server 发给 client 的证书的明文/签名/或者整体替换呢（中间人如果要想成功传递自己的秘钥必须修改签名）？

• 修改明文：如果修改了的话，当 client 拿到证书后会发现不匹配的。
• 修改签名：中间人没有 ca 的私钥无法对前面修改。
• 整体替换：这里整体替换就必须要 ca 的严格审查，中间人只能按照要求申请新的证书，但是还有域名等等一些信息使得客户端可以识别到是不是对应服务端。

中间人动机：

• 要么把明文里的公钥换成自己的。
• 要么换成自己的后然后改签名让客户能够获取公钥。

但是，均行不通。

永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的。

因此总结： 中间人无法修改证书和伪造新的证书。

非对称加密 + 对称加密 + 证书认证

因此，它来了。

这里可以理解成：

首先进证书申请 + 客户端验证证书（第一次非对称加密以及解密）；接着就是 client 拿到对应的 server 的公钥，然后进行传递接下来进行非对称加密的秘钥，服务端然后拿着自己的私钥进行解密拿到（第二次非对称加密以及解密）；接着就是用这个非对称秘钥进行通信了（非对称加密及解密）。

也就是这样：

注意：这里的易混点是签名和解签名只能用 CA 的私钥和公钥；而不是服务器的私钥公钥（过程中服务器会泄露公钥但私钥不会泄露）。

下面看张更加详细的图：

详细步骤：

• 第一次非对称加密：用于校验证书是否被篡改。服务器持有私钥（私钥在形成 CSR 文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥）。服务器在客户端请求时，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
• 第二次非对称加密：用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的公钥（是可被信任的）给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
• 对称加密：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。

超详细大白话叙述过程：

首先服务器拿着相关信息（域名，csr，明文信息等），然后生产对应的私钥（自己保存），公钥（交给 CA）然后向 CA 申请证书，ca 检查严格审核后，拿着自己的专属私钥进行对明文散列后数据签名，接着交给 server，最后 server 把证书给 client，client 拿着自己内置信任的 CA 机构的公钥容纳后进行解密签名看是否合法（明文散列是否相同，域名等是否匹配），不合格就发出警告（上报，或者浏览器阻止用户访问等），合格的话就拿到对应服务器的公钥，自己产生对称秘钥，然后发给服务端（中间人稚嫩获得密文，无法解密），然后服务端解密后，他俩就利用对称秘钥进行通信了。

总结： 这一切的目的就是保证这个对称秘钥通信的时候是安全的。

疑问点

1. 为什么要进行签名加密：

   • 如果不签名的话就是直接证书上的就是明文，那么在客户端核对前是有可能被中间人修改的，因此是不安全的。

2. 为什么明文不直接加密而是先生成摘要呢：

   • 缩小签名密文的长度，加快数字签名的验证签名的运算速度。

3. 如何成为中间人：

   • ARP 欺骗：在局域网中，hacker 经过收到 ARP Request 广播包，能够偷听到其它节点的 (IP,MAC) 地址。例，黑客收到两个主机 A,B 的地址，告诉 B(受害者)，自己是 A，使得 B 在发送给 A 的数据包都被黑客截取。
   • ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个 ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上，达到和 ARP 欺骗同样的效果。

查看浏览器的受信任证书相关信息

可以看到有很多信任的证书，点击可以看到公钥等信息：

接下来点击安全选项：

首先点击浏览器对应设置：

五、本篇小结

通过本篇对 HTTPS 的基础认识，建立了大致的了解，知道了它背后的原理等。此次学习虽然是大致的，但是也看到了 HTTPS 背后的基本原理，为以后对它更加深入的学习奠定了基础。