【Linux】HTTPS协议

前言

本篇文章进行应用层中HTTPS协议的学习！！！

---

HTTPS协议原理

1、概念

前言：因为HTTP协议在进行报文传输时是在网络中裸奔的，中间人随时都可以窃取并且修改它

• HTTPS也是应用层的协议，它只是在HTTP协议的基础上引入了一个加密层（软件层SSL/TLS）

• HTTP协议内容都是按照文本的方式明文传输的，容易在传输过程中被窃取和篡改

• 加密层也属于应用层的范畴，不属于传输层，数据自顶向下流动时加密层对应用层报文进行加密

• 数据自底向上流动经过加密层会对已经加密的应用层报文进行解密

---

2、加密和解密

加密：

• 加密就是把应用层传输的明文数据进行一系列的转换，最后生成密文

• 解密就是把密文进行一系列的转换，还原成明文

• 在加密和解密过程中，往往需要一个或多个中间的数据，用来辅助进行这个过程，这样的中间数据成为”密钥“

密码学发展历史

【古代密码学发展历史】

• 83版<<⽕烧圆明园>>：有⼈要谋反⼲掉慈禧太后，恭亲王奕䜣给慈禧递的折子，折⼦内容只是扯⼀扯家常，套上⼀张挖了洞的纸就能看到真实要表达的意思

• 明⽂：“当⼼肃顺，端华，戴恒”(这⼏个⼈都是当时的权⾂，后来被慈禧⼀锅端)

• 密文：奏折全文；密钥：挖了洞的纸

• 加密解密从古代至今已经发展成了一个独立的学科，也就是”密码学“

• 密码学的奠基人，也正是计算机科学的祖师爷之一的”艾伦·⻨席森·图灵“，计算机领域中的最⾼荣誉就是以他名字命名的"图灵奖"

---

为什么要进行加密解密呢？

运营商劫持

• 中国在早十几年之前还是在用HTTP协议进行数据传输的，在HTTPS还没有普及的时候，网络传输的数据会经过各种中间设备（运营商网络设备：路由器、交换机等）

• 运营商的网络设备可以解析出你传输的数据内容，并且进行篡改，因为HTTP是明文传输的

例子

• 当我们在浏览器上下载某些软件时，大家应该都遇到过下载的软件变成其他软件的问题吧

• 下面的点击下载按钮，其实就是向服务器发送一个HTTP请求，获取到的响应报文里会包含该APP的下载链接

• 运营商劫持响应报文后，发现下载的APP是天天动听音乐，它可以把下载链接篡改成”QQ浏览器“的下载链接

未被劫持的效果，点击下载按钮，就会弹出天天动听的下载链接

---

已被劫持的效果，点击下载按钮，就会弹出QQ浏览器的下载链接

运营商劫持图解

总结：

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

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

• 不止运营商可以劫持，其他的⿊客也可以⽤类似的⼿段进行劫持，来窃取⽤⼾隐私信息，或者篡改内容

• 试想⼀下，如果黑客在用户登陆⽀付宝的时候获取到用户账户余额，甚⾄获取到用户的⽀付密码

• 在互联网上，明文传输数据是非常危险的事情！！！

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

---

3、常见加密方式

3.1、对称加密

概念

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

• 特征：加密和解密的密钥都是相同的

• 常见的对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等

• 特点：算法库开源、计算量小、加密速度快、加密效率高

• 对称加密其实就是通过同一个“密钥”，把明文加密成密文，并且也能用密钥将密文解密成明文

举个例子

按位异或运算符的例子

• 比如传输的数据为int x = 100，辅助加密的密钥为int key = 123，我们使用按位异或运算的方式进行加密

• 得到加密后的密文为int ciphertext = 23

• 对端收到密文后通过相同的密钥进行解密就能拿到数据了，过程（ciphertext ^ key = 23 ^ 123 = 100）

• 这只是一个简单的例子方便理解，真正的加密解密是不可能这么简单的！！！

---

3.2、非对称加密

概念

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

• 非对称加密可以通过公钥对明文加密，变成密文；通过私钥对密文解密，变成明文

• 也可以反着用，通过私钥对明文加密，变成密文；通过公钥对密文解密，变成明文

• 常见非对称加密算法：RSA、 DSA、ECDSA等

• 特点：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快

• 公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密算法慢得多

举个例子

• A 要给 B一些重要的文件，但是B可能不在，与是A 和 B提前做出约定

• B说：我桌子上有个盒子，然后我给你一把锁，你把重要的文件放进盒子里用锁锁上，后面我回来的时候拿着钥匙来开锁就好

• 在这个场景中，这把锁就相当于公钥，钥匙就是私钥，公钥（锁）给谁都可以（因为不怕泄漏），但是私钥只有 B 自己持有，持有私钥的人才能进行解密（打开盒子）

---

4、数据摘要和数据指纹

概念

