【计算机网络】HTTPS协议原理

目录

一. HTTPS的基础概念

二. 概念准备

1. 密码学

2. 为什么要加密

三. 常见加密方式

1. 对称加密

2. 非对称加密

四. HTTPS原理探究

五. CA认证

1. 数据指纹&&数据摘要

2. 证书

3. 签名与验证

4. 琐碎知识点

5. 总结——完整流程

结束语

---

一. HTTPS的基础概念

• HTTPS 是一种应用层协议，定义了运行在不同端系统上的应用程序进程如何相互传递报文。
• HTTPS 经由 HTTP 进行通信，但在 HTTP 协议的基础上引入了一个加密层—— SSL/TLS ，加密报文
• HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中可能会出现被篡改的情况。HTTPS 开发的主要目的，就是保护交换数据的隐私和完整性
• HTTPS 默认工作在 TCP 协议的端口号为443

二. 概念准备

1. 密码学

自古以来，当数据通信的双方，不想内容被第三方截获，就需要对内容进行双方协商的加密。

比如密折，藏头诗，电报等等。

• 原本要传输的数据是，明文
• 经过双方协商一致的方法将明文变化后的内容是，密文
• 将明文变成密文的过程叫做，加密
• 将密文恢复为明文的过程叫做，解密
• 明文和密文变化使用的方法叫做，密钥

加密解密已经发展成了一个独立的学科：密码学。密码学的奠基人，正是计算机科学的祖师爷之一：艾伦·?席森·图灵。图灵奖正是取自这位祖师爷

2. 为什么要加密

因为HTTP是明文传输，所以传输内容只要被截获，就知晓了通信的内容。

早些时候，只使用HTTP协议时，会出现运营商劫持事件。由于任何网络通信都需要经由运营商的设备（路由器，交换机等），所以 HTTP 的明文数据必定会被运营商知晓。而运营商此时就可以对其中数据进行篡改

比如要下载某个软件，点击下载链接，浏览器会向该下载链接的服务器发送一个 HTTP 请求，而该请求经由协议封装，发送至网络，经由运营商的路由器转发，运营商的路由器也是一台主机，会对协议进行解包，运营商就可以知道请求内容，同时，服务器返回的响应报文同样也会被运营商截获，如此就可以篡改其中内容，将下载内容改成其他软件，谋获非法利益

其实，不只运营商可以截获通信数据，一些黑客或非法人员都可以通过HTTP明文的缺陷窃取用户隐私或者篡改内容

这类角色称为中间人

HTTPS产生的目的，就是将明文改为密文，并进一步保证用户的信息安全

三. 常见加密方式

1. 对称加密

• 采用单钥密码系统的加密加法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所使用的密钥是相同的
• 常见的对称加密算法：DES，3DES，AES，TDEA，Blowfish，RC2等
• 特点：算法公开，计算量小，加密速度快，加密效率高

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

对称加密的简单例子：异或计算

假设明文：a = 1234，密钥：key = 8888

加密：a ^ key = b

密文：b = 9834

解密：b ^ key = 1234 = a

2. 非对称加密

• 需要两个密钥进行加密和解密。两个密钥分别为公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）
• 常见非对称加密算法：RSA，DSA，ECDSA
• 特点：算法强度复杂，安全性依赖于算法与密钥，但由于算法复杂，加密解密的速度没有对称加密解密快

非对称加密有两种用法：

1. 公钥加密明文，私钥解密密文

2. 私钥加密明文，公钥解密密文

日常生活中的非对称加密，比如门锁和钥匙。门锁是公钥，谁都可以尝试解密，而钥匙是对应的私钥，只有配对的钥匙才能打开门锁

四. HTTPS原理探究

有了对称加密和非对称加密的认知，接下来尝试规避中间人攻击

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

双方都各自持有同一个密钥X，因为是对称加密，所以加密和解密都使用密钥X。

1. 客户端通过密钥X加密请求，形成密文请求
2. 服务器通过密钥X解密
3. 服务器通过X加密响应，返回密文响应
4. 客户端通过X解密响应，完成通信

?引入对称加密后，即使数据被截获，中间人没有密钥X，无法进行解密，也就不知道请求和响应的真实内容是啥

---

上述通信看似规避了中间人攻击，实则不然。

上述通信的中间人是在客户服务器都协商好公钥后才出现的。公钥必定需要通信前协商，不可能使用总所周知的公钥，所以每次通信，公钥都是随机生成的。而公钥的协商只能明文传输，如果此时中间人已存在，公钥则会被截获

如此上述对称加密仍是不安全的，因为在中间人拥有密钥X后，同样可以对密文请求和密文响应解密

---

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

鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前后使用这个公钥加密再传输，从客户端到服务器信道似乎是安全的，因为只有服务器有相应的私钥能解开公钥加密的数据

但服务器到浏览器的信道如何保证安全？服务器到浏览器是不安全的

服务器使用私钥加密数据，将密文传输给浏览器，浏览器可以使用公钥解密，但公钥最开始是明文传输，如果被中间人截获，那服务器到浏览器的信道就是不安全的。

而且对于浏览器到服务器也是不安全的

中间人只需要在最开始服务器给浏览器公钥S时，保留S，给浏览器自己的 公钥M，就可以截获通信

---

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

1. 服务器拥有公钥S和私钥S'，客户端拥有公钥C和私钥C'
2. 客户端和服务器交换公钥
3. 客户端给服务器发消息：用 公钥S 对数据加密，发送。只有服务器有 私钥S' 可以解密
4. 服务器给客户端发消息：用 公钥C 对数据加密，发送。只有客户端有 私钥C' 可以解密

首先，这样通信的效率太低。非对称加密解密的复杂度高，速度慢

