新浪邮箱全站HTTPS实施之路

2018年第一季度，新浪邮箱所有产品线（免费邮箱、VIP邮箱、企业邮箱）一律支持了 HTTPS 协议，从而进一步加强网络通信的安全性，保障邮箱使用户的隐私性。本文针对新浪企业邮箱产品线，以纯技术的视角全面详情HTTPS协议的部署之路，并向邮箱使用户详情HTTPS协议的概念、优势。

HTTPS 协议究竟处理了什么问题？

当企业邮箱使用户在浏览器中输入 http://mail.sina.net，以 HTTP 协议访问新浪企业邮箱官网并登陆邮箱的时候，潜在存在安全风险，而且该风险是新浪企业邮箱无法处理和避免的，根本起因是网络协议在安全性方面天然存在弱点。

风险可大可小，有些是使用户本地上网环境的问题，有些是使用户能避免的，有些是企业邮箱服务提供者也无可奈何的，网络攻击一般分为主动攻击和被动攻击，分别列举一个例子，让邮箱使用户对网络攻击有肯定的理解。

很多使用户在外面的时候，大概率会用免费的 Wifi 访问企业邮箱，而非法的 Wifi 能够干很多坏事，由于使用户所有的流量都会经过 Wifi 路由器，就像水管阀门一样，Wifi 路由器能够阻拦所有的 HTTP 协议数据，而可怕的是，HTTP 协议是明文传输的，也就是攻击者肉眼就能获取你的密码，有了密码，就能以你的身份看查看重要邮件，或者者以你的身份发送垃圾邮件。我们经常发现一个看起来很正常的邮箱使用户忽然发送垃圾邮件，大概率就是密码被盗了，被盗的起因很可能就是数据流量被截获了。

此类攻击叫做被动攻击，攻击方式五花八门，而可怕之处在于使用户根本意识不到被动攻击的存在，攻击者可以在背后进行很多破坏，而使用户一无所知。

接下去详情主动攻击，所谓主动攻击就是使用户意识到自己被攻击了，从而可以通过各种手段避免攻击。很多邮箱使用户经常向我们投诉邮箱页面有莫名其妙的广告，比方下图，这种情况一般是 ISP 劫持了 js 脚本。

广告劫持

比方一个江苏的邮箱使用户，为了访问互联网必需根据本地 ISP 的要求配置网络参数，也就是 ISP 拥有绝对的网络控制权，他们为了谋利，会在邮箱的 js 脚本上插入一段代码，这段代码执行的动作就是弹出广告，这已经算很轻微的攻击了，由于使用户至少还能正常用邮箱服务，严重的情况是 ISP 篡改 js 脚本，导致不能正常用邮箱服务。

假如遇到相似的主动攻击，我们也无能为力，只能告知使用户去向本地的 ISP 投诉，这也进一步印证了网络传输（对于我们的服务来说，就是 HTTP 传输）的不可控性。

总结说来，HTTP 协议（所有用该协议的网站）天然存在少量弱点，主要有三点：

• 你访问新浪企业邮箱官网，以为是和新浪企业邮箱服务器在通信，实际上你可能和一个黑客在通信。
• 你所有的数据都是明文的，黑客很容易知道数据代表的含义，也就是数据是非加密的。
• 你的数据可能被篡改，比方邮箱返回一堆邮件，其中一封邮件的内容已经被黑客篡改（诈骗邮件），而你根本无法校验。

因为 HTTP 协议在安全方面的脆弱性，作为访问 HTTP 网站的各大浏览器为了保障使用户的安全性，做了很多工作，对于大部分高版本的浏览器来说，假如你访问一个 HTTP 协议的网站，那么会以很显著的警示提示你。

下面两张图分别展现了 chrome 和 firefox 的警告标示：

chrome对http网站的警示firefox对http网站的警示

HTTPS 协议能够完美处理 HTTP 协议的三大问题，那么怎样知道我们企业邮箱部署了 HTTPS 协议呢？或者者说邮箱使用户怎样认知 HTTPS？当使用户用浏览器访问 https://mail.sina.net 的时候，会在地址栏上出现一个绿色小锁图标。

Chrome 示例图：

chrome小锁

Firefox 示例图：

firefox小锁

一旦出现绿色小锁图标，使用户就能现成三个概念：

• 嗯，我确定是在和真正的新浪企业邮箱服务器在通信。
• 嗯，我和企业邮箱服务器之间的通信数据都使用密钥加密了，而且密钥只有我们两者才知道。
• 嗯，假如我和企业邮箱服务器之间的通信数据被篡改了，我会立刻知道。

