HTTPS协议

目录

一、HTTPS的概念

二、加密

1.加密与解密

2.常见的加密方式

三、HTTPS的工作过程的探究

1.方案1——只使用对称加密

2.方案2——一方使用非对称加密

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

4.方案4——服务器非对称加密，客户端对称加密

（1）方案描述

（2）中间人攻击

四、证书

1.数据摘要

（1）数据摘要的概念

（2）数据摘要的应用

2.CA认证

（1）CA机构

（2）证书申请的流程

2.数据签名

3.证书如何检验数据是否被篡改

（1）证书如何工作

（2）如何阻止中间人的监听

五、HTTPS的工作过程

1.方案5——非对称加密 + 对称加密 + 证书认证

2.身边的证书

---

一、HTTPS的概念

HTTPS也是一个应用层协议，它是在HTTP协议基础上引入加密层实现的。

我们之前讲过HTTP的GET和POST方法，虽然它们存储数据的位置不同，但HTTP协议内容都是直接以原文的方式传递，所以在传输过程中一旦我们发送的数据被抓包，所有的用户信息都会一览无余。

所以HTTPS协议原HTTP协议的基础上，在应用层和传输层之间添加了软件层，一般称为SSL/TLS，负责对HTTP进行握手协商和数据的加密解密。

此时交给传输层的数据都是经过加密的，数据被抓包后不法分子也看不到实际的数据。只有客户端和服务端能够通过SSL/TLS进行数据解密，实现通信。

正因为是在原来HTTP的基础上加上了SSL/TLS，所以称之为HTTPS协议。

二、加密

1.加密与解密

• 加密就是把明文进行一系列转换生成为密文
• 解密就是把密文再进行一系列变换，还原成明文

在这个加密和解密的过程中，需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为密钥。

下面就是一个简单的加密和解密过程：

2.常见的加密方式

（1）对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密或单秘钥加密。上图中的异或过程就是一个典型的对称加密。

特征：加密和解密所用的密钥是相同的

特点：算法公开、计算量小、加密速度快、加密效率高。

（2）非对称加密

用两个密钥来进行加密和解密，这两个密钥一个是公钥（可以向全网公开），另一个是私钥（只能自己拥有）。

在逻辑上，用公钥加密，就只能用私钥解密；用私钥加密，也只能用公钥解密。

因为公钥是公开的，所以所有人都可以使用公钥来进行加密或解密。

特点：算法复杂性高，需求算力大，提高了安全性，但是加密解密速度慢于对称加密和解密。

三、HTTPS的工作过程的探究

HTTPS既然使用了加密算法，那么它的运行也一定使用了上面的对称与非对称加密，所以我们假设有一个黑客正在试图监听两台主机大的通信，看看如何合理使用加密达到安全通信的目的。

1.方案1——只使用对称加密

若通信双方都各自持有同一个密钥并且该密钥其他人都不知道。黑客将数据截获，但不知道密钥，所以也没办法解密，也就不知道请求中的内容。那么只要密钥没有被破解，这两方的通信安全必然是可以保证的。

那如何保证客户端和服务端双方用同一个安全的密钥呢？

服务器和客户端要想使用同一密钥，双方就必须有一方给另一方把本地的密钥发过去，我们认为服务器负责发送密钥，客户端负责接收密钥。此时就出现问题了，服务器要想避开黑客的监听就必须使用密文传递密钥，但是服务器现在根本就没有其他密钥用于加密。此时就成了一个先有鸡还是先有蛋的问题了。

换句话说，只使用对称加密根本不能保证密钥能够被安全传输，所以该方案是不安全的。

2.方案2——一方使用非对称加密

如果我们让服务器使用非对称加密时，服务器内有一个公钥和一个私钥。服务器先把公钥发送给客户端，此时黑客也能得到公钥。但是当服务器使用公钥加密数据发回服务器时，密文也会被黑客截获，但是唯一能解密的私钥在服务器手上，所以只有服务器可以对密文进行解密。

可是，当服务器再用私钥加密数据发回响应密文时，由于客户端和黑客都有公钥，所以他们都能将密文解锁。

换句话说，只有一方使用非对称加密仅保证了一条方向上的安全数据传递，所以该方案也不安全。

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

双方都使用非对称加密，则开始时服务器会拥有公钥S和私钥S1，客户端会拥有公钥C和私钥C1。

客户端和服务器在通信之前，先将二者的公钥进行交换。此时服务器就知道了客户端的公钥C，客户端也知道了服务器的公钥S。

客户端给服务器发消息，用公钥S加密，只有使用私钥S1才能解密，私钥S1只被服务器知晓，所以只有服务器能够解秘数据。

服务器给客户端发消息，用公钥C加密，只有使用私钥C1才能解密，私钥C1只被客户端知晓，所以只有客户端能够解秘数据。

