HTTPS 背后的内幕

这是一篇内部分享文

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

HTTP

HTTP 的缺点

使用明文通信

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

不验证通信方身份

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

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

不验证报文完整性

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

HTTPS

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

什么是HTTPS

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

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

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

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

如何弥补HTTP缺点的

加密

加密方式

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

   使用双方共同拥有的单个密钥。这种密钥既用于加密，也用于解密，叫做机密密钥。

2. 公开秘钥加密（非对称加密）

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

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

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

HTTPS 的加密方式

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

认证

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

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

认证流程:

1. 把证书请求 (ssl.csr) 发给证书机构。

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

   也就是证书里面包含了服务器公钥 + CA 对公钥的数字签名。

3. 服务器把证书发送给客户端（浏览器）

4. 客户端使用CA机构的公钥验证证书上的数字签名。 如果验证通过，则表明：

   • CA 的认证服务器是有效的
   • CA 的公钥是有效的
   • 服务器的公钥是有效的

   合法的CA机构的公钥是内置在浏览器中的。

5. 客户端使用服务器的公钥对报文加密

6. 服务器使用私钥解密报文

既然我们有开源的 openssl， 为什么还要去购买ssl证书?

https 安全的前提

数字证书颁发机构（CA）被客户端和服务端绝对信任。

自签名证书

基于OpenSSL自建CA和颁发SSL证书

就是自己扮演 CA 机构，自己给自己的服务器颁发证书。

由于自签名证书无法排除被中间人伪造的可能， 所有浏览器对自签名证书不信任，浏览的时候回给出风险提示。

因此， 只有值得信赖的第三方机构介入， 才能让植入在浏览器中的认证机构公开秘钥发挥作用， 从而借此证明服务器的真实性。

漏洞

Mozilla 和 Google 宣布对 WoSign 和 StartCom ( StartSSL ) 一年内新签发的所有SSL证书不信任。

360 > WoSign > StartCom

本作品采用《CC 协议》，转载必须注明作者和本文链接