浅谈推动有赞全站 HTTPS 项目-工程篇

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

1、基本原理

在原有 HTTPS 握手的基础上，增长了证书的验证，进行了加密，这样咱们传输数据就有安全的保证。解决的问题包括运营商劫持、中间人攻击、钓鱼网站、提高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 握手结束，使用对称加密算法进行加密通讯。

2、 切换涉及的资源和服务

当你开始着手切换成 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，会对你有很是大的帮助。

3、切换 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 访问网站时， nginx 302重定向到 HTTPS。强制切换。上线后可通过几天到一周的观察。（流量大和复杂业务须要更久）业务稳定， 无异常及用户反馈状况。能够强制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 两种方案的。

4、遇到的难点

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

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

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

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