这种做法确实安全多了，但是非对称加密的速度很慢，更何况两边都要非对称加密，所以整体的执行效率会非常低。而且这样也不能完全解决安全问题，至于这个安全问题是什么以后再说。

4.方案4——服务器非对称加密，客户端对称加密

（1）方案描述

服务器拥有公钥S和私钥S1，为了保证服务器和客户端的正常通信，客户端会先将公钥S推送给客户端。

然后客户端根据公钥S形成对称秘钥C，然后使用公钥S加密密钥C，形成一段密文X，再将X推送给服务器。

接着，收到密文X后，服务器再用私钥S1进行解密，形成对称密钥C。

最后双方都通过对称秘钥C来完成对称加密，双方就可以进行安全通信。

（2）中间人攻击

一旦公钥S被客户端安全接收，黑客就再也没有希望获取通信的内容了，但是黑客如果在客户端与服务端通信开始前就开始使用中间人攻击（也叫MITM攻击），那么通信的安全就可以被破坏了。

我来用一张图讲解一下中间人攻击在整个流程中的操作，其中M表示中间人，C为客户端，S为服务端：

中间人通过替换服务器第一次发送的公钥，中间人实现了对整体结构安全性的破坏。

所以为了从根源上避免偷天换日的情况出现，我们需要让客户端拥有验证公钥合法性的能力。为了实现这一操作，就需要证书出场了。

四、证书

1.数据摘要

（1）数据摘要的概念

数字指纹(数据摘要)：其基本原理是利⽤单向散列函数(哈希函数)对信息进⾏运算，⽣成⼀串固定⻓度的数字摘要。

数字指纹不是加密机制，但可以⽤来判断数据有没有被窜改。

如果有两个非常大的文本文件，如果我们逐字逐句地去核对该文件中的内容，那么付出的精力会相当大。

如果我们使用某个Hash算法将文本内容转化为一个长度固定的字符串，那比较起来就简单很多了。该字符串就被称为数据摘要，由于重复性极低，所以也称为数据指纹。常用的算法有MD5、SHA1、SHA256、SHA512等。

由于哈希算法的特点，文件内容和数字摘要是一一对应的，所以文件中只要有微小的改动，对应的数据摘要都会发生很大的变动。

由于形成数据摘要使用的Hash方法是不可逆的，而且任何哈希算法都不能保证所有数据和摘要都做到一一对应。所以，数据摘要的意义主要在于判读。

（2）数据摘要的应用

不知道大家有没有好奇过，为什么我们从本地或者其他人的网盘链接中向我们自己的网盘中上传数据时，用不了一秒就传上去了？

比如说，用户A有一部电影《战狼2》，但百度网盘的服务器上没有这部电影。第一个人把它上传保存在百度网盘时，会耗费较长的时间。

如果用户B、用户C甚至用户Z也有一部同样的电影，他们都将该部电影存储到百度网盘上。如果上传数据就是直接把数据传递到服务器上，那么服务器上一定会有许许多多重复的资源，这就造成了严重的空间浪费。

如果在每份文件上传之前，先形成数据摘要，百度网盘的服务器按照该摘要在所有已储存在服务器上的文件形成的数据摘要表中查找。

如果没有相同的数据摘要，说明服务器中不存在该资源，服务器就会将用户资源直接保存在磁盘中；如果表中找到了你上传资源的数据摘要，服务器就就不会再原文上传了，而是将已存在资源的软硬链接放到你需求的目录下，这样就大大节省了内存，提高了效率，实现了“秒传”的效果。

2.CA认证

（1）CA机构

CA机构：它是采用PKI（Public Key Infrastructure）公开密钥基础架构技术，专门提供网络身份认证服务的组织。既可以是民间团体，也可以是政府机构。国内的CA认证中心主要分为区域性CA认证中心和行业性CA认证中心。

作用：专门负责签发和管理数字证书，且具有权威性和公正性的第三方信任机构。

它的作用就像我们现实生活中各种颁发证件的政府部门，比如食品安全部门可以为餐馆等颁发营业许可证等。同样服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。

证书就如⾝份证，证明服务端公钥的合法性。

（2）证书申请的流程

如图所示，证书的申请一共分三步：

第一步，在机构或者个人需要申请申请证书时，需要先在服务器上将认证信息填好，包括公钥与私钥对，域名/申请者/公钥等信息。填好信息以后生成.csr结尾的请求文件。

.csr结尾的文件需要在特定平台⽣成（网上搜都有），虽然我们需要填写私钥，但是只有公钥会打包进CSR⽂件，发给CA进⾏权威认证。私钥我们在服务端⾃⼰保留即可，⽤于后续通信。

第二步，向CA机构提交，等待CA机构审核。

