https 协议

什么是 Https 协议

HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层。
HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况。HTTPS 通过使用协议加密通信，可以保护数据在传输过程中的安全性，防止敏感信息被恶意获取。

前置概念

加密

什么是加密

加密就是把明⽂ (要传输的信息)进⾏⼀系列变换, ⽣成密⽂ .

解密就是把密⽂再进⾏⼀系列变换, 还原成明⽂ .

在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为密钥.

举个例子：在电话等远距离通信设备还没有诞生的时候，双方只能通过信件来进行通信。你给你喜欢的女生写了一封情书，但是你特别害怕这个信被送信员看到，于是你把信封放在了一个带锁的箱子中，然后再让送信员送信。

其中这个信封就可以看作明文，这个带锁的箱子连同信封，就可以看作是密文，而那把开锁的钥匙就可以看作是密钥。

为什么要加密

因为http的内容是明⽂传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务

器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双⽅察觉，这就是中间⼈攻击，所以我们才需要对信息进⾏加密。

常见的加密方式

对称加密

采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的。
常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
特点：算法公开、计算量⼩、加密速度快、加密效率⾼。

对称加密其实就是通过同⼀个 "密钥" , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂.

我们可以用位运算异或来简单模拟非对称加密的过程

假设: 明⽂ a = 1234, 密钥 key = 8888

则加密 a ^ key 得到的密⽂ b 为 9834.

然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234.

当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使⽤按位异或.

非对称加密

需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。

⾮对称加密要⽤到两个密钥, ⼀个叫做 "公钥" , ⼀个叫做 "私钥".

公钥和私钥是配对的。

通过公钥对明⽂加密, 变成密⽂
通过私钥对密⽂解密, 变成明⽂

也可以反着⽤

通过私钥对明⽂加密, 变成密⽂
通过公钥对密⽂解密, 变成明⽂

还是上面的例子，你把你的情书放在了一个带锁的箱子里面，假设你的心上人已经有了这把锁的钥匙啦，那么你就不用担心你的情书会被送信员看到了。

其中，这把锁就可以看成公钥，这把钥匙就可以看作是私钥。公钥给谁都⾏(不怕泄露), 但是私钥只有你的心上人⾃⼰持有。持有私钥的⼈才能解密，才能看到你写的情书。

数据摘要和数据指纹

数据指纹(数据摘要) ,其基本原理是利⽤单向散列函数(Hash函数) 对信息进⾏运算,⽣成⼀串固定⻓度的数据指纹(数据摘要)。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被篡改。

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

根据数据指纹形成的原理，只要对原数据进行修改，对修改之后的数据使用同样的 Hash 函数，Hash 出来的值(数据指纹) 会有很大差异。

举一个现实生活中的例子：网盘的秒传功能。

通过网盘上传文件的时候，网盘系统会先计算上传文件的数据指纹（通常是文件的哈希值），然后与已存在于服务器上的文件的数据指纹进行比对。如果存在相同数据指纹的文件，则可以直接使用已存在的文件，而无需再次上传，从而实现快速上传的功能。

通过数据指纹比对，网盘系统可以避免重复上传相同的文件，节省了用户的时间和带宽资源。

数字签名

数字摘要经过加密，就得到数字签名（后⾯细说）

我们自己通过一次一次地设计更加安全的网络通信，来引出 Https 协议的原理哈！

方案1：只使用对称加密

表示客户端与服务端通信时仅仅使用对称加密。假设客户端与服务端约定一个密钥，在通信的过程中使用这个密钥来进行加密，你作为一个专业的黑客，要怎么看到客户端与服务端通信时的信息呢？

你知道客户端与服务端通信要经过路由器，运营商等物理节点，拿到了客户端与服务端通信的密文。然后你入侵了客户端的电脑，获得了密钥。使用密钥解密之后，就看到了双方通信的数据啦！

显然这种加密方式并不靠谱，客户端内置密钥，能被别人获取到。同时，如果服务端要更改密钥，客户端与服务端就没法通信啦！

那么客户端向服务器请求密钥行不行呢？显然不行，这不把密钥往别人手里送嘛！

那服务端在返回给客户端密钥的时候对这个密钥进行加密行不行呢？显然这里就出现了鸡生蛋蛋生鸡的问题了！

继续拿刚才那个情书的例子举例：送信员相当机制啊，提前在你的心上人那里把锁的钥匙复制了一份，你的情书就泄漏啦！

方案 2：只使用非对称加密

在客户端想要与服务端进行通信的时候，客户端先向服务端请求非对称加密中的那个公钥。服务端保留非对称加密中的私钥。客户端拿到这个公钥之后。在以后的通信中：

客户端发给服务端的数据使用公钥进行加密，服务端用私钥解密之后，获得客户端发送的数据。
服务端发给客户端的数据使用私钥进行加密，客户端用公钥解密之后，获得服务端发送的数据。

你作为一名专业的黑客，要怎么看到客户端和服务端之间通信的数据呢？

假设你不能入侵服务器哈，一个公司是有网络安全工程师的，入侵难度太大了！

