【网络】HTTPS——HTTP的安全版本

1.HTTP的问题

• 1、使用明文通信

HTTP协议不具备给通讯内容加密的功能，所有使用HTTP协议通信的请求和响应的内容无法进行加密,都是使用明文发送。由于HTTP属于TCP/IP协议族的协议，按照TCP/IP协议族的通讯机制，HTTP在整个通讯线路上都存在被窃听的可能。例如：wireshark等抓包工具、sniffer等嗅探工具都可以在通讯网络上收集数据包并进行解析。

• 2、不验证通讯双方身份

HTTP协议不会对通信中的请求方和响应方进行验证。服务器只要接收到请求就会返回一个响应。因此存在会一些安全隐患：

• 1、无法确定请求发送到的web服务器是按真实意图返回响应的web服务器，存在伪装服务器的可能。
• 2、无法确定响应是不是返回到按照真实意图接受的客户端的情况，存在伪装客户端的可能。
• 3、无法确定通信方是否有通讯的权限。对于一些保存有重要信息的服务器，只能将信息发送给部分有通讯权限的用户。
• 4、对于无意义的请求，服务端也会响应。无法阻止DOS拒绝服务攻击，通过海量请求占用服务资源，无法正常提供服务。
• 5、无法判断请求的来源和发起者。

• 3、无法验证报文的完整性

HTTP协议无法确认通信报文的完整、准确。在请求或响应送出之后直到接收方接收之前这段时间，如果请求或响应被篡改，也是无法知道的。即：发出的请求和响应和接收到的请求和响应无法确保相同。例如：中间人攻击

2.预备知识  

2.1.HTTPS是什么

https(全称：Hypertext Transfer Protocol Secure)，是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性，是 HTTP 的安全版本。

1. Https是身披SSL/TLS外壳的HTTP协议，它并非一个新的协议而是在HTTP的基础上新增了安全层(SSL/TLS),HTTPS先和安全层通信，然后安全层和TCP层通信。
2. HTTPS 经由 HTTP 进行通信，但是在 HTTP 的基础上引入了一个加密层，使用 SSL/TLS 来加密数据包。
3. HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
4. HTTPS 默认工作在 TCP 协议443端口(HTTP默认80端口)

既然要保证数据安全，就需要进行“加密”，即网络传输中不再直接传输明文，而是加密之后的“密文”。

应用层就是我们自己啊，我们自己去加密吗？别开玩笑了，等下偷鸡不成蚀把米了。

为了更好的加密，就在应用层和传输层之间加了一个安全层，使用 SSL/TLS 来加密数据包。

以前HTTP是应用层将HTTP响应/请求直接传递给传输层，现在变成了HTTPS，先将应用层将HTTP响应/请求传递给SSL&TLS这个过渡层，然后再传递给传输层，这就是HTTPS和HTTP的区别。

也就是说，

• Https是身披SSL/TLS外壳的HTTP协议，它并非一个新的协议而是在HTTP的基础上新增了安全层(SSL/TLS),HTTPS先和安全层通信，然后安全层和TCP层通信。

SSL/TLS 是用于加密和保护网络通信的协议。它们用于确保在互联网上传输的数据在传输过程中是安全的，并且不能被未经授权的人读取或篡改。SSL 是 TLS 的前身，TLS 实际上是 SSL 的后续版本 

• 使用SSL/TLS就不一定安全了 ，因为SSL/TLS会一直更新，新版本出来的时候，旧版本的漏洞也就公布出来了，这会导致使用旧版本的SSL/TLS的客户端不安全。

2.2.加密和解密

2.2.1.什么是加密和解密

首先需要简单了解一下 加密与解密 的概念

• 加密：把明文经过一系列变换，形成密文
• 解密：把密文经过一系列变换，还原成明文

明文就是我们能看懂的信息，密文就是我们看不懂的东西。

        比如这篇博客现在就是以明文的形式显示的，但如果我将其变为火星文，所有人都看不懂，那它就变成密文了

在加密与解密的过程中需要一个或者多个辅助数据，我们将其称为 「密钥」

