电商网站HTTPS实践之路（二）——系统改造篇

首先是要让系统支持HTTPS。 需要有接入层来统一处理TLS握手。页面资源的替换也存在一些坑。对于不同的域证书选择上也要注意，最好的方式是提前整理好域列表绑定成一张支持多域名和泛域名的证书。大多数互联网公司的CDN资源都是租用的，CDN上证书如何来处理。最后，HTTPS的测试策略如何实施，来保证页面不会出现Mix content阻塞和net: ERR_INSECURE_RESPONSE错误。

1. HTTPS接入层的设计

开通服务端的443端口，用户发起HTTPS请求服务端才能正常响应。然而，一般的电商网站可不仅仅只是一台Tomcat，都会考虑性能和各种架构优化。基本上会是：客户端 -> CDN（静态缓存+动态加速） -> 四层负载均衡（F5/Ctrix／LVS） -> 七层负载均衡（Niginx）-> Web服务器（Apache） -> 应用服务器（Tomcat）-> 数据层。难道每一层都需要开启443端口进行TLS握手嘛？我们知道TLS握手过程会徒增至少两次RTT时间，这样的性能损耗我们是不能接受的。
因此，需要尽早完成TLS握手，对于后端仍使用HTTP通信。包括Facebook、淘宝等都提到过统一接入层的架构来“卸载”TLS协议。如下图所示，我们的接入层设计在CDN之后，应用服务器之前，是内外网之间的屏障。对于静态资源，命中CDN缓存后直接得到响应；对于动态回源请求，在HTTPS接入层完成握手过程，upstream到系统走80端口。

通过HTTPS接入层的建设，
1. 性能得到提升。一方面，传输的RTT减少了，另一方面，应用系统本身不存在握手来消耗cpu；
2. 实现了流量的统一调度。未来优化、升级、管控流量都集中在HTTPS接入层上。

2. 页面资源的替换

2.1 令人讨厌的Mix Content

混淆内容（Mix Content），简单来说是指HTTPS页面中混淆了HTTP请求。
通常当用户代理通过一个安全信道（如HTTPS）从一个特定站点加载一个资源（如Web页面）时，用户代理可以获得关于该资源的用户安全和隐私状态的三种判断：认证性（authenticated）、加密性（encrypted）及数据完整性（data integrity）。这些判断对于防止资源内容被篡改或窃听，抵御中间人攻击非常重要。但如果这些经过认证和加密的资源再通过一个非安全的信道（如HTTP）请求其他的子资源（如脚本、图片等），该资源的安全性就不再能够得到保证，从而处在一个混合状态，而事实上这一情况非常普遍。
因此，W3C颁布了针对Mix Content的安全标准，描述了用户代理、浏览器在处理加密和认证的文档时，如何禁止（disallow）对经过非加密方式或非授权连接所加载的子资源进行渲染或执行。
浏览器遵循Mix Content标准，并在控制台打印出报错信息：

Mixed Content: The page at 'https://product.suning.com/0000000000/129564647.html?srcpoint=index3_homepage1_32618213038_prod01' was loaded over HTTPS, 
but requested an insecure image 'http://image.suning.cn/uimg/PCMS/prmtExposition/149310522123830711.png'. 
This content should also be served over HTTPS.

Mix Content又可以分为两类：
Blockable：浏览器严格禁止加载这类资源。比如JavaScript、CSS
Optionally-blockable：可商榷的混淆内容，现代浏览器默认会加载这类资源，同时会在控制台打印警告信息。比如<img>、<video>、<audio> 和 <source>标签加载的内容。
值得注意的是，IE 8及以下并不属于现代浏览器范畴，不区分Blockable和Optionally-blockable&