网络：HTTPS的加密

个人主页 ： 个人主页
个人专栏 ： 《数据结构》 《C语言》《C++》《Linux》

文章目录

前言

本文是对于https加密的知识总结

一、前置知识

HTTPS是什么？
HTTPS是一种基于HTTP的加密通信协议，通过传输加密(密文传输)和身份认证(CA证书)保证传输过程的安全性。它在HTTP的基础上加入SSL/TLS协议，用于对数据进行加密，并保证数据的完整性和安全性。

HTTP与HTTPS的区别

什么是加密
加密：把明文数据进行一系列变换，生成密文的过程。
解密：把密文再进行一些列变换，还原成明文的过程
在这个加密和解密的过程中，往往需要一个或多个中间数据，辅助进行这个过程，这样的数据称为密钥。
如下图所示：

client向server发送一个数据5，但client在发送数据5前，先对数据5(0101)进行 ^ 1(0001)操作得到 4(0100)，那么server在接受到数据4(0100)，要再次进行 ^ 1(0001)操作得到5(0101)。其中，数据5(0101)就是明文数据，数据4(0100)就是密文数据，而client对数据5(0101) ^ 1(0001)的操作就是加密，server对数据4(0100) ^ 1(0001)的操作就是解密，数据1(0001)就是密钥。我们举得这个列子就是对称加密

常见的加密方式

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

非对称加密：使用一对密钥来进行加密和解密操作，这对密钥分别是公钥和私钥。公钥是公开的，任何人都可以获取；而私钥是保密的，只有拥有者才知道。
常见非对称加密算法：RSA，DSA，ECDSA

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

公钥和私钥是配对的。
如通过公钥对明文加密，变成密文，再用配对的私钥对密文解密，变成明文。也可以通过私钥对明文加密，变成密文，再用配对的公钥对密文解密，变成明文。

数据摘要 && 数据指纹
数据指纹(数据摘要)，其基本原理是利用单向散列函数(hash函数)对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用了判断数据有没有被篡改。

摘要常见算法：有MD5，SHA1，SHA256，SHA512等，算法把无限的映射成有限，因此可能会有碰撞(两个不同的信息，算出摘要相同，非常低概率)
摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比

两个应用场景：

1. 用户账号密码登入的识别，服务器在用户第一次注册账号密码时生成一个数据指纹存储于mysql，等用户要再次登入识别时，将这次的账号密码形成的数据指纹与上次的作对比，如果相同就代表该用户的账号密码正确(假如该用户并没有修改过密码)
2. 某网盘秒传的功能，某网盘先将用户要上传的数据生成一个数据指纹，再去某网盘的数据库中取查找是否有相同的数据指纹，如果存在，就代表以前有用户存储过相同的数据，此时某网盘就可以提供秒传功能

以上内容大部分都是总结书上的知识。

二、加密方案

要保证网络传输过程中数据的安全，那么就要对数据进行加密，网络传输过程中使用加密后的密文。加密的方式有很多，但是整体可以分为两大类：对称加密和非对称加密

加密方案一：只使用对称加密

只使用对称加密，就代表client和server各自持有相同的一个密钥X，且该密钥X没有被其它人知道，这样双方通信就是安全的。但这可以做到吗？

中间人不知道密钥X，就不能对密文解密。

这里有两个问题(其实有三个问题，下面几个方案都有这一问题。但第三个问题，在数字签名时再说)。

• 问题1：这个密钥如何生成？是由client 和 server双方提前约定好吗？如果是这样的话，当累计的client只有几百个时，server还好存储，那当累计的client有几百万个时，这几百万个密钥的存储就是一大问题。那由client动态生成在传输给server吗？这就引发了下一个问题。
• 问题2：如何对由client动态生成的密钥加密？你会发现在只使用对称加密的想法中，我们像对这个动态生成的密钥加密是不可能的。因为这就是先有蛋还是先有鸡的问题，要对这个密钥加密，那client和server先约定好一个密钥进行加密的密钥C吗？这就有是问题一了，那再由client动态生成新的一个密钥C，在对这个密钥 + C形成密文吗？那server要对这个密文解密就要知道密钥C，那client不能明文传输C吧，只能加密C，client要如何对这个C加密呢？

所以综上所述，只使用对称加密的方法是不行的。

加密方案二：只使用非对称加密

由于方案一的其中一个问题是如何传递密钥，那我们就使用非对称加密看看吧。
由server先生成一对密钥(公钥S，私钥S’)，server先把S明文传输给client，client接受到S后，传输密文(数据 + S)，此时中间人并不知道私有S’，不能对该密文解密。看来这次是成功了吧？我们再来看server接受到密文后，用私钥S’解密等到数据，server不就要给client响应，此时server传输密文(响应 + 私有S’)，client接受到密文，用公钥S解密得到响应，与此同时中间人也用公用S解密得到响应。看来这个方案也是不行的，它只保证由client到server的安全，server到client的安全缺不能保证。

加密方案三：双方都是以非对称加密

由于方案二的问题是主要是中间人可以用server的公钥S对从server到client的密文解密，那如果client和server各自都生成一对配对的密钥那(公钥C，私钥C’，公钥S，私钥S’)。

• server生成公钥S和私钥S’，client生成公钥C和私钥C’
• client和server明文交换对应公钥(此时client有C,C’,S，server有S,S’,C，中间人有S,C)
• client给server发消息，密文 = 数据+ 公钥S，此时server可以用S’进行解密，中间人只能看着
• server给client发消息，密文 = 数据 + 公钥C，此时client可以用C’进行解密，中间人还是只能看着 现在我们保证了从client 到 server的数据安全，从server 到 client的数据安全。看着还可以。 但非对称加密有一个问题就是太慢了，如果你可以忍受浏览器以毫秒为单位给你响应，那就当我没说。