加密是上锁，解密就是开锁，无论是上锁还是解锁，都需要钥匙，也就是「密钥」 

加密示例：假设我们要加密的消息（明文）是 "HELLO"，并且我们选择的密钥是3（意味着字母表中的每个字母向后移动3位）。

• H -> K (因为H向后移3位是K)
• E -> H (E向后移3位是H)
• L -> O (L向后移3位是O，注意这里超过了Z则循环回A)
• L -> O (同上)
• O -> R (O向后移3位是R）

所以，经过加密后的密文是 "KHOOR"。

解密示例：现在，如果我们收到密文 "KHOOR" 并知道密钥是3，我们可以通过相反的操作来解密，即将每个字母向前移3位来还原明文。

• K -> H (K向前移3位是H)
• H -> E (H向前移3位是E)
• O -> L (O向前移3位是L)
• O -> L (同上)
• R -> O (R向前移3位是O)

这样，我们就成功地将密文 "KHOOR" 还原成了明文 "HELLO"。在这个例子中，密钥就是那个固定的数字3，它在加密和解密过程中起到了至关重要的作用，确保只有拥有密钥的人才能正确解码信息。

 2.2.2.为什么要加密解码

• 为什么需要加密？

        首先是因为信息都是以 明文 的形式传输的，难免会遇到坏人收集个人信息，其次是可能存在运营商劫持等安全问题，个人信息容易泄漏，所以才需要对信息加密，保护隐私

        我们举个例子来

        由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等)，那么运营商的网络设备就可以解析出你传输的数据内容，并进行篡改。

        比如说我们下载天天动听，我们在浏览器点击"下载按钮"，其实就是在给服务器发送了⼀个HTTP请求，我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等)，所以我们发出的HTTP请求会先会经过运营商的网络设备(路由器,交换机等)，然后再到天天动听的服务端，原路返回HTTP响应，获取到的HTTP响应其实就包含了该 APP的下载链接。

        原路返回HTTP响应时，还是会经过运营商的网络设备，这个时候运营商可以选择劫持这个HTTP请求。 运营商劫持之后，就发现这个请求是要下载天天动听，它不想让我们下载天天动听，于是把服务器交给用户的HTTP响应给偷偷篡改成"QQ浏览器"的下载地址了，再把这个HTTP响应返回给浏览器。

这个时候，用户本来想下载天天动听，却变成了下载QQ浏览器。

        所以：因为http的内容是明文传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务 器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。

        劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对信息进行加密。

在互联⽹上,明文传输是比较危险的事情!!! HTTPS就是在HTTP的基础上进行了加密,进⼀步的来保证用户的信息安全~ 

        我们上网的时候一定会处于一个局域网，局域网一定会有路由器，如果我们是明文传送的，那么我们的HTTP请求就会被局域网捕捉到了，别人就可以充当中间人，篡改我们的HTTP请求和响应。 

2.2.3.常用的加密方式 

常见的加密方式有以下两种：

• 1.对称加密

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

• 特征:加密和解密所用的密钥是相同的
• 常见对称加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等
• 特点:算法公开、计算量小、加密速度快、加密效率高对称加密其实就是通过同一个"密钥",把明文加密成密文,并且也能把密文解密成明文.

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

假设 明文a=1234,密钥 key=8888

则加密 a^key 得到的密文 b为 9834，然后针对密文 9834 再次进行运算 b^key，得到的就是原来的明文 1234.(对于字符串的对称加密也是同理,每一个字符都可以表示成一个数字)

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

• 2.非对称加密

1. 需要两个密钥来进行加密和解密，这两个密钥是公开密钥(publickey，简称公钥)和私有密钥(private key，简称私钥)。
2. 常见非对称加密算法(了解):RSA，DSA，ECDSA
3. 特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

非对称加密要用到两个密钥,一个叫做"公钥",一个叫做"私钥".公钥和私钥是配对的.

最大的缺点就是运算速度非常慢，比对称加密要慢很多

1. 通过公钥对明文加密,变成密文
2. 通过私钥对密文解密,变成明文