首先你入侵了客户端的电脑，拿到了服务端发送来的公钥。
然后你截取了服务端发送给客户端的数据，使用你拿到的公钥进行解密，成功拿到了服务端发送给客户端数据。
但是，你拿不到私钥啊，就没法看到客户端发送给服务端的数据。是不是能保证客户端发送给服务端的数据是安全的呢？
于是你陷入了思考。让子弹飞一会儿，我们等会儿来看看你是怎么破解这个问题的，因为下面的几种加密方式都是使用同一种方式破解的！留到后面一起讲。

方案3：双方都使用非对称加密

在客户端有一个公钥和私钥，在服务端也有一个公钥和私钥。通信过程的加密方式和方案 2 类似。

存在问题：非对称加密的效率太低。安全问题依然是有的，等会儿一起说哦！

方案4：对称加密 + 非对称加密

在客户端与服务端之间进行通信的时候，客户端先向服务端请求公钥。客户端拿到公钥之后，客户端形成一个对称密钥。客户端使用公钥对这个对称密钥进行加密，然后将加密之后的数据发送给服务端。服务端收到数据后使用私钥解密之后拿到了客户端形成的对称密钥。此后客户端与服务端之间的通信使用这个对称密钥加密。

这样看是不是很完美，既解决了效率问题，又解决了方案 2 中黑客能看到服务器发送给客户端的数据的问题！

真的是这样嘛？真的是安全的嘛？作为一名专业的黑客，你经过冥思苦想，想到了一个完美的破解方案：

如下图：

服务端有一个公钥 S 和一个私钥 S*。
客户端有一个非对称加密的密钥 X。
作为一名黑客(中间人)，你也有自己的公钥和私钥。
作为一名专业的黑客，你已经在客户端与服务端进行通信之前就提前埋伏好了！
当客户端向服务端发起通信请求获取服务端公钥的时候，你对该请求进行拦截！由你(中间人) 向服务端发起请求。
服务端获得请求之后，将公钥 S 发送到了你(中间人)的电脑上，然后你(中间人)对服务端的公钥进行掉包，将自己的公钥 M 发给客户端。同时保留服务端的公钥 S。
客户端收到公钥 M 之后，将客户端形成的对称密钥 X 使用公钥 M 进行加密，然后把加密之后的对称密钥发送给服务端。
同样，你(中间人)将客户端使用公钥 M 加密之后的对称密钥进行拦截，使用你自己(中间人)的私钥 M* 进行解密之后，你也拿到了客户端形成的对称密钥 X 啦！然后将这个对称密钥使用服务端的公钥 S 加密之后，发送给服务端。
至此，客户端与服务端之后使用对称密钥 X 加密通信的数据，你(中间人)，全都能看见啦！

这种破解的方法对于方案 2,3,4 都适用哈，所以说上述讲的方案全都不是安全的！

再拿情书的例子举个例：那个送信员见不得你就要有女朋友了，于是将你的箱子和信封全部掉包了，并且修改了信封中的内容！哈哈哈哈哈，"恶毒" 的送信员。

不知道 uu 们能不能看到这个问题的本质。其实本质问题就是：客户端无法验证服务端发来的公钥是合法的，是没有被经过掉包的！

那么如何保证服务端公钥的合法性呢？这就要提出一个叫做证书的概念啦！

CA 认证

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

CA（Certificate Authority，证书颁发机构）是负责颁发和管理数字证书的机构。数字证书是用于在网络上验证通信方身份的一种方式，类似于身份证明。CA通过验证申请者的身份信息，并为其颁发数字证书，证明该申请者的身份是可信的。常见的CA机构包括Symantec、Comodo、GoDaddy等。在使用HTTPS协议时，网站通常会从CA机构处获取数字证书，以确保网站身份的可信度和安全性。

我们在搭建网站的时候需要上传的 SSL 证书就是 CA 机构颁发的：

SSL证书是由CA（Certificate Authority，证书颁发机构）颁发的。SSL证书是一种用于在Web服务器和浏览器之间建立加密连接的数字证书，用于保护网站和用户数据的安全性。当用户访问使用SSL证书的网站时，浏览器会验证SSL证书的有效性，以确保网站的身份是真实可信的。

CA 认证的过程

如上图：展示了 CA 认证的过程

证书包含两个部分：数字签名和明文信息。
这个数字签名是什么呢？刚刚我们就提到了数字签名的概念：数字签名是数据摘要进行加密之后的数据。

我们来看看 CA 认证的过程哈：

服务端首先要有自己的公钥和私钥。
服务端申请证书需要填写相关信息：比如域名信息，证书申请者，服务端的公钥。
相关信息填写完毕之后，服务端会生成一个请求文件 .csr。

.csr 文件是 Certificate Signing Request（证书签名请求）文件的缩写。例如：在申请SSL证书时，服务器管理员需要生成一个.csr 文件，其中包含了服务器公钥和相关的身份信息。这个文件会被发送给证书颁发机构（CA），CA会根据.csr 文件生成数字证书，并返回给服务器管理员，以便在服务器上安装和使用SSL证书。

