电商网站HTTPS实践之路——概述篇

Posted 2022-12-02 皖南笑笑生

写在开篇前的话：全站HTTPS已经是互联网企业发展的大势所趋。继淘宝、京东等电商完成全站HTTPS化后，笔者负责领导了公司的全站HTTPS工作。在整个过程中，笔者深刻体会到对于一个大型网站而言，全站HTTPS绝对是一个挑战巨大且需要严谨对待的工作。不幸的是，网络知识库中并未有针对电商型网站的任何改造经验与文档供我们参考。爬坑的过程是异常残忍的，遇到了一次次血淋淋的教训，因此笔者决定将整个方案分享出来。一方面，作为自己工作过程中的一笔财富；另一方面，如果能对大家有参考价值，少爬点坑也是好事情。
最后说一句，笔者能力有限，如果能对大家有帮助，转载请注明出处，毕竟是一年的心血。如果觉得存在问题，欢迎留言指教！

• 1. 为什么要做全站HTTPS？
  • 1.1 保证用户购物环境的安全
  • 1.2 部分加密仍存在安全漏洞
  • 1.3 全站HTTPS是互联网行业大势所驱
• 2. 针对大型电商网站的特性，增加了全站HTTPS的复杂性
• 3. 全站HTTPS方案概述

1. 为什么要做全站HTTPS？

HTTPS，即是安全的超文本传输协议。依赖TLS握手来保护HTTP传输数据和信息的安全性。
TLS（transport layer security, 传输层安全协议）和SSL（secure socket layer, 安全套接字层）应用于OSI表示层（TCP之上，HTTP之下）。都是旨在基于不安全的基础设施提供安全通信。SSL 1-3由Netscape公司开发，TLS 1.0-1.2由Microsoft维护，为了取悦Microsoft协议才发生了更名（SSL->TLS）。后面我们统一使用TLS协议。
TLS握手协议保证了数据在网络传输过程中：1. 数据加密；2. 身份校验；3. 数据的完整性校验。

1.1 保证用户购物环境的安全

我想这是电商网站实现全站HTTPS的根本原因——保证用户的购物环境更安全。毕竟用户的购物体验增强了才能提升电商网站的流量和人气。然而“感谢”运营商为我们营造了一个糟糕的公网环境，明文传输的流量被篡改、劫持、监听、窃取比率很高，这里面最让人无法接受到有两种：
1. 劫持广告：在页面加载中浮出第三方广告，甚至涉黄涉黑，严重影响了网站的形象和信誉。
2. 篡改使页面加载失败：明文传输被篡改后很可能导致整个页面无法加载或者接口返回错误内容使用户购买失败。

以上，对于普通用户而言，他们更容易将责任归结于电商网站做的差，所以全站HTTPS势在必行。

1.2 部分加密仍存在安全漏洞

一定要实现全站HTTPS化吗？很多电商网站根据会对登陆、支付等模块使用HTTPS，以保证用户信息的安全，然而，这样仍存在着安全漏洞。
比如会话劫持攻击（session sidejacking），即使你对登陆、支付等模块做好了加密，然而只要你的网站中存在同域的明文资源，攻击者会从未加密的连接上获取会话令牌JSESSIONID（因为会话令牌通过Cookie传送，存在于每个发向网站的请求中），一旦获取令牌，攻击者就可以在其有效时间内冒充用户身份进行访问和操作。

1.3 全站HTTPS是互联网行业大势所驱

谷歌启动了Deprecating Powerful Features on Insecure Origins计划，今后部分涉及用户隐私数据的API 必须在安全环境（Secure Contexts）中才能使用。
苹果公司将强制所有AppStore中的应用实行App Transport Security(ATS)标准，否则将拒绝应用上架。
Mozilla 公司在一年前也明确表态会逐步淘汰不安全的 HTTP，详见：Deprecating Non-Secure HTTP。
就像HTTP 1.1逐渐取代HTTP 1.0，HTTPS最终取代HTTP已经提上议程，所以我们还在等什么呢？

2. 针对大型电商网站的特性，增加了全站HTTPS的复杂性

