【Linux】https 协议
目录
一、https 协议
二、加密和解密
（一）为什么需要加密与解密
（二）加密和解密的过程
（二）常见的加密方式
1、对称加密
2、非对称加密
3、数据摘要
4、数字签名
三、https 的加密方式
（一）只使用对称加密算法
（二）只使用非对称加密算法
（三）对称加密+非对称加密
（四）数字证书的引入
（五）非对称加密+对称加密+数字证书
一、https 协议
【Linux】http 协议-CSDN博客
上节我们提到 http协议 是不安全，因其是按照明文进行数据传输的，导致用户信息很容易在网络传输的过程中被窃取篡改。
因此在实际情况中必须得考虑数据安全问题，https 协议就出现了。https 协议在 http协议 的基础上多了一个加密功能——SSL 协议。 https 协议保证了在网络传输过程中数据的安全，在传输层将数据向上交付时可以通过目的端口号区分 http 协议和 https 协议，具体通信过程于下文中讲述。
二、加密和解密
（一）为什么需要加密与解密
上文我们提到，http 协议在网络传输中是明文进行传输的，很容易被窃取和篡改，因此需要对传输数据进行加密，防止在网络传输过程中用户信息被窃取。
（二）加密和解密的过程
加密解密不仅仅是为了使传输数据在网络中不以明文的形式进行传输，而还要是发送方和接收方能够了解传输数据的真实内容。
加密就是将明文数据进行一系列转换形成密文，而解密则是将密文在进行一系列转换形成明文。
（二）常见的加密方式
本文不具体讨论加密算法。
1、对称加密
对称加密即采用单密钥的加密方法，加密与解密使用同一个密钥，这种加密方法成为对称加密。
- 常见的加密算法：AES、DES 和 3DES、Blowfish 或 IDEA系统。
- 特点：其核心优势在于速度快，适合处理大量数据，例如实时通信或大规模存储加密。
例如在上图中按位异或也是简单的对称加密策略。
2、非对称加密
非对称加密即采用两个不同的密钥分别进行加密与解密，这两个密钥分别是公钥和私钥。
- 常见的非对称加密算法：RSA、ECC 或 ECDSA。
- 特点：解决密钥分发问题，安全性更高，但计算效率低。
加密与解密过程：
1）加密过程：发送方使用接收方的公钥对明文假面，生成密文。
2）解密过程：接收方使用私钥解密密文，还原原始数据。
即可以使用公钥加密和私密解密，又可以使用私密加密和公钥解密。
3、数据摘要
数据摘要基本原理是通过单向哈希函数对原始数据将那些数学运算，生成固定长度的字符串。无论输入数据多大，输出长度始终固定。
数据摘要本身并不是用于加密的，其目的在于判断数据是否被篡改，只要数据发生了改变，再使用哈希函数进行运算得到的摘要也和原先的摘要不同。
- 常见的算法：MD5，SHA 系统以及 CRC32。
- 特点：按原始数据生成固定大小的字符串，因为使用哈希函数对原始数据进行加工，因此有可能出现哈希碰撞的可能（概率低）。除此之外，其具有唯一性、防篡改和不可逆的特点。
数据摘要并不是加密解密的方法，其主要用于传输文件中检查文件是否被损坏、系统存储用户密码的摘要而非明文等应用场景。
4、数字签名
数字签名是基于数据摘要生成的，通过使用单向哈希函数对原始数据进行处理得到数据摘要，再使用非对称加密算法对数据摘要进行加密即可得到数字签名。
三、https 的加密方式
（一）只使用对称加密算法
对称加密是是只使用一个密钥，一旦通信双方约定好同一个加密算法，即使只使用同一个加密算法也能完全满足需要。
这一方式看似没有问题，但如果再发送密钥的时候就被中间人（攻击者）截获了呢？如果这样的话，通信双方虽然对数据进行加密后再发送，而中间人也可以在通信双方约定密钥的时候获取密钥，此后也通过获取到的密钥对传输数据进行加密和解密，因此数据传输对中间人而言实际相当于明文传输，对称加密并没有起到任何作用。
（二）只使用非对称加密算法
使用非对称加密算法也会面临相同的困境，如果在约定公钥私钥时中间人通过劫持 https 请求也可以获取到公钥，用户的信息也会被泄漏甚至篡改。
所以只使用非对称加密算法无法解决在通信开始时被中间人窃取公钥的情况。
（三）对称加密+非对称加密
即使使用对称加密+非对称加密也无法解决上述情况，但在这里提到是因为二者的特性。
从上文可知，对称加密的特点是计算快，但安全性低，而非对称加密的特点是安全性更高，但是计算复杂效率慢，因此可以二者结合使用。
但非对称加密+对称加密依然不能解决通信安全问题。
（四）数字证书的引入
数字证书（Digital Certificate）是一种由权威机构颁发的电子凭证，用于在网络环境中验证通信实体的身份并保障数据传输安全
服务器在使用 https 前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。客户端向服务器请求公钥时，服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如⾝份证，是服务端公钥的身份证明。
当服务端申请向CA机构申请证书时，CA机构会该服务端进行审核，若通过后会为该网站形成数据签名：
1、CA机构拥有非对称加密的公钥A（公开）和私钥A'；
2、CA机构会对服务端的申请认证信息使用哈希算法（公开）形成数据摘要；
3、对数据摘要使用私钥A'进行加密得到数字签名S；
4、将服务端的证书明文和数字签名S共同组成数字证书，将其发送给服务端。
（五）非对称加密+对称加密+数字证书
在服务器和客户端建立连接时，服务器将数字证书发送给客户端，而客户端验证证书后就可以通过证书里的公钥对自身的对称加密的密钥进行加密后发送给服务器，当服务器接收后再使用私钥对传输数据进行解密后获取对称加密的密钥，之后通信双方就通过对称加密的密钥进行数据通信。
那为什么这种方式能够解决数据传输的安全性问题呢？中间人在开始阶段不也是能接收到数据证书吗？
针对以上问题我们简单说明下客户端如何验证证书，数字证书 = 数字证书明文 + 数字签名。当客户端接收到数字证书后，首先会使用哈希函数（公开）对数字证明明文进行加工形成数据摘要A，再使用CA机构公开的公钥对数字签名进行解密得到数据摘要B，之后对比数据摘要A和数据摘要B是否相同即可验证该证书是否有效（是否被修改或掉包），除此之外，还需要验证证书的有效期、域名匹配等等。
因此即使数据证书被中间人窃取，中间人也无法做出任何行为：
1、如果中间人劫持到了数字证书，对其内容进行修改后发送给客户端，客户端通过以上验证即可发现证书被修改过并将其丢弃；
2、如果中间人劫持到了数字证书，对其内容进行掉包后发送给客户端，客户端通过以上验证即可发现证书被修改过并将其丢弃；
因此无论中间人如何做，都无法对通信过程造成实质性的影响。因为中间人并不是知道CA机构的私钥，因此无法生成有效的证书，即无法通过证书明文形成符合的数据摘要。即使中间人真的使用有效的证书进行替换，因为CA证书的申请是需要经过CA机构认证审核，且替换后的证书包含了域名项，而这也会暴露中间人的真实信息。
随着社会科技的发展，实际中的证书并不是单单只有以上内容，其还涉及到了信任链、有效期、域名匹配等多维度检查，忽略任意环节都会导致安全认证失败，本文只做简单的介绍。