这就是 HTTPS 协议的好处，企业邮箱可以赶快访问下官网，看看是不是有绿色小锁图标。

为什么现在才支持 HTTPS 协议

作为老牌的邮箱服务提供商，我们深知安全的重要性，也努力通过各种技术手段确保使用户的安全，邮箱服务的特性决定必需将安全放在第一位。

早在三年前我们就已经在筹备 HTTPS 协议的支持了，那为什么现在才上线？使用户可能有这样一个疑问，主要有以下几个起因：

（1）HTTPS 协议尽管很早就被提了出来，但因为性能和兼容性的起因，直到最近几年才被广泛用，邮箱同样如此，相对来说，其实是一个新生事物。

builtwith.com 对全球顶尖网站的 HTTPS 协议部署量进行了统计，结果如下：

比照国内的HTTPS部署情况，并没有相关的统计数据，但可预见对 HTTPS 协议的认知度并不高，也期望我们邮箱和其余邮箱服务商一样，在 https 协议的推广方面能做出表率。

Google 和 Facebook 的少量技术专家也对 HTTPS 的性能进行了综合的评估：

• HTTPS CPU 的消耗占 CPU 总消耗的比例小于 1%。
• 每个网络连接占使用的内存也仅仅是 10 kB ,额外带来的网络负载小于 2% 。
• 现代的服务器足够解决 HTTPS 协议运算，并不需要额外的硬件加速 HTTPS 协议运算 。

可见，从性能角度考虑，部署 HTTPS 网站已经成了大趋势了，未来我们也会部署基于 HTTPS 协议的 HTTP/2 协议，它带来的性能提升是巨大的，完全可以抵消 HTTPS 协议带来的性能损耗。

（2）兼容性

新浪邮箱是国内最早的邮件服务商，积累了很多使用户，尤其少量老使用户，他们不喜欢升级电脑操作系统，而老的操作系统不能够支持最新的 HTTPS 协议（比方还在用 ssl v2.0 协议），假如我们贸然的部署 HTTPS 协议（尤其用安全级别更高的 tls v1.2 协议），那么这部分使用户将无法用我们的服务，我们必需在安全性和可使用性方面做一个平衡。

我们也进行过很多的灰度测试，包括对某些高版本的浏览器强制用 HTTPS 协议，一切的一切，都是为了避免干扰使用户用邮箱。而到今年，我们确认 HTTPS 网站的部署在可行性和必要性方面已经不存在太大的问题了，才完整部署了全站 HTTPS 策略。

但为了尽量让老使用户能够用 HTTPS 服务，我们降低了安全级别，这也是一种折中，用 ssllabs 检测，发现我们的服务评分并不高（如下图），这都是无奈之举，相信随着我们和使用户的努力，未来我们会部署更高安全级别的 HTTPS 协议版本。

评分

目前某些使用户可能无法用邮箱，主要包括：

• 用 Android 2.3.7 操作系统的使用户
• 用 Windows XP 系统/IE6 浏览器的使用户

假如你还在用古老的系统和浏览器，建议你更新，这样才能保证你的安全。接下去讲解部署 HTTPS 服务的少量技术细节。

证书

部署 HTTPS 网站必需拥有一张证书，和证书形影不离的是服务器私钥（一旦泄露会存在安全风险），证书和私钥需要部署在服务器上，证书包含的最关键属性是网站的域名。

新浪集团是统一购买收费证书的，选择的是 SAN 通配符证书，该证书包含了集团所有的子域名（甚至三级子域名），查看证书，发现包含了很多子域名，具体看下图：

证书

选择通配符 SAN 证书的好处在于：

• 统一管理，由集团负责证书的申请、升级、撤销，保证合法用。
• 展开的新业务（比方世界杯新添加的 2018.sports.cn 域名）无需额外申请或者者升级证书，非常的便利。

通配符 SAN 证书是非常昂贵的，但为保障使用户的安全，这些花费是必需的。我们选择的证书是由 DigiCert CA 签发的，这是一家老牌的 CA 机构，证书兼容性和服务都不错。假如你想节约成本，可以选择免费 CA 机构 Let’s Encrypt 签发的证书，其在功能方面和收费 CA 机构并没有太大的差异，完全可以用，而且其现在也已经支持 SAN 通配符证书了，详细可以理解《Let’s Encrypt 终于支持通配符证书了》这篇文章。

HTTPS 网站系统架构

首先理解下企业邮箱网站服务对应的服务和域名：

• mail.sina.net，官网。
• webmail.sina.net，Webmail。
• entadmin.sina.net，企业邮箱网站管理系统。
• www.sinaimg.cn，静态元素，包括 js、css、图片，统一部署在公司 CDN。

先理解企业邮箱原价 http 网站是如何部署的，结构图如下：

http架构

详情架构图的起因在于：

• 让邮箱使用户理解我们系统是如何部署的，可见为了提升网站响应速度，在全国部署了多个点。
• 假如要支持 HTTPS 协议，因为证书的存在，整个系统架构将产生变化，使系统更复杂。

最终我们采使用了 Cloudflare 提出的 Flexible SSL 处理方案，整个系统架构演变如下图：

https架构

通过比较，可见为了支持 HTTPS 协议，做了以下少量改进。

（1）nginx ssl 卸载

HTTPS 协议相比 HTTP 协议，在握手层添加了屡次连接，服务器一下子添加了成倍的连接数，导致并发能力下降；同时服务器要运行大量的密码学运算，单机的并发解决能力也会下降。也就是 Web 服务器既要解决 HTTPS 连接，还要负责业务的解决，整个服务器已经不堪重负了。

为理解决该问题，我们用一组集群专门解决 HTTPS 连接和密码学运算，而邮箱业务的解决则以 http 代理商的方式让后台 Web 集群解决。

这种分层架构让整个系统更加简洁、健壮，nginx ssl 卸载专门负责解决 HTTPS 连接和运算，假如解决能力下降，可以横向扩容，同时也可以选择专门的服务器加速 HTTPS 连接（比方 AES-NI 指令集加速），也可以采使用硬件加速方案。

简洁意味着，假如要修改 HTTPS 配置（比方未来支持 tls v1.3 协议），直接统一在 ssl 集群升级配置就可，完全是透明的，后台 Web 集群不要做任何解决，也意识不到协议更新了。

我们也屡次提到证书和密钥必需协同部署，将他们部署在专有 ssl 集群的好处是什么？ssl 集群由专门的运维人员维护，服务器数量也相对较少，开发人员根本接触不到，泄露密钥的可能性大大减少。

（2）Flexible SSL

nginx ssl 卸载保证所有的用户请求都用 HTTPS 协议，而 nginx ssl 卸载和后台 Web 集群（邮箱业务）之间却采使用 http 协议的方式连接，我们不禁有疑问，这安全吗？

这种方案相对是安全的，由于 nginx ssl 卸载和后台 Web 集群之间是私有网络（公司局域网）连接的，攻击者一般很难攻破后台 Web 集群。

采使用这种方案最大的好处就是解决速度提升、架构简单。思考一下，假如后台 Web 集群也要支持 HTTPS 协议，不但成本上升，而且还要部署证书和密钥，因为开发人员接触 Web 集群比较多，私钥泄露的可能性大大加大，同时 Web 集群还要解决 HTTPS 连接和运算，运算速度大大降低。

一般情况下 CDN 后台源站采使用 HTTPS 连接方式，在企业的处理方案中，完全可以采使用 Flexible SSL 方案。

接下来理解 nginx ssl 卸载是如何配置的：