也可以反着用

1. 通过私钥对明文加密,变成密文
2. 通过公钥对密文解密,变成明文

非对称加密的数学原理比较复杂，涉及到一些 数论 相关的知识。

这里举一个简单的生活上的例子.

A 要给 B 一些重要的文件，但是 B 可能不在。

于是A和 B提前做出约定：B 说:我桌子上有个盒子，然后我给你一把锁，你把文件放盒子里用锁锁上，然后我回头拿着钥匙来开锁取文件.

在这个场景中,这把锁就相当于公钥,钥匙就是私钥。

公钥给谁都行(不怕泄露)，但是私钥只有 B自己持有，持有私钥的人才能解密。

1. 对称加密算法在加密和解密过程中使用相同的密钥，速度较快，但需要事先共享密钥，导致密钥管理的复杂性。
2. 非对称加密算法使用不同的密钥进行加密和解密，提供更好的安全性和身份验证，但速度较慢。

一种常见的方式是在通信开始时使用非对称加密算法来安全地交换对称密钥，然后使用对称加密算法进行实际的数据传输。 我们下面再讲。

3.HTTPS的工作过程探究

我们自己给HTTP逐步设计一套安全方案，设计完一套，逐个分析各个方案的不足，最后得出最完美的，那个就和我们的HTTPS差不多了

最开始的问题是HTTP对于报文是明文传递的。我们需要对其进行加密

3.1.加密方案的选定

• 方案一：只使⽤对称加密

         如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除非密钥被破解）

 

• 我们先看看这个方案的结果

        引⼊对称加密之后，即使数据被截获，由于⿊客不知道密钥是啥，因此就⽆法进⾏解密，也就不知道请求 的真实内容是啥了。这确实保证了数据的安全传输。

        但事情没这么简单，服务器同⼀时刻其实是给很多客户端提供服务的，这么多客户端，每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了)， 因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很⿇烦的事情~

• 但是我们怎么实现呢？

有人想说下面两种

• 方案A：服务器生成密钥后传递给客户端
• 方案B：客户端生成密钥后传递给服务器

但是大家有没有想过，这两种方案都是在传递密钥（明文状态），这样子一定会被中间人截获。

        但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了. 因此密钥的传输也必须加密传输! 但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有 蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了

• 由于结果不好和不可能实现，我们就不考虑单独使用对称加密

• 方案2-只使用非对称加密
• 我们要知道，不是只有公钥才能加密，私钥也可以加密，同理公钥也能解密，私钥也能解密

• 我们先看浏览器到服务器这段路怎么保障安全？

鉴于⾮对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。

• 但是服务器到浏览器的这条路怎么保障安全？

        如果服务器⽤它的私钥来对数据进行加密，然后传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。

• 这个也不安全

• 方案三——双方都使用非对称加密

我们看了方案2，会不会想到，让服务器和浏览器双方各持有自己的密钥和公钥。

• 1. 服务端拥有公钥A1与对应的私钥A11，客户端拥有公钥B1与对应的私钥B11
• 2. 服务器先把公钥A1以明⽂⽅式传输给浏览器，浏览器将公钥B1传递给服务器
• 3. 客户端给服务端发信息：先⽤A1对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 A11
• 4. 服务端给客户端发信息：先⽤B1对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥 B11

这样貌似也行啊，但是效率太低 依旧有安全问题。

•  方案四——非对称加密+对称加密

这个方案来弥补第一个方案的遗憾

• 服务端具有非对称公钥S1和私钥S11
• 客户端发起https请求，获取服务端公钥S1
• 服务端以明文方式发送公钥S1给客户端
• 客户端在本地生成对称密钥C，通过公钥S1加密，发送给服务器.
• 由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文,也就无法获取到对称密钥(真的吗?)
• 服务器通过私钥S11解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥C加密给客户端返回的响应数据.
• 后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.

这种解决方案首先使用非对称式加密保证了 密钥传输时的安全性，确保只有客户端和服务器拥有 密钥，因为 密钥 加密与解密的特点就是 效率高，所以后续在传输数据时，整体效率就会高很多