目前，网络上针对HTTPS部署和优化有很多不错的资料，比如，Jerry Qu的博客：
《关于启用 HTTPS 的一些经验分享（一）》
《关于启用 HTTPS 的一些经验分享（二）》
《关于启用 HTTPS 的一些经验分享（三）》
百度运维官博的大型网站的 HTTPS 实践：
《大型网站的 HTTPS 实践（一）—— HTTPS 协议和原理》
《大型网站的 HTTPS 实践（二）——HTTPS 对性能的影响》
《大型网站的 HTTPS 实践（三）——基于协议和配置的优化》
感谢这些前辈的宝贵经验和知识财富。然而电商类网站有其特殊性，增加了全站HTTPS的复杂性。我们来举个例子，

Referrer丢失： 目前大部分浏览器，在发生协议降级时默认不发送 Referrer 信息，最典型的场景就是从 HTTPS 页面点链接跳到HTTP 网站时，浏览器并不会在请求头中带上 Referer 字段。

对于电商网站这会带来一些麻烦。你很容易遗漏一些a标签的维护，仍然是http://。那问题就来了，Referrer丢失会导致大数据埋点采集不到跳转来源，间接影响页面一跳率和商品详情页到达率等站内BI数据。
如何解决这个问题呢？
Jerry Qu提到使用Referrer Policy策略，告诉浏览器在协议升级时要带上Referer，如下所示。然而Referrer Policy只被部分现代浏览器支持（具体查询CanIUse），比如IE系是完全不支持的，换言之对于IE用户Referer仍然带不过来。

<meta name="referrer" content="always" />

百度的做法是根据UA判断用户是否使用IE浏览器，然后在IE浏览器中使用http://的跳板页面，这样就不会影响到页面数据采集。比如，用户在百度上搜索苏宁，其过程应该是这样：https://www.baidu.com -> 输入“苏宁易购” -> http://bzclk.baidu.com/adrc.php?t=…(跳板页) -> http://www.suning.com/?utm_source=baidu&utm_medium=brand&utm_campaign=title （苏宁易购）。
然而这种做法并不适合电商型网站，你不可能起改造整个页面结构，所有链接跳转都从跳板页到着陆页，且这样也牺牲了部分安全性（考虑ssl剥离）。我们的做法是在内容管理平台对所有维护的链接做统一替换为相对协议（//）来解决这个问题。

3. 全站HTTPS方案概述

因此，如何来做大型电商网站的全站HTTPS化，我们将整个实施过程划分为3个方面，如下图所示。在未来的章节中我们将会逐个展开详述。

全站HTTPS化方案包括了3个方面：
1. 系统改造篇：首先是要让系统支持HTTPS。
需要有接入层来统一处理TLS握手。页面资源的替换也存在一些坑。大多数互联网公司的CDN资源都是租用的，CDN上证书如何来处理。最后，HTTPS的测试策略如何实施，来保证页面不会出现Mix content阻塞和net: ERR_INSECURE_RESPONSE错误。
2. 性能优化篇：其次是HTTPS性能的优化。
这块技术较为成熟，nginx、Apache等Web服务器支持程度也不错。包括服务端优化和客户端优化两方面。服务端需要选择严格传输协议HSTS的合理使用、会话复用的合理使用、Ocsp stapling的合理使用、 TLS协议的合理配置、False Start的合理使用、SNI功能的合理使用、HTTP 2.0的合理使用、SSL硬件加密卡的合理使用。客户端的相关性能优化主要是使用移动端HTTP2加速代理、利用HttpsDns解决DNS劫持问题。
3. 灰度上线篇：最后，万事俱备，灰度上线
有人说为什么不直接一次性全站HTTPS。这样做明显是风险极大的，还是以前面Referer的例子来看，如果我们不是选择城市来灰度发现了这个问题，所损失的是几天的业务数据，这对大型网站来说是不可接受的。因此，要做灰度上线，通过开关控制、制定详细上线计划，每走一步同步对比性能数据和业务数据。最终全站HTTPS化实现完成。