其次，中间人只要像破解方案二那样，准备自己的公私钥在最开始公钥交换时替换发送给对方的公钥就可以窃取后续数据

---

4. 方案四——非对称加密+对称加密

该方案依然无法规避中间人攻击，但是优化了方案三的效率问题

1. 服务器有公钥S和私钥S'，浏览器(客户端)有公钥C

2. 服务器将公钥S给客户端，客户端用公钥S加密公钥C，传输给服务器

3. 服务器用私钥S'解密，获得公钥C

4. 后续通信都使用公钥C，即对称加密通信

如此，只有一次非对称加密，后续通信都使用对称加密，速度快，效率高

但依然存在问题，只要在最开始时，中间人截获服务器的公钥S，替换为公钥M，即可获得客户端的公钥C。

究其原因是，客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送的

五. CA认证

1. 数据指纹&&数据摘要

• 数据指纹(数据摘要)，其基本原理是利用单向散列函数(Hash函数)对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，因为无法恢复，但仍可以用来判断数据是否被篡改。数据即使进行细微更改，形成的数据指纹都会有很大差异
• 摘要常见算法：有MD5，SHA1，SHA256，SHA512等，算法把无限的映射成有限，因此可能会有碰撞(两个不同的信息，算出的摘要相同，但是概率非常低)
• 摘要特征：和加密算法的区别是，摘要严格意义并不是加密算法，因为无法解密，通常用来进行数据对比

2. 证书

服务器在使用HTTPS前，需要像CA机构申请一份数字证书

证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

数字证书里含有证书申请者信息，公钥信息。服务器把证书传输给浏览器，浏览器从证书中获取公钥即可。证书证明了服务端公钥的权威性

证书可以理解成是一个结构化的字符串，里面包含以下信息：

1. 证书发布机构? 2.证书有效期? 3. 公钥? 4. 证书所有者? 5. 数字签名? ........?

数字签名：摘要经过加密，就得到了数字签名

注意：申请证书的时候，需要在特定平台生成，同时也要生成一对密钥，即公钥和私钥。这对密钥就是用来在网络通信中进行明文加密以及数字签名的。将各种信息集成在CSR文件中，发送给CA机构进行权威认证。

私钥服务器自己保留，用来后续进行通信（其实主要就是用来交换对称密钥——方案四）

可以使?在线?成CSR和私钥：https://myssl.com/csr_create.html

3. 签名与验证

在服务器向CA机构申请成功后，CA机构会给服务器颁发一份证书，其中包含

1. 证书信息(申请者信息，URL，过期信息)+服务器通信使用的公钥
2. 数字签名：将证书信息经由散列函数形成数字指纹，再用CA机构的私钥形成数字签名

当客户端向服务器发起连接后，服务器会先返回证书，客户端进行验证

1. 将证书信息和数字签名分开
2. 证书信息通过散列函数形成数字指纹
3. 数字签名通过浏览器/本地主机内置的CA机构的公钥解密出数字指纹
4. 对比两个数字指纹，如果相同，则数字签名有效且没有被篡改
5. 如果数字签名有效，则从证书信息中取出服务器的公钥，实行方案四的通信方式

?

客户端进行认证

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置了受信任的整数发布机构)
• 验证证书的内容是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个hash值(称为数据摘要)，设为hash1。然后计算整个证书的hash值，设为hash2，对比hash1和hash2是否相等，如果相等，说明证书没有被篡改过

中间人无可能篡改证书？

如果中间人篡改了证书，由于没有CA机构的私钥，所以无法hsah之后用私钥加密形成签名，那么就没办法对篡改后的证书形成匹配的签名，如果强行篡改，客户端收到该证书后会发现明文和签名解密或的值不一致，则说明证书已经被篡改，证书不可信，从而终止向服务器传输数据，防止信息泄露

中间人有无可能掉包证书？

首先中间人没有CA私钥，无法制作假证书，若中间人向CA机构申请了真证书，用该证书进行替换，但证书中的证书信息包含了域名等服务器认证信息，如果被掉包，客户端依然可以辨别

4. 琐碎知识点

为什么要有数据摘要——散列函数的作用

常见的摘要算法有:MD5和SHA系列，以MD为例，摘要算法的特点

• 定长：无论多长的字符串，计算出来的 MD5 值都是固定长度(16字节版本或者32字节版本)
• 分散：源字符串只要改变一点点，最终得到的 MD5 值都会差别很大
• 不可逆：通过源字符串生成 MD5 很容易，但将 MD5 还原成源字符串理论上是不可能的

正因为这些特性，可以认为如果两个字符串的 MD5 值相同，则认为这两个字符串相同

同时因为摘要定长，方便比对，校验速度快，不需要验证原字符串（证书）

5. 总结——完整流程

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

• 第一组（非对称加密）：CA机构的公私钥。用于校验证书是否被篡改。客户端持有公钥(操作系统包含了可信任的CA机构有哪些，同时持有对应的公钥)，私钥只有CA机构有。服务器接受客户端的请求后，返回携带签名的整数，客户端通过CA机构的公钥进行证书验证，保证证书的合法性。
• 第二组（非对称加密）：用于协商生成对称加密的密钥。客户端在进行证书验证后，证书有效则使用证书中的公钥（服务器申请证书时提交），给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密，获取对称加密密钥
• 第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密

---

第一组非对称加密的密钥是为了让客户端拿到第二种非对称加密的公钥

第二组非对称加密的密钥是为了让客户端将随机生成的对称密钥传输给服务器

结束语

本篇博客到此结束，感谢看到此处。
欢迎大家纠错和补充
如果觉得本篇文章对你有所帮助的话，不妨点个赞支持一下博主，拜托啦，这对我真的很重要。