• 数据摘要也叫数据指纹，它的基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数据摘要

• 数据摘要并不是一种加密机制，但可以用来判断数据有没有被篡改

• 常见单向散列函数算法：MD5、SHA1、SHA256等，它可以把无限的数据映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但概率非常低）

• 特征：它和加密算法的区别是，摘要的主要工作不是进行加密，因为没有解密，只不过从摘要反推原数据是不可能的，通常用于进行数据对比

• Hash函数主要用于完整性校验和提高数字签名的有效性（后面证书会讲）

数字签名

• 对数据摘要进行加密，就能得到数字签名了

---

5、HTTPS工作原理

前言：

• HTTPS既然要保证数据传输时的安全，就需要对其进行“加密”

• 网络传输中就不再直接进行明文传输了，而是传输“密文”

• 加密的方式有很多，但是整体可以分为两大类：对称加密 和 非对称加密

---

5.1、方案一 仅对称加密

前言：如果通信双方都持有相同的密钥，且没有第三方知道，这样双方通信是安全的

• 传输数据引入对称加密之后，即使数据被截获，由于截获的人不知道密钥是什么，因此无法进行解密，也就不知道请求报文内容是什么了

• 想法是挺好的，但是现实是残酷的，虽然下图中是完成了安全的通信，前提是怎么将自己生成的密钥交给对方呢？？？

---

解决方案

• 服务器同一时刻其实是给很多客户端提供服务的（多线程），服务器对客户端提供的密钥都必须是不同的

• 如果是相同的密钥就太容易扩散了，截取的人很容易拿到，因此服务器就需要维护每个客户端和每个密钥之间的关系

比较理想的做法是：在客户端和服务器连接的时候，双方协商这次的密钥是什么

• 但是，如果直接明文传输密钥，那么截取数据的人也就知道了，那么后续的加密操作就形同虚设了，所以说密钥传输也要进行加密的

• 但是想要对密钥进行加密，仍然需要双方协商一个”密钥的密钥“，这就成了先有鸡还是先有蛋的问题了，此时这种方案是不安全的

---

5.2、方案二 仅非对称加密

传输过程详解

• 服务器先把公钥以明文的方式传输给浏览器，之后浏览器向服务器请求时先用公钥对请求正文进行加密再传

• 从客户端到服务器这条信道似乎是安全的，因为只有服务器有对应的私有能解开公钥加密的密文

但是服务器到客户端这条信号要怎么保证呢？

• 如果服务器用私钥加密响应正文传输给浏览器，那么浏览器可以用公钥解密，但是这个公钥一开始是明文传输的，若这个公钥给中间人劫持到了，那么他也能进行解密

• 仅使用非对称加密只能保证单条信道的通信安全，不能保证另外一条信道是安全的

---

5.3、方案三 双方使用非对称加密

传输过程详解

• 客户端拥有公钥C和私钥C’，服务器拥有公钥S和私钥S‘

• 客户端和服务器协商交换公钥。客户端明文传输公钥C给服务器；服务器明文传输公钥S给客户端

• 客户端给服务器发请求，先用S对请求正文加密，再发送，只能由服务器解密，因为只有服务器有私钥S’

• 服务器给客户端发响应，先用C对响应正文加密，再发送，只能由客户端解密，因为只有客户端由私钥C‘

特点

• 效率太慢了，加密解密过程比对称加密慢了几个级别

• 依旧有安全问题，后面揭晓

---

5.4、方案四 非对称加密+对称加密

传输过程详解

• 服务器拥有非对称公钥S和私钥S’；客户端拥有对称密钥C

• 客户端发起HTTPS请求，获取服务端公钥S

• 客户端在本地生成对称密钥C，通过公钥S加密和请求正文一起传输给服务器

• 服务器通过私钥S’解密就能拿到对称密钥C和正文了

• 服务器通过对称密钥C加密响应正文，传输给客户端，客户端可以直接用C解密拿到明文
  

特点

• 该方案解决了第三个方案中效率的问题，第三个方案采用了二个非对称加密

• 由于对称加密的效率比非对称加密级别高很多，因此在开始阶段协商密钥的时候 使用非对称加密，后续的传输仍使用对称加密，这样效率就大大的提高了

• 但是这种方案跟前面二个方案一样仍然有安全的问题

---

6、中间人攻击

方案2、方案3和方案4都存在一个问题，如果在最开始，中间人就开始攻击了呢？

• 中间人攻击（Man-in-the-MiddleAttack），简称“MITM攻击”

• 在方案4中，客户端获取到公钥S后，通过它进行加密传输自己本地生成的对称密钥C和正文，服务端用S’解密拿到数据后，用公钥C对响应正文加密传输给客户端，此时中间人确实无法解析出客户端形成的密钥C，因为只有服务器有私钥S’

• 但是中间人的攻击，如果在最开始协商交换密钥的时候就进行了，那就不一定了，假设hacker成为了中间人

