新浪邮箱全站HTTPS实施之路

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

HTTPS 协议到底解决了什么问题？

当企业邮箱用户在浏览器中输入 https://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 协议部署量进行了统计，结果如下：

统计网站数量	201601	201701	201710	目前的占比
全球顶尖10.000个网站	743	1.365	4.031	40%
全球顶尖100.000个网站	3.885	8.083	38.212	38%
全球顶尖1.000.000个网站	56.455	117.835	270.733	27%

对比国内的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 https://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:// 协议访问，如果主页面使用 https:// 协议访问，则引用的资源才也使用 https:// 协议访问。

301 和 HSTS

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

• 由于企业邮箱的历史非常悠久，有些页面和元素我们可能没有替换完成。
• 搜索引擎收入了很多 http 页面，或者用户收藏了很多 http 页面。
• 如果用户输入 mail.sina.net，浏览器由于不知道该网站是否支持 HTTPS 协议，所以仍然以 https://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 的跳转（也就是说可以从入口决定是跳转到 https://webmail.sinanet 或 https://webmail.sina.net），所以通过策略让特定用户（抽样用户、特定区域用户）使用 HTTPS 地址，并收集是否有这些用户针对 https 访问提出的 Bug。

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

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

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

你也许感兴趣的：

• [外文翻译]为什么Stack Overflow需要用几年时间才把网站迁移到HTTPS
• PHP和HTTPS
• 聊聊HTTPS和SSL/TLS协议
• 【外评】电脑从哪里获取时间？
• 【外评】为什么 Stack Overflow 正在消失？
• Android 全力押注 Rust，Linux 却在原地踏步？谷歌：用 Rust 重写固件太简单了！
• 【外评】哪些开源项目被广泛使用，但仅由少数人维护？
• 【外评】好的重构与不好的重构
• C 语言老将从中作梗，Rust for Linux 项目内讧升级！核心维护者愤然离职：不受尊重、热情被消耗光
• 【外评】代码审查反模式