浅谈推进全站HTTPS项目-工程篇

[iscarecrow]

HTTPS 在 HTTP 的基础上增加了SSL/TLS加密，提供了更加安全的传输协议。俨然已经属于各大网站的标配。有赞作为一个SaaS平台，涉及到用户的商品，交易，支付等关键性流程。支持全站 HTTPS，提高网站安全是我们的基础保障。本文关注的事情包括： 了解 HTTPS 基础原理，切换 HTTPS 需要切换的内容，如何监控和实际操作，以及遇到的一些难点。

一、基本原理


在原有 HTTP 握手的基础上，增加了证书的验证，进行了加密，这样我们传输数据就有安全的保证。解决的问题包括像运营商劫持、中间人攻击、钓鱼网站、提升SEO等。具体流程如下：

1. 客户端发送“ClientHello”消息，消息包含 SSL 的版本、客户端支持的加密套件和数据压缩算法及随机数1。

2. 服务器响应“ServerHello”消息，消息包含选定的加密套件、选定的数据压缩方法、会话标识，数字证书及另一个随机数2。

3. 客户端（ Web 浏览器）验证服务器的SSL数字证书的有效性，不通过则提示警告。

4. 客户端发送“客户端密钥交换”消息。此消息包含 pre-master secret（用于生成对称加密密钥生的随机数3）。

5. 客户端使用一系列加密运算将 [随机数1 随机数2 随机数3] 转化为 master secret，其中将派生出所有用于加密和消息认证的密钥。

6. 服务器使用一系列加密运算将 [随机数1 随机数2 随机数3] 转化为 master secret，其中将派生出所有用于加密和消息认证的密钥。

7. 客户端发出“更改密码规范”通知服务器端之后使用协商好的对称加密算法及密钥通信。

8. 服务器发出“更改密码规范”通知客户端之后使用协商好的对称加密算法及密钥通信。

9. SSL握手结束，使用对称加密算法进行加密通信。

二、 切换需要涉及的资源和服务

当你开始着手切换成 HTTPS 的工作时，首先你需要明确你要处理的内容有什么? 一般来说你需要梳理以下内容：

1. 部署到cdn的静态资源，js、css
2. 图片资源
3. 主域及其次级域名的数量
4. 是否有第三方资源，比如广告、视频等接入
5. api调用，是否动态返回Http业务
6. 提供的对外服务

关于第1点，静态资源基本会收敛于少数域名，服务也基本会由第三方cdn服务商提供。 对应的服务提供商处开启 HTTPS 支持。

动态引入静态资源

<link rel="stylesheet" href="${loadStaticContent(www/css/main.min.css)}">

<script type="text/javascript"  src="${loadStaticContent(www/js/main.min.js)}"></script>

在早期全站加载静态资源过程中， 应该自定义前端模板方法去动态加载js，css。 防止写死域名情况。后期在全站切cdn域名时，就可以直接使用新的 HTTPS 域名，一刀切，修改模板方法引入域名和路径。

关于第2点，图片来源一般分为两种，站内图片和站外图片。站内图片，基本会使用第三方cdn服务。可以统一开启 HTTPS。而站外图片一般的来源可能包括：开发写死，对接第三方服务（类似淘宝导购），链接型图片上传未存储到自己的服务。

css动态引入图片

.loading {
    background-image: image-cdn('/logo_loading.png');
}

假设使用了sass等工具，站内图片可以在css中引入cdn域名加载方法。统一替换。

老图片问题

对于老的Http数据图片数据，业务访问可知的情况下，需要跑脚本重新上传。对于上传图片组件若传入的是Http图片，应该考虑重新上传支持。

关于第3点，主域及其次级域名，可以通过统计nginx日志上 HTTP 的流量(awk日志)。获取现有站点HTTP 流量的pv访问表。得到需要 HTTPS 的域名的数量。确认切换 HTTPS 顺序和工期，考虑因素包括:请求量的大小、业务的轻重缓急、业务切换 HTTPS 难度、各域名功能等方面。在确定站点基本情况后，需要和各业务方交流以上方面问题。得出各域名切换的时间节点。

关于第4点，第三方资源引入问题。

• 视频应该使用引入支持 HTTPS 的视频资源，比如腾讯视频。
• 外站不支持 HTTPS 图片，应该考虑重传为站内图片。
• 广告对接，一般是引入第三方广告脚本，第三方脚本做什么事情， 都属于第三方脚本的工作， 所以需要脚本提供方提供 HTTPS 服务

原则上第三方资源应该是 HTTPS 的，如果不是，我们可能就需要存储到自己的服务上或者通过服务端转发。否则必然是 HTTPS 的环境下，引入Http的情况