加密方案四：非对称加密 + 对称加密

由于方案三的一个问题就是效率问题，那我们就用对称加密的方式来解决效率问题。

• server先生成一对配对的公钥S，私钥S’
• client向server请求公钥S，获取公钥S(此时client有公钥S，中间人有公钥S，server有公钥S，私钥S’)
• client再动态生成对称密钥C，通过公钥S + 密钥C = 密文，传输该密文给server，server通过私钥S’对密文解密获得密钥C(此时client有公钥S，对称密钥C，中间人有公钥S，server有公钥S，私钥S’，对称密钥C)
• 现在client和server就可以通过对称密钥C来进行数据传输。而中间人就只能在一旁看着

这一方案看着非常可以，但其实以上四种方案都有一个共同的问题，就是client如何判断密文和数据的正确性，也就是说像这次的方案，如果中间人(已经生成一对配对的公钥M，私钥M’)在client申请公钥S时，中间人将公钥S替换为公钥M，发给client，client如何鉴别这个公钥的安全性，如果client使用公钥M，那么中间人就会得到对称密钥C，从而使client与server的通信不安全。

这也就是Man-in-the-MiddleAttack，简称“MITM攻击”(一种网络入侵手段，攻击者作为中间人，劫持通信双方会话并操纵通信过程，而通信双方并不知情，从而达到窃取信息或冒充访问的目的。)。要解决这一问题，就需要client可以识别从server发送数据的正确性，而单一密文或者公钥并不能自我证明自己的正确性，需要引入其它数据。而这就是数字签名和CA证书的意义。

CA证书 和 数字签名

CA证书：全称Certificate Authority证书，是由认证机构服务者签发的一种数字证书，是数字签名的技术基础保障，也是网上实体身份的证明。它主要用来证明某一实体的身份及其公钥的合法性，同时证明该实体与公钥二者之间的匹配关系。在电子商务系统中，所有实体的证书都是由证书授权中心即CA中心颁发并签名的。
该证书有什么内容呢？

其中除了数字签名是密文的，其它信息都是明文传输的，那它是如何保证通信的安全性呢？

CA认证：即证书颁发机构（Certificate Authority，简称CA）认证，是一种由可信任的第三方机构负责发放和管理数字证书的过程。这种数字证书通常用于在公钥基础设施（PKI）中验证公钥的持有者身份。CA认证的目的是确保电子交易和通信的安全性、真实性和完整性

也就是服务端在使用HTTPS前，需要向CA机构申请一份数字证书，数字证书里面含有申请者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书中获取公钥。证书就如身份证，证明服务端公钥的权威性。

我们可以在浏览器上，查看到授信任的证书发布机构。

数字签名（又称公钥数字签名）是只有信息的发送者才能产生的、别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。它是一种类似写在纸上的普通的物理签名，但在实现上使用了公钥加密领域的技术，用于鉴别数字信息。

数字签名的工作原理是：数据发送方使用自己的私钥对数据及与数据有关的变量进行运算，将合法的数字签名与数据原文一起传送给接收方。数据到达接收方后，接收方利用发送方的公钥对收到的数字签名进行运算，将得到的结果与发送方发送过来的签名做比较。如果相同，则说明收到的数据是完整的，在传输过程中没有被修改；反之说明数据被修改过，以此对数据完整性做检验，以确认签名的真实性和合法性。

签名的过程

验证的过程：

这里我们先对数据形成数据指纹在加密，是为了提高效率

现在我们将上面的数据给为CA证书，那以后server向client发送数据时一并发送CA证书，是不是就可以保证通信过程中数据的安全性了。
这里可能还会有几个疑惑？

• 证书里面的明文，中间人不可以篡改吗？很明显这是不可以的，如果篡改了证书里的明文数据，那由该明文数据形成的数据指纹一定与原本的数据指纹不同，就可以判断出该数据被篡改过
• 证书里面的签名，中间人不可以篡改吗？答案也是不行，因为该签名是由数据指纹 + CA秘钥形成的，这个世界上，只有CA机构可以形成(用不匹配的公钥来解密私钥加密的数据，会产生乱码或无法识别的数据)，并且只改签名没有意义(明文数据没有改变)。
• 证书里面的明文数据和签名，中间人都该可以吗？由于证书的签名只能由CA机构形成，那代表中间人想要将证书的明文数据和签名都改变，那只能用真的证书来替换该证书。但证书里面有申请人的信息，如果中间人真的用真证书来替换，就会暴露。并且证书里有域名的信息，浏览器会检查域名是否与申请域名一致。

现在看来我们只要server向client发送数据时一并发送CA证书，就可以保证通信过程中数据的安全性了。

如何形成csr？

我们可以使用CSR在线生成工具来看看。
CSR在线生成工具

完整流畅：非对称加密 + 对称加密 + 证书认证

只是在方案4的基础上添加证书，来保证client可以验证数据的安全性

• 第⼀组(⾮对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR⽂件与申请证书时获 得),客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客 ⼾端请求是，返回携带签名的证书.客⼾端通过这个公钥进⾏证书验证,保证证书的合法性，进⼀步保 证证书中携带的服务端公钥权威性。
• 第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.客⼾端⽤收到的CA证书中的公钥(是可被信任的) 给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥
• 第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

总结

以上就是我对于HTTPS的知识总结