HTTPS 背后的内幕

这是一篇内部分享文

file

背景： 2016 年底 iOS App 强制要求使用 HTTPS 协议。Chrome 计划在 2017 年将所有使用非 HTTPS 协议的网站标记为不安全，并在地址栏的前面显示一个红叉。Mozilla 宣布所有的新特性将只提供给 HTTPS 网站，HTTP 网站将逐步被禁止访问浏览器功能。

HTTP#

HTTP 的缺点#

使用明文通信#

http 没有加密功能，无法对请求和响应的内容加密。内容在经过网络中间节点是容易被窃听。
file

不验证通信方身份#

HTTP 在请求和响应时，不确认通信双方的身份。也就是说，客户端无法确认返回的消息就是从真正的服务器上返回的，有可能是从伪装的服务器上返回的。

同时，服务端也不知道接收响应的客户端是否就是正真的目标客户端。
这就是中间人攻击。

file

不验证报文完整性#

客户端端和服务端都无法确认收到的消息是否就是对方发送的原始消息，有可能中间被修改。
file

HTTPS#

在不安全的网络上创建一安全信道。

什么是 HTTPS#

TLS 是传输层安全协议（Transport Layer Security）的缩写，是一种对基于网络的传输的加密协议，可以在受信任的第三方公证基础上做双方的身份认证。

SSL 是 TLS 的前身，现在已不再更新 > TSL/SSL 原理

HTTPS 是在基于 TLS/SSL 的安全套接字上的的应用层协议，除了传输层进行了加密外，其它与常规 HTTP 协议基本保持一致

简单来说就是 HTTPS = HTTP + TLS/SSL

file

如何弥补 HTTP 缺点的#

加密#

加密方式#

共享秘钥加密（对称密钥加密）

使用双方共同拥有的单个密钥。这种密钥既用于加密，也用于解密，叫做机密密钥。
公开秘钥加密（非对称加密）

一个公钥和一个私钥，这两个密钥在数学上是相关的。在公钥加密中，公钥可在通信双方之间公开传递，或在公用储备库中发布，但相关的私钥是保密的。只有使用私钥才能解密用公钥加密的数据。使用私钥加密的数据只能用公钥解密。

在 HTTP 应用中单纯的使用上面的任一中加密方式都存在问题：

服务端如何安全的将秘钥发送给客户端？如果通信被窃听，那么攻击者就在获得密文的同时获得秘钥，加密也就失去了意义。
如何让所有的客户端持有公钥？客户端如何确认收到的公开秘钥不是从中间人发送过来的假秘钥而是货真价实的真秘钥？

HTTPS 的加密方式#

HTTPS 使用混合使用 2 中加密方式，同时使用证书来证明公钥的正确性。

认证#

目的：为保证双方传递信息的真实性、可靠性、完整性。

CA: 证书认证中心 (Certificate Authority) 中心。是一个负责发放和管理数字证书的第三方权威机构。

认证流程:

把证书请求 (ssl.csr) 发给证书机构。
CA 确认申请人身份后使用 CA 机构的私钥对服务器公钥进行数字签名，同时把已签名的公钥分配给机构，并且把证书和公钥及签名进行绑定。

也就是证书里面包含了服务器公钥 + CA 对公钥的数字签名。
服务器把证书发送给客户端（浏览器）
客户端使用 CA 机构的公钥验证证书上的数字签名。如果验证通过，则表明：
- CA 的认证服务器是有效的
- CA 的公钥是有效的
- 服务器的公钥是有效的
合法的 CA 机构的公钥是内置在浏览器中的。
客户端使用服务器的公钥对报文加密
服务器使用私钥解密报文