• 由于对称加密的效率⽐⾮对称加密⾼很多,因此只是在开始阶段协商密钥的时候使⽤⾮对称加密,后 续的传输仍然使⽤对称加密. 虽然上⾯已经⽐较接近答案了，但是依旧有安全问题 。 

 3.2.加密方案的缺陷

     我们上面得到了最接近答案的方案四，在方案4中，客户端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥 S进行加密，中间⼈即使窃取到了数据，此时中间⼈确实⽆法解出客户端形成的密钥X，因为只有服务器有私钥S' 。

        但是中间人的攻击，如果在最开始握⼿协商的时候就进⾏了，方案四那就不⼀定安全了.

• 中间人攻击-针对上面的场景

1. 服务器具有非对称加密算法的公钥S，私钥S'
2. 中间人具有非对称加密算法的公钥M，私钥M'
3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端
4. 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端
5. 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，自己形成对称密钥X，用公钥M加密X，形成报文发送给服务器
6. 中间人劫持后，直接用自己私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
7. 服务器拿到报文，用自己的私钥S'解密，得到通信秘钥X
8. 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

• 上⾯的攻击方案，同样适⽤于方案2，方案3 问题本质出在哪⾥了呢？

客户端⽆法确定收到的含有公钥的数据报⽂，就是目标服务器发送过来的！

        被攻击的核心原因：客户端无法验证公钥的合法性（客户端不认识服务器），此时就需要一个公平公正的第三方机构来进行认证，确保客户端所连接的服务器是合法的

3.3.引入证书

3.3.1.摘要算法

摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。

你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。

换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。

摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”（collision，也叫碰撞）的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”，让这种可能性尽量地小。

3.3.2.数字摘要

数字摘要 又称为 数字指纹，指通过哈希函数对信息进行运算后生成的一串定长字符串，具有很强的唯一性，数字摘要 并不能加密，而是用于快速判断原始内容是否被修改

1. ⭐数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被窜改。
2. ⭐摘要常见算法:有MD5、SHA1、 SHA256、SHA512等， 算法把无限的映射成有限，因此可能会有碰撞(两个不同的信息，算出的摘要相同，但是概率非常低)
3. ⭐摘要特征:和加密算法的区别是，摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息，通常用来进行数据对比。

        摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

        比如，你发了条消息：“转账 1000 元”，然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改。

        如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被窜改，是不可信的。

        这种技术还可以用于网盘存储中，比如xxx网盘中就有一个 “秒传功能”，可以快速上传目标文件，其实就是根据用户上传的文件生成了 数字摘要，将该摘要与服务器中已经记录好的摘要信息进行对比，如果发现该摘要，就证明服务器中已经存在这个文件了，无需再重复上传，只需要在用户的上传目录中建立目标文件的软链接或者硬链接，就可以实现 “秒传”。

       就比如我上传了一部《飞驰人生2》，网盘根据用户上传的文件生成了 数字摘要，发现这个服务器里已经有人上传过《飞驰人生2》了，这个时候服务器就可以不用再上传了，直接给我返回了一个链接，这样子，我一点那个链接，就去到别人上传的《飞驰人生2》里面了。

3.3.3.数字签名

数字签名 是指将 数字摘要 通过加密后得到的字符串，计算过程需要借助 密钥

        数字签名（又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。它是一种类似写在纸上的普通的物理签名，但是使用了公钥领域的技术来实现的，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

数字签名的验证过程如下：

• 发送方使用哈希函数对消息A进行摘要处理，生成消息摘要A1。
• 发送方使用密钥对消息摘要A1进行加密，生成数字签名A2。
• 发送方将消息A和数字签名A2一起发送给接收方。
• 接收方使用发送方的公钥对数字签名A2进行解密，得到消息摘要B1。
• 接收方使用哈希函数对收到的消息A进行摘要处理，得到消息摘要B2。
• 接收方比对解密得到的消息摘要和计算得到的消息摘要，如果一致，则证明消息的完整性和真实性得到了保证。

为什么不直接对原始内容进行加密后得到 数字签名？

