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 缺点的#
加密#
加密方式#
-
共享秘钥加密(对称密钥加密)
使用双方共同拥有的单个密钥。这种密钥既用于加密,也用于解密,叫做机密密钥。
-
公开秘钥加密(非对称加密)
一个公钥和一个私钥,这两个密钥在数学上是相关的。在公钥加密中,公钥可在通信双方之间公开传递,或在公用储备库中发布,但相关的私钥是保密的。只有使用私钥才能解密用公钥加密的数据。使用私钥加密的数据只能用公钥解密。
在 HTTP 应用中单纯的使用上面的任一中加密方式都存在问题:
- 服务端如何安全的将秘钥发送给客户端?如果通信被窃听, 那么攻击者就在获得密文的同时获得秘钥,加密也就失去了意义。
- 如何让所有的客户端持有公钥? 客户端如何确认收到的公开秘钥不是从中间人发送过来的假秘钥而是货真价实的真秘钥?
HTTPS 的加密方式#
HTTPS 使用混合使用 2 中加密方式, 同时使用证书来证明公钥的正确性。
认证#
目的: 为保证双方传递信息的 真实性、可靠性、完整性。
CA: 证书认证中心 (Certificate Authority) 中心。是一个负责发放和管理数字证书的第三方权威机构。
认证流程:
-
把证书请求 (ssl.csr) 发给证书机构。
-
CA 确认申请人身份后使用 CA 机构的私钥对服务器公钥进行数字签名, 同时把已签名的公钥分配给机构, 并且把证书和公钥及签名进行绑定。
也就是证书里面包含了服务器公钥 + CA 对公钥的数字签名。
-
服务器把证书发送给客户端(浏览器)
-
客户端使用 CA 机构的公钥验证证书上的数字签名。 如果验证通过,则表明:
- CA 的认证服务器是有效的
- CA 的公钥是有效的
- 服务器的公钥是有效的
合法的 CA 机构的公钥是内置在浏览器中的。
-
客户端使用服务器的公钥对报文加密
-
服务器使用私钥解密报文
既然我们有开源的 openssl, 为什么还要去购买 ssl 证书?#
https 安全的前提#
数字证书颁发机构(CA)被客户端和服务端绝对信任。
自签名证书#
就是自己扮演 CA 机构,自己给自己的服务器颁发证书。
由于自签名证书无法排除被中间人伪造的可能, 所有浏览器对自签名证书不信任,浏览的时候回给出风险提示。
因此, 只有值得信赖的第三方机构介入, 才能让植入在浏览器中的认证机构公开秘钥发挥作用, 从而借此证明服务器的真实性。
漏洞#
Mozilla 和 Google 宣布对 WoSign 和 StartCom (StartSSL) 一年内新签发的所有 SSL 证书不信任。
360 > WoSign > StartCom
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: