Https

HTTPS 项目的由来和结果

S

决定进行 HTTPS 改造的最大痛点与直接原因是运营商劫持严重，不仅插入小广告，更有破坏性劫持。 在通过 CSP 采集数据后，前端同学看到微店用户在全国的劫持概率大约有10%左右，技术上的共识是 https 是一劳永逸的解决方案。 在忍耐了3个月后（考虑改造成本高，痛点还不突显），因为一次破坏性劫持导致杭州移动用户页面直接白屏事件而下定决心。 除应对运营商劫持之外，HTTPS 即是对于安全的一大保障，另一方面也是技术趋势。 Apple store 开始限定下一年发布或更新的APP必须采用 HTTPS 才能审核通过， 浏览器的部分API依赖于 HTTPS 环境才能被允许调用，比如 geolocation， 最新的 HTTP2 技术也是强制依赖于 HTTPS 的部署等等。 如果不考虑安全问题，实际上只需要部分应用支持 HTTPS 即可，但一旦考虑安全因素， 必须实现全站 HTTPS 才能做到完整的防范，否则一个口子就能撕裂出一片安全问题。

T

早期主要是运维和前端同学在跟进运营商劫持问题，在决定进行HTTPS改造后， 实际上就需要前端、后端、APP、测试、运维多方一起协作达成效果。 由于前端接触这个项目最早，我在阿里既有HTTPS改造的实践，也有项目管理的实践， 我自荐承担整个项目的项目管理工作(ps: 当时前端技术部还没有 leader)。 在跟进项目的过程中，也高度参与了技术方案的制定与讨论，HTTPS对杭州研发体系升级也有很大影响。 从任务角度来说，除了HTTPS改造这个基础任务之外， 也包括新应用如何快速接入HTTPS体系，如何对研发流程和技术架构进行升级来更智能地管理， 以及如何将老应用下线处理确保线上全部 HTTPS 流量等问题。

A

项目分为三个阶段，整个项目时间跨度很长，涉及的部门、人员、应用也非常多。

为了能使整个项目能快速可控地推进，我们首先挑选了一个重点应用进行全链路和全端的HTTPS改造， 这其中包括导购与浏览、购物车与下单的整个用户链路，以及从h5端到app端三端都进行改造。 这个改造大致耗费了1个多月，作用是明显的。

一方面，这个子项目囊括了一个完整的HTTPS改造所需的所有技术角色，让各技术角色 实战了HTTPS改造的具体实施方案和注意点，当时的这批人差不多也是各部门的主力人员， 在全面改造阶段的第二阶段，实际上就成为了各部门接口人，对降低推进阻力也起到了很大的效果。

另一方面，借此子项目，技术部沉淀了一整套HTTPS快速改造方案， 完成了对研发流程和技术架构上的绝大部分改造和准备工作， 使得后续项目可以无阻塞地进行快速改造，解决了研发和发布等问题。

在运维端，约定了整个技术部的应用域名规范，规范化了服务器的组织方式，只需在特定集群上配置泛域名证书， 就能支持到后续所有应用的HTTPS改造，同时在各套测试环境、CDN服务器上都进行了HTTPS部署。 另外，由SCM对前端、后端的发布流程也进行了升级改造，让发布流程也默认支持HTTPS。

在后端，中间件团队开发了统一API网关层，所有的后端服务对外输出都会接入该统一网关层， 将 HTTPS 改造项目需要操作都集中在统API网关层进行管理， 而具体的后端服务则是需要改造接入到统一网关层。

在APP端，开发了网络相关的SDK，将HTTPS改造相关内容统一在SDK中集中管理， 具体的APP必须引入该 SDK，并且使用该 SDK 来进行网络通讯管理。

在h5端，对于CDN资源和API的网络请求统一采用相对协议， 这样页面协议一升级内部资源的协议也能同步升级。 另外对于支持HTTPS的前端应用，会配置302强制HTTPS。

项目的第二阶段是全面改造，首先跟各部门leader确定了部门接口人，避免我直接与部门leader的不对等沟通。 通过对线上流量的分析，找出所有要改造的应用，明确应用的改造负责人，以及对应用的重要程度不同 确定不同的优先级与上线时间。 这个工作的难点在于一些老应用改造成本较高，大家意愿不强，或者部分应用负责人喜欢拖延时间，从而导致项目时间不可控。 项目质量问题一方面有统一的改造方案来提供保障，另一方面则是依赖对应测试同学负责， 最后我通过 kibana 做了一个多个维度的 dashboard，能够直观地反应目前的进度情况和项目质量。 项目时间上，主要依赖周报和周会的形式来实现信息同步， 对于重点应用、老应用或者拖延时间的情况，则是重点关注，尽早明确下时间点和子项目的项目成员。

项目的第三阶段则是老应用的下线清理，以及全网强制HTTPS，以实现当下和以后都能100%的HTTPS流量。 这块工作主要是我跟运维以及部分应用负责人配合，当时下线的后端应用超过10+个。

R

• 解决运营商劫持问题，用户的网络通讯安全更有保障
• 对外应用97%以上的HTTPS流量（3%是因为老版APP没有强制升级功能，因此还是使用HTTP)
• HTTPS 的统一接入方案和研发流程保障，新应用默认走 HTTPS，不需要再干预
• 技术部整体技术架构的升级和统一，老应用也都进行了改造或下线，清理了部分历史债务

HTTPS

• 证书和证书链
• mixed content