假设传输过程详解

• 服务端拥有非对称加密算法的公钥S私钥S’

• 中间人hacker拥有非对称加密算法的公钥M私钥M’

• 客户端向服务器发起请求，服务器明文传输公钥S给客户端

• 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成自己的公钥M，并将伪造的报文发给客户端

• 客户端收到报文，提取公钥M，自己本地生成对称密钥X，用公钥M加密X和正文，形成密文发送给客户端

• 服务器拿到报文，用自己的私钥S’解密，得到对称密钥X

• 双方开始采用X进行对称加密的方式进行通信。但是这一切都在中间人的掌握之中，劫持数据，进行窃听甚至修改，都是可以的

总结

• 上面的攻击方案同样适用于方案二和方案三

• 主要的问题是：客户端无法确定收到的含有公钥的报文，就是服务端发送过来的

---

7、解决方案

7.1、引入证书

CA认证

【CA认证 – 百度百科】

• 服务端在使用HTTPS协议之前，需要向CA机构申请一份数字证书

• 数字证书里面含有证书申请者信息、公钥信息等

• 服务器把证书传输给浏览器，浏览器从证书里面获取公钥就行了

• 证书就如同身份证，证明服务端公钥的权威性

证书其实是一个结构化数据，将它序列化后就变成了字符串，里面包含以下数据：

• 证书颁发机构、证书有效期、公钥、证书所有者、签名等等

• 申请证书的时候，需要在特定的平台生成，同时生成的证书也会一并生成一对密钥对，即公钥和私钥，它们是配套使用的

• 这对密钥对就是用来在网络通信中进行明文加密以及数字签名（对数字摘要/指纹进行加密）的

• 其中公钥会随着CSR文件，一起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信（主要用来交换对称密钥）

在线生成CSR和私钥网站：点击跳转 – https://myssl.com/csr_create.html

• 生成CRS文件之后，后续就是向CA机构进行申请认证了，不过过程很繁琐

• 网络有各种提供证书申请的服务商，一般真的需要，直接找平台解决就行

---

7.2、数字签名

概念

• 数字签名是发送者才能产生的，别人无法伪造的一段数字符串，这段数字符串同时也是对信息的发送者发送信息真实性的一个有效证明

• 数字签名是非对称密钥加密技术与数字摘要技术的应用

• 数据签名是先把要传输的正文拷贝一份采用单向Hash函数生成一个固定长的字符串摘要，随后将这个摘要用证书中的私钥进行加密成密文生成数字签名，最后将它放到正文中（正文包含原数据和数字签名）

• 如果明文传输的数据被修改了，那么只要将数据重新按上面的方式生成数据摘要，并且对数字签名用服务器传输的公钥进行解密拿到另外一个数据摘要，用这二个数据摘要进行比对就可以确定数据是否被篡改了

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专门为该网站形成数字签名，过程如下：

• CA机构拥有非对称加密算法的公钥A和私钥A’

• CA机构对服务端申请的证书明文数据进行单向Hash映射，拿到数据摘要

• 然后对数据摘要进行加密，使用CA机构的私钥A’进行加密，得到数字签名S

• 服务端申请证书的原数据明文（传输的正文）和数据签名S共同组成了数字证书，这样一份数字证书就能颁发给服务端了

---

7.3、方案五 非对称加密+对称加密+证书认证

传输过程

• 在进行通信之前，服务器要向CA机构申请证书，在获取到证书之后，与客户端通信会先给它返回一个证书 ，证书包含了服务器之前生成的公钥（私钥服务端自己保存），也包含了网站的身份信息

• 后面都是非对称加密和对称加密的方式进行网络数据传输了，主要还是刚开始校验传输的公钥S是否被篡改成中间人的公钥，如果不是就完成了密钥交换

客户端进行认证

• 当客户端获取到这个证书之后，会对这个证书进行校验（防止证书是伪造的）

• 判定证书的有效期是否过期（如果过期，浏览器会一般会弹出证书已经过期是否访问的窗口）

• 判定证书的发布是否受信任（操作系统中已内置的受信任的证书发布机构）

• 验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对数字签名解密，得到一个Hash值（数据摘要），设为hash1，然后计算整个证书的hash值，设为hash2，对比hash1 和 hash2 是否相同，如果相同，就没篡改过

---

查看Chrome浏览器的受信任证书发布机构

中间人有没有可能篡改我们的证书呢？？？

• 中间人如果篡改了证书的明文，由于他没有CA机构的私钥，所以无法Hash之后用私钥进行密钥形成数字签名，那么也没有办法对篡改后的证书形成匹配的签名

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

如果中间人掉包了整个证书呢？

• 因为中间⼈没有CA私钥，所以⽆法制作假的证书

• 所以中间⼈只能向CA申请真证书，然后⽤自己申请的证书进行掉包

• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来

• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括自己的