关于第5点，属于业务范畴，前端走api方式的调用，返回值中针对头像、展示图片等图片方式，如果经过模板层可以考虑加模板方式统一替换成 HTTPS，直接拼装成的字符串。可以提供统一方法替换。

关于第6点 ，比如你有api等对外服务。早期开放了Http调用的口子，那么很遗憾。我们能做的事情是通过公告、邮件等方式告知第三方，我们在特定时间后就不在支持Http服务，希望第三方支持 HTTPS 调用。或者如果安全性不重要的话，那么就同时支持HTTP/HTTPS调用。苹果Https的公告 App Transport Security就是很好的例子，而实际上app内部还是留了开启HTTP请求的设置。

以上是需要我们处理的大部分内容。在推进全站 HTTPS 问题之前，做好这步梳理准备。包括了调研、确认切换范围、了解业务切换难易程度、确定工作的时间安排和参与人员。注：各部分工作设定好deadline，会对你有非常大的帮助。

三、切换Https中的注意点

站内HTTPS资源准备完毕后，就可以考虑将各站点切换成 HTTPS。操作层面需要注意以下几点：

相对协议

代码层面对明显写死的Http协议进行修改。修改成相对协议是不错的选择

<img src="//domain.com/img/logo.png">
<script src="//www/js/libs/jquery/1.4.2/jquery.js"></script>

相对协议下，当你访问Https网站时，请求Https资源。否则Http。这样方案上更具有灵活性，可以考虑内网先进行Https的测试，对外网使用Http。 假设Https方案出现问题时，可退回到Http。

301 与 302区别

当页面所有资源都切换成HTTPS，回归测试后。可考虑Http访问网站时，nginx302重定向到Https。强制切换。上线后可经过几天到1个星期的观察。（流量大和复杂业务需要更久）业务稳定， 无异常及用户反馈情况。可以强制301切换。

302和301的区别就在于：302重定向是临时的，下次浏览器访问同样是访问原链接。而301重定向是持久的。下次浏览器会直接访问新链接。所以当确定某域名下已经实现了HTTPS，可采用301重定向。

Content-Security-Policy

当某站点已经切换成了HTTPS。假设后期还是有开发人员引入Http的情况。我们应该采用哪种CSP策略防止呢？

block-all-mixed-content, 强制阻止页面内http加载

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

但是实际上，阻止HTTP加载不是我们的目的，后期开发中
引入Http的行为可能是疏漏造成的，我们可以理解成实际上资源已经可以支持HTTPS的。 所以可以采用另一种CSP策略： upgrade-insecure-requests

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

该策略下会产生以下两种效果

• 站点内的HTTP请求，都会HTTPS的方式发起。
• 所有连接跳转都会以HTTPS的方式打开。

这种策略显然更加友好。当网站已经确认强制使用了HTTPS，就可以加入该方法。

测试环境是否启用HTTPS

从测试便利性角度，测试环境可以提供HTTP。但实际上为了和正式环境一致应该用HTTPS测试更合理。因为上述推荐使用相对协议，所以测试环境本身是可以提供HTTP/HTTPS两种方案的。

四、遇到的难点

全站HTTPS由于域名和业务等因素影响，切换过程中必然会遇到许多难点。 主要表现在业务方来源和用户访问来源：

1. 基础接口调用方太多，同时存在前端直接调用或者后端业务层调用的情况，需要接口提供方定位接口真实调用位置。
2. 一些接口调用没有referer，referer对于前端定位流量来源能够提供非常大的帮助。但是有一些页面的HTTP访问不存在referer，这种情况可能由于用户保存该页面链接或者从其他来源进入网站页面丢失等造成。假设页面经过HTTPS测试通过，可以通过强制切换成Https解决。
3. 客户端接口老版本请求HTTP情况，根据用户的量，判断是否放弃老版本的调用。否则无法根除该流量的Http
4. 第三方请求公司提供的HTTP服务， 告知第三方规定时间内升级。

除了以上的几个显性难点外，其实还有些隐性难点，比如需要与业务方约定明确强制切换的deadline，接口升级、服务改造迁移、老接口复杂性等各种问题都会拖延各实施方的进度。只有强制的deadline切换才保住全站HTTPS的推进进度。

写在最后，本文主要是围绕推动公司全站HTTPS的一些心得。更多的是以一个项目推动方的角度考虑如何推动事情的落地。原理，内容，执行，难点。这几个核心流程把握住。我们才能做到更加有条理的实施。同时全站流量切换成HTTPS，其实只是工作的开始。之后的HTTPS性能优化、异常HTTP流量监控、HTTPS可用性监控等都是接下来应该去不断推进的工作。

• 掘金