Linux——HTTPS协议

HTTPS也是一个应用层协议：只是是在 HTTP 协议的基础上引入了一个加密层而已~

概念准备

1什么是加密

2为什么要加密

3常见的加密方式

对称加密

非对称加密

数据摘要(数据指纹)

一HTTPS加密方式

方案1只使用对称加密

方案2只使用非对称加密

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

方案4对称加密+非对称加密

编辑

二中间人攻击

三CA认证证书

1理解数据签名

2证书

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

4方案五对称加密+非对称加密+证书

5总结

概念准备

1什么是加密

加密：明文 (要传输的信息）进行一系列变换, 生成密文
解密：密文进行一系列变换, 还原成明文
在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这
样的数据称为密钥

在86版的火烧圆明园中，亲臣递给慈禧太后的周折中

明文

秘钥：烧了的洞

密文：通过秘钥将文字进行组合成句子

2为什么要加密

例子：臭名昭著的 "运营商劫持"

未被劫持的效果

劫持的效果

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

至于为什么要这样做

3常见的加密方式

对称加密

采用单钥密码系统的加密方法：同一个密钥用作信息的加密和解密

常见对称加密算法(了解)： DES、 3DES、 AES、 TDEA、 Blowfish、 RC2 等

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

简单对称加密例子：按位异或

假设明文 a = 1234, 密钥 key = 8888
则加密 a ^ key 得到的密文 b 为 9834
然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234

非对称加密

需要两个密钥来进行加密和解密这两个密钥：公开密钥和私有密钥(两者可以反着用)

常见非对称加密算法(了解)： RSA， DSA， ECDSA
特点：安全性依赖于算法与密钥，算法复杂，加密与解密速度慢

举生活例子来帮助理解：

A 要给 B 一些重要的文件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:

B 说: 我桌子上有个盒子, 然后我给你一把锁，你把文件放盒子里用锁锁上, 然后我回头拿着钥匙来开锁取文件

在这个场景中, 这把锁就相当于公钥，钥匙就是私钥：公钥给谁都行(不怕泄露), 但是私钥只有 B 自己持有，持有私钥的人才能解密

数据摘要(数据指纹)

数字摘要(数据指纹),其基本原理是利用单向散列函数(Hash 函数)对信息进行运算,生成一串固定⻓度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。
摘要常见算法：有 MD5、 SHA1、 SHA256、 SHA512 等(有可能发生碰撞，但概率极低)
摘要特征：摘要严格意义不是加密(没有解密)，只不过从摘要很难反推原信息

常用来进行数据对比

如百度云盘的秒传功能：用户在上传电影时，会先被服务器进行Hash函数的运算形成摘要；在自己的数据库中找对应摘要映射的资源；如果找到了，用户上传的速度立马就好了（实际是找到的资源拷贝一份到该用户资源空间中，达到秒传）；如果没找到才进行资源上传的工作(通过网络将资源传输给服务器)

例外大部分储存用户密码的数据库也有应用：通过form表单提取到用户密码后进行Hash函数形成摘要进行保存：这样做的好处是：为了防止数据库泄露/不法人员得到用户数据进行牟取暴利

一HTTPS加密方式

方案1只使用对称加密

如果通信双方都各自持有同一个密钥 X，且没有别人知道

但是怎么把秘钥X告诉客户端？

如果明文传输的话：不就被中间人给获取了吗！

如果加密传输的话：就变成了先有鸡还是先有蛋的问题了

方案2只使用非对称加密

服务器生成公钥和私钥，在通信前把公钥交个服务器

保证单项通信安全（暂时）

但是：

非对称加密通信速度慢

往左通信的数据也能被中间人获取并解密(公钥大家都能获取)

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

双方都生成公钥和私钥，在进行通信前各自的公钥交给对方

看似安全，其实也是不安全的

用非对称加密通信速度慢

方案4对称加密+非对称加密

客户端生成对称秘钥X，服务器生成公钥S和私钥S`：在通信前把公钥S交给客户端，客户端把自己的公钥X与公钥S加密后发给服务器，服务器私钥S`解密（只有它能解密）得到秘钥X；往后通信就通过对称加密进行！！

看似是最佳方案：通信速度快，通信过程都进行了加密

但是：还是一样不安全(与前一种类似)

至于为什么会不安全，要看下面的中间人做了什么事~

二中间人攻击

server发送公钥S给client时，该信息会被中间人给劫持：换成自己的公钥X给client，client收到时是不知道被中间人篡改了：用中间人的公钥M进行加密发给server，发送过程又被中间人给劫持了：此时只有中间人能进行解密，得到对称秘钥X；在用之前劫持到的公钥S进行加密发给server，而服务器也不知道数据是被中间人篡改过的，以为是client发来的加密秘钥X，用私钥S`进行解密得到秘钥X：此刻client，server,mid都有了秘钥X，mid不就可以随便的来进行获取数据与篡改数据了吗！

那么为什么会让中间人得到秘钥呢？问题在哪？

在于首次server发送公钥时，client不知道公钥是不是‘合法’的！

三CA认证证书

1理解数据签名

签名的形成是基于非对称加密算法的，注意：目前暂时和 https 没有关系，不要和https 中的公钥私钥搞混了

这里签名者是谁？暂时理解成签名者(临时)：用自己生成公钥(Q)和私钥(Q`)来进行加密解密

假设这个签名者是我，要验证的人是张三：我用私钥钥(Q`)进行加密后与的带签名的数据和公钥(Q)交给张三，让张三去解密：在这个过程中如果出现了中间人(老六)把公钥换成它自己的公钥(L)，张三认不认？当然不认：这份带签名的数据只有我的公钥(Q)能解密

说明：解密过程必须内置使用我的公钥(Q)来进行签名验证，并进行后续验证

这个世界上只有我有私钥(Q`)：也就意味着：只有我有对数据进行签名的能力；当然这也是一种权利！谁持有大家都认的公钥(Q)对应的私钥(Q`)，谁都可能进行签名！！

2证书

client第一次请求：除了得到公钥(Q)，还会得到一份证书

那么这个证书从哪来的？谁给的？

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书：数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行

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

客户端(浏览器)一般都要内置可信的CA结构或者旗下授权的子公司的公钥来进行证书验证！

在线生成CSR和秘钥网站：CSR在线生成工具

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

以Chrome 浏览器为例：进去浏览器后，点击右上角

选择 "设置", 搜索 "证书管理" , 即可看到以下界面. (如果没有，在隐私设置->安全性安全里面找找)

4方案五对称加密+非对称加密+证书

现在我们可以来对方案四进行完善：添加证书

那么上方的方案中间人要想进行攻击有两个方向：局部替换和整体替换

中间人把证书里的公钥(Q)替换成自己的公钥(L)或者把整个证书替换成我自己生成的？

不行！如果替换了，浏览器进行解密会解密失败(散列值不相等)

既然上面行不通：那中间人自己去CA机构申请证书然后把证书进行替换？

第一中间人既然叫做中间人，自然时不希望自己的信息暴露(申请证书要个人基本信息)

第二在证书中有域名选项需要你填：收到证书域名不一致会立马停止解密

5总结

以上方案设计的的秘钥有三组（两非一对）

第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。

第⼆组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.

第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实一切的关键都是围绕client收到的对称加密的密钥是否‘合法’来进行处理的！！