第三步，审核通过以后，CA机构会向服务器签发证书。

这个证书可以理解成为一个结构化的字符串，包含：证书发布机构、证书有效期、服务端公钥和证书所有者等等，这些数据都是明文的，谁都能看懂，只有一个数据签名是加密过的数据。

2.数据签名

数据签名：将数据摘要用签名者的私钥加密，形成的密文就是数据签名。

如图所示就是形成数据签名的过程，我们发送过去的域名、公钥等全部数据会先经过哈希函数生成数据摘要，然后用CA自己的私钥对数据摘要加密，形成的密文就是数据签名。

要想获得该数据的数据摘要，只能使用CA的公钥才能对数据签名进行解密。

那为什么不直接对证书原文加密呢？

先哈希形成摘要也是为了缩小数字签名的⻓度，加快数字签名的比对速度。

3.证书如何检验数据是否被篡改

（1）证书如何工作

如图所示，这就是CA机构生成的证书，会发回给服务器：

我们依旧以第一步传输密钥为例，查看证书是怎么解决这个问题的：

当客户端向服务端发起密钥请求后，服务端就会将附有数字签名的证书返回给客户端。

如上图所示，当客户端拿到服务端返回的带有数字签名的证书后，将证书和数字签名分开，并且将证书内容使用公开的Hash方法再次形成新的数据摘要。

然后，再使用CA机构公开的公钥，将分离下来的数字签名进行解密，得到原来的数据摘要。

如果两个数据摘要相同，说明证书合法，确实服务端发送来的未经篡改的数据，证书中的公钥S可以合法使用，以后的通信也不会再有中间人的事情了；如果两个数据摘要不同，说明数据被篡改，这份数据就被客户端丢弃。

（2）如何阻止中间人的监听

服务器在给客户端发送证书时，中间人也能拿到这个证书。由于公钥是明文数据，而且生成数字签名的哈希函数也是公开的，所以中间人可以拿到这两个数据。

如果中间人截取了服务端给客户端返回的带有数据签名证书，并再次对服务端公钥S进行了替换，转发给了客户端。

当客户端收到被篡改公钥的证书后，通过公开的Hash方法形成的数据摘要和用CA机构公钥解密数字签名后得到数据摘要不相等，客户端就能意识到证书被篡改了，错误的信息会被丢弃。

由于CA机构的私钥其他人没有，所以CA机构颁发证书中的数字签名一经签发就是独一无二且永不改变的。一旦中间人修改了证书中的内容后，它无法使用CA机构独有的私钥形成新的数据签名。

中间人用自己的私钥形成了新的数据签名，但是客户端在验证的时候是使用的CA机构的公钥，无法解密这个数据签名，也会验证失败。

每个浏览器中都内置了CA机构的公钥，解密证书中的数据签名时只能使用这个公钥。

中间人也不能将协议整个换掉。

一方面，中间人要想换掉整个协议，就需要中间人自己去申请CA证书，对黑客而言，这不纯纯自投罗网吗，搞点违法犯罪的事，直接公安机关就能顺着你的IP找到你。

另一方面，中间人纵使换掉整个协议，但证书的服务器域名他改不了，域名不对照样认证出错。

正因为加密使用的私钥在CA手上，所以中间人拿这些明文数据完全没有办法。这样客户端可以验证服务端公钥的合法性，从而保证了后续网络通信的安全性。

五、HTTPS的工作过程

1.方案5——非对称加密 + 对称加密 + 证书认证

所以，最后我们引出了HTTPS的工作过程：

服务器拥有公钥S和私钥S1，为了保证服务器和客户端的正常通信，客户端会先将包含公钥S的证书推送给客户端。

然后客户端认证证书的正确性，认证正确公钥S形成对称秘钥C，然后使用公钥S加密密钥C，形成一段密文X，再将X推送给服务器。

接着，收到密文X后，服务器再用私钥S1进行解密，形成对称密钥C。

最后双方都通过对称秘钥C来完成对称加密，双方进行安全通信。

2.身边的证书

证书在平时上网的时候你一定见过，比如大家上网的时候应该都见过下面的页面吧，你当时可能不知道怎么回事，直接就继续浏览此网站了。但是现在我们知道了，证书有问题的话确实不应该访问网站，会有监听的风险。

除此之外，在我日常使用的Edge浏览器中，点击右上方的三个点，选择"设置"，在隐私、搜索和服务的安全性部分中有一个管理证书。

打开就可以看到浏览器中存在着许多证书，这么多证书都是在访问不同的服务器时，服务器发送过来后保存在浏览器中的，方便之后直接通信。

点击某个证书后，会弹出来证书的详细内容，包括序列号有效时期公钥等等内容。

这些16进制数就是对应服务端的公钥S。

以上就是HTTPS的全部内容了。