server {   listen       443 ssl;   server_name  mail.sina.net;   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;   ssl_certificate      cert.pem;   ssl_certificate_key  cert.key;   location / {      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;      proxy_set_header Host "mail.sina.net";      proxy_set_header X-Forwarded-Proto https;      proxy_redirect off;      proxy_pass http://endmail.sina.net;      proxy_http_version 1.1;   }}

接下去看看 Web 后台是如何配置的：

server {   listen       80;   server_name  endmail.sina.net;   location / {     root  /usr/share/nginx/html;     index  index.html index.htm;   }}

这个配置并无特殊之处，就是简单的一个 HTTP 服务，不使用配置证书，也就是对于开发者来说，他只负责解决业务逻辑，根本不关心使用户请求的是 HTTP 协议还是 HTTPS 协议，假如想知道使用户采使用哪种协议访问，可以读取 X-Forwarded-Proto HTTP 消息头，这个消息头由 ssl 卸载传递。

全站 HTTPS 策略

上述讲述的证书部署、网站架构调整一般都由公司统一部署和管理，对于我们邮箱开发者来说，涉及的不多，减少了很多工作。接下去讲解的内容都和开发者有关，而且非常重要。

对于邮箱使用户来说，企业邮箱支持 HTTPS 协议不代表就是安全的，比方访问企业邮箱某个页面，尽管访问地址是 https，但假如出现下列图片形容的情况，至少代表该页面依然是不安全的，存在安全风险。

警告

起因就在于该 https 页面中加载了非 https 协议的元素（混合内容），比方图片、css、js，常见的攻击称为 SSL 剥离攻击，攻击者可以阻拦该 http 协议的页面，从而获取到明文的 cookie 信息，进而攻击使用户，造成使用户的隐私泄露。

为了在 HTTPS 协议层面保障邮箱使用户的安全性，必需实施全站 HTTPS 策略，简单的来说，你访问的任何一个页面、一个元素都必需以 HTTPS 协议的方式访问；你网站有多少个域名（企业邮箱主要有四个域名），那么这些域名都必需配置证书，提供 HTTPS 协议访问方式。这就是全站 HTTPS 策略，想尽一切办法避免存在 http 页面或者元素。

假如开发者不了解全站 HTTPS 策略的重要性，就会犯以下的少量错误：

• HTTP 协议和 HTTPS 协议共存，比方尽管整站提供 HTTPS 协议，但假如使用户手动输入 HTTP 协议地址，同样能够提供服务。
• 某些重要的服务（比方登录页面）以 HTTPS 协议的方式提供，而非重要页面依然以 HTTP 协议的形式访问。
• 一个 HTTPS 协议的页面存在混合内容，也就是加载了 HTTP 协议的元素。
• 因为历史起因，网站上依然存在很多 HTTP 协议的页面（关于这部分情况后续会重点形容）。

确定了全站 HTTPS 策略以后，我们邮箱开发者要做的就是尽最大可能将 HTTP 协议的页面或者元素替换为 HTTPS 协议的页面或者元素，让我们看看有哪些工作要完成。

企业邮箱整个网站由后台程序和前台程序组成，这两者都会引入元素，假如要让引入的元素都以 HTTPS 协议的形式提供，必需修改代码，所幸，不论是后台程序还是前台程序，代码的板块化做的比较好，通过修改配置文件就转化了大部分 HTTP 协议地址。

但事情也并非一帆风顺，我们也遇到了一点挑战，企业邮箱加载的元素有本站的也有外站的，对于本站的元素我们替换地址就可，而外站的元素有些可能并不支持 HTTPS 协议，那怎样办？

何为外站的元素？外站就表示访问地址的域名是企业邮箱不能控制的，比方 www.test.com 域名下的一个元素。

使用户奇怪的是为什么企业邮箱会引入外站元素？由于使用户的邮件内容支持 html 格式（富文本），html 页面可以包含图片等元素，使用户发送的邮件内容是企业邮箱不能干预的，从而一封邮件中可能会引入外站的元素。

我们是怎样处理的呢？我们采取了一个代理商的方案，也就是将所有的外站元素保存到服务器上，而后以企业邮箱的域名呈现元素的内容。这种方案非常消耗服务器性能，添加服务器存储，但从安全的角度考虑，这是值得的。

提供一个小技巧，这就是 //mail.sina.net 的语法，// 表示相对协议 URL（Protocol-relative URL），是非常有使用的一种语法。假如主页面用 https:// 协议访问，则引使用的资源才也用 https:// 协议访问，假如主页面用 http:// 协议访问，则引使用的资源才也用 http:// 协议访问。

301 和 HSTS

可不论我们邮箱开发者再怎样修改，还是会存在 http 页面和元素的存在，起因：

• 因为企业邮箱的历史非常悠久，有些页面和元素我们可能没有替换完成。
• 搜索引擎收入了很多 http 页面，或者者使用户收藏了很多 http 页面。
• 假如使用户输入 mail.sina.net，浏览器因为不知道该网站能否支持 HTTPS 协议，所以依然以 http://mail.sina.net 的形式访问。

为了让这些页面和元素也以 HTTPS 协议的形式提供服务，我们主要采取了 301 和 HSTS 的方案。

企业邮箱是一个“弱网址”的服务，让我们迁移的工作轻松了不少。邮箱使用户用邮箱就是打开官网，而后登陆到 Webmail（webmail.sina.net），在 Webmail 中，使用户不关心浏览器地址，而微博、博客不一样，每一条微博、博文都有一个固定 URL 地址，可以分享到其余软件中（微信、QQ 等等），也就是说使用户很少保存 Webmail 中的地址，而且 Webmail 是私人的，不会被搜索引擎收入，也就是说我们主要解决官网的 HTTP 地址转换。

Webmail HTTP 地址解决：

server {    listen       80;    server_name  webmail.sina.net;    rewrite      ^ https://mail.sina.net;}

官网 HTTP 地址解决：

server {    listen       80;    server_name  webmail.sina.net;    rewrite      ^ https://$server_name$request_uri? permanent;}

这两个配置说明说明？假如使用户保存了一个 Webmail 的 HTTP 地址，则统一跳转到 https://mail.sina.net，假如使用户保存一个官网的 HTTP 地址，则统一将 http 标识符转换为 https 标识符。

用 301 跳转能够处理问题，但依然有少量缺陷：

• 301 需要服务器进行一次跳转，从 Web 优化的角度看，是非常消耗性能的。
• 301 在跳转的时候，依然有一次 HTTP 请求，依然存在 ssl 剥离攻击。

所以我们也同时采使用了 HSTP 机制，首先强调下，301 和 HSTP 机制各有应使用场景，一般情况下配合用，HSTS 机制是为了弥补 HTTPS 协议在 Web 应使用中的弱点而提出来的，可以说非常重要。

简单说下 HSTS 工作原理，当浏览器发现某个域名存在 HSTS 头部信息（该头部信息有缓存时间），则该域名下的所有请求都会转换成 HTTPS 地址后再请求，这是一个内部 307 跳转，所以不会影响用户端和服务器端性能，HSTS 头部是实施全站 HTTPS 策略最重要的技术手段。

当然 HSTS 生效需要浏览器和服务器共同支持才可以，也就是说假如浏览器不支持该标准，那么就没有任何作使用。

HSTS HTTP 头部标准如下：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

解释下重要的参数：

• max-age，服务器告诉某个用户端，在 31536000 秒内，应该实施 HSTS 标准，这段时间内假如用户端重新访问了 HTTPS 网站，max-age 时间就会被重新刷新。
• includeSubDomains，服务器告诉用户端域名下的所有子域名都实施 HSTS 标准，不仅仅是发出 HSTS HTTP 头部的主机才遵循该标准。
• preload，简单的说就是浏览器预存了需要实施 HSTS 标准的网站，假如不配置，则第一次访问依然会有一次 301 跳转。

灰度上线

HTTPS 迁移这个项目前后执行了很长时间，根本的准则就是严谨，尽量避免影响使用户的用，主要的步骤如下：

（1）HTTP 访问和 HTTPS 访问并行，也就是说不论输入 http 标识符还是 https 标识符都能用企业邮箱。

（2）整个邮箱部门工作人员统一测试 HTTPS 地址，收集 HTTP 地址（没有修改到位的）并改正，主要的技术手段就是收集 Access 日志，根据 Referral 判断 HTTPS 页面能否存在 HTTP 地址。

比较自动化的分析手段是采使用了 CSP 消息头，比方配置如下 CSP 规则：

add_header Content-Security-Policy-Report-Only "default-src https:;report-uri /cspreport.html;";

该规则表示一旦浏览器发现某个加载元素不是 https 协议，就会向 /csoreport.html 发送一条 POST 请求，请求中包含了少量调试信息，从而我们邮箱开发者就能知晓那些 HTTP 地址没有转换了，CSP 消息头非常有使用，可以重点关注。

（3）官网用 301 规则，切换到 https 地址（除了登录页面），选择官网的起因在于页面比较简单，即便出现问题，也不会大面积影响使用户。

（4）官网的登录程序能够控制 Webmail 的跳转（也就是说可以从入口决定是跳转到 http://webmail.sinanet 或者 https://webmail.sina.net），所以通过策略让特定使用户（抽样使用户、特定区域使用户）用 HTTPS 地址，并收集能否有这些使用户针对 https 访问提出的 Bug。

（5）企业邮箱官网全面启使用 301 规则（包括登陆页面）和 HSTS 规则。

（6）Webmail 全面启使用 301 规则和 HSTS 规则，整个迁移工作完成。

最后，我们针对安全工作是认真的，邮箱使用户假如遇到任何安全问题，可以及时反馈，我们要做的就是尽最大可能保障使用户的安全。

我最近写了一本书《深入浅出HTTPS：从原理到实战》，欢迎去各大电商购买，也欢迎关注我的公众号（yudadanwx），理解我最新的博文和本书。

qrcode_for_gh_27a6d90762d3_258.jpg