.csr 文件包含以下信息：
- 公钥：用于加密通信的公钥，是证书的一部分，用于验证证书的有效性。
- 组织信息：包括组织名称、部门、城市、州/省、国家等。
- 域名信息：证书要绑定的域名，通常是需要SSL证书保护的域名。
- 加密算法：用于生成数字签名的加密算法信息。
  
  网上都有一些在线生成 .csr 文件的网站哈！
将 csr 文件发送给 CA 机构之后，CA 机构会对这些信息进行审核。
审核通过之后，就可以向服务端颁发相关证书啦！

证书中的签名怎么回事儿呢？

首先 CA 机构会将服务端上传的明文信息通过哈希算法形成一个数据摘要！
然后对形成的这个数据摘要使用 CA 机构的私钥进行加密，形成数字签名。
没错，CA 机构也有自己的公钥和私钥，CA 机构的公钥是公开的。私钥只有 CA 机构持有。

这里就有一个问题了！如何知道服务端的证书是权威机构颁发的，没有经过篡改的呢？

我们在检查服务端的证书是否合法的时候，应该怎么做呢？

证书中不是包含数字签名和明文信息两个部分嘛！我们先将这两个部分拆开。得到明文信息和数字签名。
我们对明文信息使用与 CA 认证形成数据摘要时相同的哈希算法进行哈希。得到结果 ret1。
我们再对数字签名使用 CA 机构的公钥进行解密，得到结果 ret2。
我们只要对比 ret1 和 ret2 就知道这个证书是不是权威机构颁发的啦：
- 如果 ret1 == ret2 说明没问题。
- 如果 ret1 != ret2 那就说明这个证书要么不是权威机构颁发的，要么就是经过篡改的啦！

如下图：就是形成证书与验证证书合法的过程，CA* 就是 CA 机构的私钥哈！

我们可以看到，这些验证过程需要的什么散列函数，CA 机构的公钥在浏览器中都是有的哈：

下面是在 Microsoft Edge 浏览器查询到的信息：

那么我们就可以提出使用 HTTPS 通信的真正过程啦：

终极方案：非对称加密 + 对称加密 + 证书

如上图：展示了客户端与服务端进行安全通信的过程。

客户端向服务端发起通信请求，服务端首先会将部署在服务器上的证书返回。
客户端收到这个证书之后，就会对证书进行拆分。对明文信息通过算法形成数据摘要(假设本例子中 CA 机构使用的是 MD5 算法对明文信息形成数据摘要的)。对数字签名使用 CA 机构的公钥进行解密。然后对比这两个结果是否一致。
如果一致的话，客户端会生成对一个称密钥，然后使用服务端的证书中的明文信息中的公钥对这个对称密钥进行加密，然后发送给服务端。如果不一致的话，肯定就不会进行通信啦！或者你日常网上冲浪的时候，遇到一些证书过期的网站，浏览器会弹出该网站的整数过期什么的，是否要继续访问。或者是一些证书不合法的网站，也会弹出证书不合法啥的。如果你继续访问就是使用 http 协议吧，你发送的数据就相当于在互联网裸奔哦！
如果证书认证合法的话，从此之后，客户端与服务端就可以使用这个对称密钥来通信啦！

你作为一名专业的黑客，那肯定要来挑战挑战啦！

首先，你轻松获取到服务端发给客户端的证书，你尝试修改证书上的某些字段之后返回给客户端。客户端拿到这个证书，发现 hash 出来的数据摘要，和用 CA 机构的公钥对数字签名解密出来的数据摘要不同，客户端就不发那个对称密钥啦！你想要修改证书的签名也是一个效果哦！
你偏不信，于是自己伪造了一个证书，发给客户端，发现客户端依旧没有发那个对称密钥过来！
这是因为在对数字签名进行解密的时候，客户端只用 CA 机构的公钥，这就意味着，只有 CA 机构能够进行证书的颁发。其他人没办法捏造证书的。
你硬是不信邪，于是你通过合法途径向 CA 机构申请了一个合法的证书。你拦截了服务端发给客户端的证书，将证书掉包，发给了客户端。客户端就疑惑了，为什么我请求的是这个网站，证书上的域名确实另一个网站呢？(证书上的明文信息是包含其认证的域名信息的)。这可不是重定向啊，要不得，要不得，危险，危险！！！
另外，你通过合法途径申请证书，可是能从证书中看到你的个人信息的哦！你想想！！！

最后一个问题：CA 机构为啥不对服务器提交的数据用 CA 机构的私钥直接加密，而是要形成数据指纹之后再加密呢？

原则上是可以的哈，只不过哈希之后长度更加短，方便嘛！！！

事实上，客户端收到服务端的证书，除了对比数据摘要，还要判断证书有效期，是否信任等等。上面的图片中也有有效期，等等字段哈！看下面的图片有有效期吧：

知识点总结：

加密，非对称加密，对称加密，数据指纹，数字签名的概念

了解证书的办法过程。

理解 https 通信的安全性是如何保证的。