• 因为在经过哈希函数后，会得到一串定长且唯一的字符串，更适合进行加密计算 

3.3.4.CA证书

• 数字证书是什么？

我们都知道，互联网是虚拟的，通过互联网我们无法正确获取对方真实身份。

而通过数字证书可以明确对方身份

比如：

        小美通过网络发送一份电子版合同（邮件或电子版的纸质合同）给你，你是无法确定这份文档是不是小美发送的，有没有被篡改。通过数字签名的电子合同可以防篡改，可以确定这份电子合同是不是小美发送给你的。

        数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在互联网上验证通信实体身份的方式。

        数字证书不是数字身份证，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。其作用类似于现实生活中司机的驾驶执照或日常生活中的身份证。

• CA是什么？

        上面提到的数字证书就是CA发行的。

        CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。

        CA 拥有一个证书（内含公钥和私钥）。

        网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。

 

       在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。 

• CA证书是什么？

顾名思义，CA 证书就是CA颁发的证书。

       CA证书也就我们常说的数字证书，包含证书拥有者的身份信息，CA机构的签名，公钥和私钥。身份信息用于证明证书持有者的身份；CA签名用于保证身份的真实性；公钥和私钥用于通信过程中加解密，从而保证通讯信息的安全性。

  

      以上看完了还是很晕咋办？没关系，只要记得以下两点就可以了：CA是权威可信的第三方机构，是“发证机关”。CA证书是CA发的“证件”，用于证明自身身份，就像身份证和驾驶证。

大家在网上肯定看过下面这张图片吧

 这个证书就是CA证书 

       在今天，如果想使用 HTTPS 协议，服务器就需要向 CA机构 申请一份 CA证书，证书就如同该服务的身份证，其中包含了 证书申请者信息、公钥信息 等重要信息，服务器在成功申请到证书后，就会将证书交给客户端（也就是浏览器），以进行证书认证和获取 公钥

下面是申请CA证书的业务流程：

1. 申请公开密钥：服务器运营人员向数字证书认证机构提出公开密钥的申请。
2. 验证身份：数字证书认证机构会验证申请者的身份，确保他们是他们声称的那个人或组织。
3. 数字签名：一旦身份得到确认，数字证书认证机构就会对申请的公钥进行数字签名。这个签名保证了公钥的真实性和完整性。
4. 颁发证书：数字证书认证机构将签名的公钥放入一个公钥证书中，并将这个证书颁发给服务器。
5. 发送证书：服务器将这份由数字证书认证机构颁发的公钥证书发送给客户端，以便进行公开密钥加密的通信。

        注意这个证书不是挂起来的证书，而是安装在服务器的证书。

我们看看数字证书通常包含了：

1. 服务器的非对称密钥中的公钥；
2. 持有者信息；
3. 证书认证机构（CA）的信息；
4. CA 对这份文件的数字签名及使用的算法；
5. 证书有效期；
6. 还有一些其他额外信息；

首先我们要了解一些预备知识

1.浏览器内置有CA证书：

• 关于认证机关的公钥的安全转交问题，由于直接通过通信方式转交存在困难，大多数浏览器开发商在发布浏览器版本时，会预先在浏览器内部植入常用认证机关的CA证书。
• 客户端（如浏览器）内置了很多受信任的CA证书。这些CA证书中的公钥是用来验证服务器证书的签名的。
• 这些内置的CA证书是由浏览器厂商和操作系统开发商精心管理和更新的，它们确保客户端可以信任来自这些CA的证书。
• 这样，当客户端访问一个使用HTTPS的网站时，浏览器可以自动验证网站证书的有效性，确保用户的安全。

我们可以在浏览器设置里面看到这些内置的证书

 

2.客户端接收到证书后，会进行以下操作：

1. 验证数字签名：客户端使用数字证书认证机构的公开密钥来验证证书上的数字签名。
2. 确认证书有效性：如果签名验证通过，客户端就可以确认两件事情：一是证书是由一个真实有效的数字证书认证机构签发的；二是服务器的公开密钥是可以信赖的。

3.数字签名的验证过程如下：

• 发送方使用哈希函数对消息A进行摘要处理，生成消息摘要A1。
• 发送方使用密钥对消息摘要A1进行加密，生成数字签名A2。
• 发送方将消息A和数字签名A2一起发送给接收方。
• 接收方使用发送方的公钥对数字签名A2进行解密，得到消息摘要B1。
• 接收方使用哈希函数对收到的消息A进行摘要处理，得到消息摘要B2。
• 接收方比对解密得到的消息摘要和计算得到的消息摘要，如果一致，则证明消息的完整性和真实性得到了保证。

4.CA证书数字签名的验证过程：

1. CA证书的签发：当客户端向服务器发起请求时，服务器会发送它的数字证书。这份证书中包含了服务器用于加密的公钥和其他信息（如服务器的身份信息）。服务器的数字证书是由CA机构签署的，数字签名是由CA使用其私钥生成的。服务器在向CA机构申请生成CA证书时，CA机构会对证书中的数据（如服务器的公钥和身份信息）进行哈希运算得到数字摘要，最后CA机构使用CA的私钥对这个哈希值进行加密，生成数字签名。服务器将申请到的这个数字签名和证书一起发送给客户端。
2. CA证书的验证：当客户端收到服务器发送的证书后，它会使用内置的CA公钥来解密证书中的数字签名。如果解密成功，并且解密后的哈希值与客户端自己计算的哈希值一致，那么客户端就可以确认这个证书确实是由受信任的CA签发的，且在传输过程中没有被篡改。

也就是说，证书的工作过程如下 

 

• 现在有一个问题，存在中间人攻击并对数字证书进行了篡改，我们是如何保证客户端收到的服务器发送的数字签名的正确性？

存在以下情况：

1. 证书篡改：攻击者可能会修改证书的内容，比如更改公钥为攻击者自己的公钥，或者修改证书中的其他信息。
2. 证书替换：攻击者可能会用自己的证书（可能是自签名的或者由不可信的CA签发的）替换掉原始的证书。

如果收到了中间人攻击：

1.中间人无法伪造签名：

• 即使中间人截获了服务器发送的证书，并试图篡改证书内容（例如，替换服务器的公钥），他也无法生成一个有效的数字签名，因为他没有CA的私钥。
• 只有拥有CA私钥的机构（即真正的CA）才能生成匹配的签名。中间人即使知道生成签名的算法，也无法在没有CA私钥的情况下生成合法的签名。

2.篡改后的证书会导致验证失败：

• 如果中间人篡改了证书内容（如替换了服务器公钥），客户端在解密数字签名后会发现，解密得到的哈希值与客户端计算出的哈希值不匹配。
• 这意味着证书已经被篡改，客户端会拒绝信任这个证书，并且中止与服务器的通信。

也就是说中间人如果强行篡改服务器发向客户端的证书，客户会发现证书中的明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

 3.4.方案五——HTTPS真容

学习完上面的知识，我们终于可以得到最终方案了。

我们的方案5（「非对称式加密」+「对称式加密」+「CA证书」）是在方案4的基础上面增加的CA证书这个环节。我们的方案5也刚好就是HTTPS锁采取的方案。

HTTPS的整体过程：

• 服务端具有非对称公钥A1和私钥A2
• 客户端向服务器发送HTTPS请求，要求建立安全连接.
• 在服务器收到客户端请求的时候，服务器先把自己生成的一个非对称加密的公钥A1通过CA证书传递给客户端。（注意这个过程服务端使用了CA私钥对我们的证书进行了加密）
• 客户端通过CA证书的公钥对证书进行验证（浏览器/客户端那边内置了CA公钥，可以解密CA私钥加密的数据）。验证成功后，客户端端根据得到服务器发送过来的公钥A1，对自己生成的对称加密的密钥B进行加密。然后将密钥B发送给服务端
• 服务器得到由客户端使用服务器公钥A1加密过的数据（这个数据是客户端生成的对称加密的密钥B），最后使用服务器的私钥A2进行解密 得到对称密钥B。
• 后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.

