共计 1727 个字符,预计需要花费 5 分钟才能阅读完成。
导读 | HTTP 协议,本身是明文传输的,没有经过任何安全处理。那么这个时候就很容易在传输过程中被中间者窃听、篡改、冒充等风险。这里提到的中间者主要指一些网络节点,是用户数据在浏览器和服务器中间传输必须要经过的节点,比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。 |
HTTP 协议,中间者可以窃听隐私,使用户的敏感数据暴露无遗;篡改网页,例如往页面插的广告内容,甚至进行流量劫持,比如有的时候你会发现域名没输错,结果却跑到了一个钓鱼网站上,因为被它劫持了。
为了解决这三大风险,HTTPS 的价值就体现出来了。
- · 内容加密,第三方无法窃听。
- · 身份认证,一旦被篡改,通信双方会立刻发现。
- · 数据完整性。防止内容冒充或者篡改。
HTTPS,简单的理解 HTTP 的安全版,即 HTTP 下加入 SSL 层,由两部分组成:HTTP + SSL / TLS。
第一步,用户在浏览器里输入一个 https 网址,此时客户端发起 HTTPS 请求,通过 TCP 和服务器建立连接(443 端口)。
第二步,服务器存放 CA 证书进行处理,注意的是采用 HTTPS 协议的服务器必须要有一套数字证书,这套证书其实就是一对公钥和私钥。
第三步,服务器向客户端返回证书。证书里面包含了很多信息:比如域名,申请证书的公司,公钥等。以下是一个淘宝网的 CA 证书。
第四步,客户端对证书进行解析。这部分工作是有客户端的 TLS 来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随机数,然后用证书对该随机数进行加密。
第五步,向服务器发送证书加密后的随机数。
第六步,服务器用它的私钥进行解密,得到了客户端传过来的随机数。
第七步,服务器用客户端的随机数加密后的信息发送给客户端。
第八步,客户端用之前生成的私钥解密服务端传过来的信息。
以上就是整个 HTTPS 的交互过程,大家是不是对整个流程有了比较大致的了解了呢。
真实业务场景是复杂的,这里,整理 3 个项目中遇到的比较复杂的应用场景。
- 场景一,对 HTTPS 进行 CDN 加速,这种情况下,CA 证书需要存放在哪里呢?
- 服务器(源站)提供证书给 CDN 厂商,包括公钥证书和私钥,CDN 负责交互和内容缓存,CDN 有缓存则直接响应,以 HTTP 或 HTTPS 的形式回源。这个方案,适用仅对防劫持、防篡改有需求,而愿意提供证书给 CDN 的源站加速。
- 服务器(源站)不提供证书,CDN 存放公钥,服务器(源站)存放私钥。在 CDN 与前端浏览器进行 TLS 的认证和秘钥协商过程中,通过安全的信道把协商过程中的信息以 HTTP 或 HTTPS 的形式转发给源网站。此方案中,CDN 不做缓存,仅以自有的加速网络,将用户的请求快速送到服务器(源站),降低公网延迟。这个方案,适用于对安全要求更高,不愿将私钥共享给 CDN 的源站加速。
- 场景二,对 HTTPS 的域名通过 CNAME 绑定到另外一个 HTTPS 域名上
这个情况下,我们需要一个证书还是两个证书呢?
我们的方案是,两个证书。因为每个证书跟自己的域名进行绑定,即使它们都在同一个服务器上,也不能使用同一个证书。
- 场景三,两台服务器的证书问题
因为安全问题,CA 证书在一台服务器上,而服务部署在另外一台服务器上。这种情况就比较难办。
此时,需要借助 Nginx 进行反向代理,回源到具体的服务器。
对于 HTTPS 设计上的方案,对于我们而言,有什么可以借鉴的地方么,答案是肯定的:有。一个非常典型的方案就是 RSA 双向认证。
RSA 双向认证,顾名思义,就是用对方的公钥加密是为了保密,这个只有对方用私钥能解密。用自己的私钥加密是为了防抵赖,能用我的公钥解开,说明这是我发来的。例如,支付宝的支付接口就是非常典型的 RSA 双向认证的安全方案。此外,我们之前的教育资源、敏感验证码出于安全性考虑都借鉴了这个方案。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)