22/03/HTTPS如何实现比HTTP多的S(一遍必懂)

前言:

• 这篇文章是因为看HTTPS的知识点, 踩了好多坑, 因为每个科普文都只是讲清晰了其中的某一点, 看完没有体系的概念. 在不断的梳理下, 最终逐步清晰起来.
• 我将从问题出发, 最终大家可以发现: 许多概念和知识点是为了解决问题, 而被创建发展, 最终形成体系.
• 下文客户端/用户/浏览器端 统一用A简称, 服务器端/web服务器/站点/网站统一用B简称
  

珠玉在前:

• 数字签名是什么
• SSH、SSL与HTTPS

涉及知识点：

1. SSL/TLS
2. 中间人攻击
3. 数字证书 数字签名
4. 对称加密 非对称加密
5. RSA秘钥对: 公钥 和 私钥

一. HTTPS和HTTP有什么区别?

当然不是多了一个字母S的区别 /狗头

S代表SSL(Secure Sockets Layer)或者TLS(传输层安全协议, Transport Layer Security), 一般都认为二者等价. 其目标是建立一种对上层应用协议透明的, 任何应用层协议都可以依赖的可安全通信的传输层协议. TLS是 SSL经过IETF标准化之后的产物, 其主要作用为:

1. 验证网站身份
2. 确保传输数据的安全性
3. 确保传输数据的完整性

题外话: 网络安全的四大要素:信息传输的保密性, 数据交换的完整性, 发送消息的不可否认性, 交易者身份的确定性.

那么每一小点是如何实现的?

二. SSL如何验证网站身份

1. 为什么要验证网站身份?

客户端A和服务器端(网站)B 双方素昧平生, 相隔千里. 为了解决信任问题, 首先得确认对方的身份, 这是通信交易的前提.

中间人攻击(Man-in-the-MiddleAttack): 就是存在另一个人或者一台机器冒充真正的服务器接收用户传给服务器的数据，然后再冒充用户把数据传给真正的服务器, SMB会话劫持、DNS欺骗等攻击都是典型的MITM攻击。

想象电信诈骗: 冒充警察获得你的支付密码等私密信息, 再冒充你本人 在银行官网输入正确的转账信息转移你的财产. 然而对于你自己和银行都不知道自己被骗了.

2. 你如何证明你是你?

单凭你自己, 是不可能证明你是你自己的, 对吗? 不然以前怎么会有顶替上大学的情况出现, 我们需要用第三方权威机构 学信网给我们生成的 学籍证明 证明我确实是XXX, 对方才能让我注册学籍.

所以, 为了验证网站是可信任的, 我们需要一个 权威机构CA (请记住这个缩写后文会反复用到)——数字证书认证机构. CA会给它验证了的网站颁发数字证书(digital certificate). 当客户端A与网站B建立LLS连接之前, B需要将数字证书发给A, A验证无误后, 再进行数据交换等后续步骤.

3.数字证书都有些什么?

其中很重要的就是 (记住下面这两个, 后文会涉及):

• B的公开秘钥
• 数字签名

4. 数字证书如何保证其真实性?

这里涉及到非加密对称的概念.

1976年两位数学家提出一个崭新的非对称加密的概念:

1.A生成一对两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。
2.B获取A生成的公钥，然后用它对信息加密。
3.A得到加密后的信息，用私钥解密。

受这个思路的启发，三位数学家Rivest、Shamir 和 Adleman 设计了一种具体实现上面描述的非对称加密的算法，以他们三个人的名字命名，就是目前在计算机领域应用非常广泛的非对称加密算法RSA加密算法。在SSH(眼熟的应该会想到github)和SSL传输协议里, RSA加密算法大放异彩.

数字证书通过CA的秘钥对, 保证其真实性

实现步骤:

1. 证书正文/内容, 如上图(1)所示, 包含证书的各类属性
2. 利用hash函数, 生成证书的摘要(digest)
3. 利用CA的私钥 对 摘要digest 加密, 生成数字签名(signature)
4. 如上图(2)所示, 将该数字签名放到证书内容的最后( 命名为signature很合理啊, 正文最后放签名嘛)
5. 浏览器存储着CA机构的公钥, 用该公钥对证书上的签名 解密 得到摘要 (客户端(浏览器)的"证书管理器"见下图)
6. 浏览器也就是客户端, 对证书正文利用hash函数生成摘要 验证是否与解密出来的摘要一致
7. 不一致则代表验证失败, 一致则代表验证成功, 同时由于秘钥一致, 证明证书正文没有被篡改. (不知道, 有没有人想起MD5, 就是那玩意儿)

需要说明的是: 各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥

有的同学可能会想, 为什么网站不自己制作证书? 这里就又回到问题的最初, 你没办法证明你是你.

还有个问题, 那我把各种各类的网站B的公钥放到浏览器A, 网站B自己制作证书, 证书使用B的私钥加密, 这样不行吗? 这样可以, 能验证B是B, 但是浏览器没法做到记录所有可信任的站点的公钥啊.

所以如果你做一个网站, 要实现HTTPS协议, 你就得交钱给CA, 让它给你颁发一个证书. CA权威机构只有几家, 所以浏览器只用记住几个CA的公钥就可以了.

题外话: 感觉CA内部应该要实现 CA私钥对CA公钥, 多对一的功能? 因为不同的站点证书应该要是不同的CA私钥加密吧. 比如我四大行, 如果我使用同一个CA私钥, 那我如果是银行A内部员工, 我偷偷伪造银行B的证书去骗客户, 那怎么可以呢?

三. SSL如何实现数据加密传输?

一定要有这个意识: 客户端A和服务器端(网站)B 双方素昧平生, 相隔千里. 那么如何实现数据安全传输, 大多数人都知道加密呀. 比如什么摩斯密码. 但是问题来了, 对方怎么知道你使用的是哪一套加密规则? 一定要记住, A和B不认识不认识. 难道A利用莫斯密码加密数据, 同时在请求报文里, 告知对方我是用莫斯密码加密的嘛? 请问这是不是(⊙_⊙) 傻? 第三方不法分子截获了请求, 看到这个内容恐怕也会对你的智商表示怀疑吧…

1. 如何将A的加密方式安全的告知B?

加密方式, 加密规则, 其实就是秘钥. A要如何安全的将秘钥给B. 这里,也用到了非对称加密的概念, 还记得上一步数字证书里有B的公钥吗?

所以, 本地/浏览器/客户端, 也就是A利用B的公钥对秘钥加密, 然后发送给B, B利用B的私钥对其解密, 得到秘钥. 此时双方都知晓了秘钥, 那么秘钥就可以拿来做数据加密了, 因为第三方不法分子不知道这套加密规则/秘钥.

2. 为什么说SSL连接同时用到对称和非对称加密?

这里又牵扯到一个概念, 什么叫做对称加密? 大概就是函数和反函数那个意思. 即正向加密, 反向解密. 莫斯密码就是对称加密, 我按照规则加密, 按照同一套规则解密.

对称加密和非对称加密各有优缺点:

1. 非对称加密肯定安全性更高, 但是更耗时
2. 对称加密就是更简单高效, 但是安全性较低

所以SSL做了一个trade-off, 同时用到了对称加密和非对称加密, 数据交换使用的对称加密, 将对称加密规则告知对方的时候, 使用到了非对称加密.

如果不嫌弃, 我将这个过程再梳理一下:

1. 利用证书里面 B的公钥 将A打算用来加密数据的对称加密算法F 进行加密给B.
2. B将得到的F’ 用B的私钥解密, 得到对称加密算法F
3. 双方知晓了对称加密算法F, 利用其进行数据加密传输

看起来可能有点绕, 多读两遍, 我也不敢相信我居然能写这么个玩意儿…

四. SSL如何确保传输数据的完整性?

应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。