整个过程确保了数据在传输过程中是加密的，并且只有通信的双方能够解密，防止中途被窃听或篡改。操作系统和浏览器会定期更新信任的CA证书列表，确保新增的信任根证书和已撤销的CA证书的变化能及时反映在用户设备上。

也就是说HTTPS工作过程设计到的密钥有三组：CA的非对称密钥：CA公钥，CA私钥、服务器的非对称密钥：公钥A1，私钥A2，以及客户端和服务器之间的对称密钥B。

HTTPS共作过程中涉及到的密钥有三组：

1. 第⼀组（非对称加密）：用于校验证书是否被篡改。服务器持有私钥（私钥在形成CSR文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的CA认证机构有哪些，同时持有对应的公钥）。服务器在客⼾端请求时，发送携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。
2. 第二组（非对称加密）：用于协商生成对称加密的密钥。客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器,服务器通过私钥解密获取到对称加密密钥。
3. 第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。其实⼀切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的。

其实⼀切的关键都是围绕这个对称加密的密钥B，其他的机制都是辅助这个密钥工作的。

1. 第⼆组非对称加密的密钥A2是为了让客户端把这个对称密钥B传给服务器
2. 第⼀组非对称加密的CA密钥是为了让客户端拿到第⼆组非对称加密的公钥——CA机构的公钥。

 如果对HTTPS还是一头雾水，就看看下面这个

1. 客户端发起请求：客户端向服务器发送HTTPS请求，要求建立安全连接。
2. 服务器响应并发送证书：服务器收到请求后，会发送自己的数字证书（包含服务器自己生成的非对称密钥中的公钥、数字签名以及其他的信息）给客户端。这个证书由可信的证书颁发机构（CA）签名。
3. 验证证书：客户端收到证书后，会使用内置的CA公钥来验证服务器证书的真实性。如果证书有效且可信，客户端会继续，否则会中断连接并向用户发出警告。
4. 生成对称加密密钥：客户端验证证书成功后，会生成一个随机的对称加密密钥，并使用服务器的公钥对客户端自己生成的密钥进行加密。
5. 发送加密的对称加密密钥：客户端将加密后的对称加密密钥发送给服务器。
6. 服务器解密对称加密密钥：服务器使用自己的私钥解密收到的对称加密密钥，从而获得客户端生成的对称加密密钥。
7. 建立安全通信：从此刻起，客户端和服务器都使用这个对称加密密钥进行通信。这种对称加密方式可以保证数据传输的保密性和完整性，因为对称加密在速度和效率上优于非对称加密。

上面就是HTTPS的做法

3.5.HTTPS和HTTP的区别

Https是身披SSL/TLS外壳的HTTP协议，它并非一个新的协议而是在HTTP的基础上新增了安全层(SSL/TLS),HTTPS先和安全层通信，然后安全层和TCP层通信。

HTTPS和HTTP的区别主要在于安全性和加密方式：

1. 建立连接时：HTTPS比HTTP多了TLS的握手过程。当使用HTTPS时，客户端和服务器在建立连接之前，会先进行一个叫做TLS握手的过程。这个过程包括客户端向服务器索要并验证服务器的公钥，确保服务器是它声称的那一个。然后，双方会协商产生一个会话秘钥，这个秘钥用来加密双方之间的通信内容。
2. 传输内容时：HTTPS会把数据进行加密，通常是使用对称加密。这意味着在传输过程中，数据是以加密的形式传输的，这样即使数据在传输过程中被截获，攻击者也无法理解数据的内容。
3. HTTP协议是一种以字符串明文传输的简单的请求-响应协议，在传输层基于TCP协议实现。HTTP协议默认使用80端口。HTTPS协议是一种对HTTP加密后的协议，主要是多了身份验证以及加密传输等功能，HTTPS协议默认使用443端口。

        总结来说，HTTPS通过TLS协议提供了一种加密的通信方式，可以防止数据在传输过程中被截获和窃取，而HTTP则是明文传输，没有加密。因此，HTTPS比HTTP更加安全。