在最近几年里，我写了很多有关 HTTPS 和 HTTP/2 的文章，涵盖了证书申请、Nginx 编译及配置、性能优化等方方面面。在这些文章的评论中，不少读者提出了各种各样的问题，我的邮箱也经常收到类似的邮件。本文用来罗列其中有代表性、且我知道解决方案的问题。

    Web 安全是一项系统工程，任何细微疏忽都可能导致整个安全壁垒土崩瓦解。拿 HTTPS 来说，它的「内容加密、数据完整性、身份认证」三大安全保证，也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全，其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理，浅谈一下 HTTPS 的安全风险。

    一直以来，为了优化本博客站内搜索效果和速度，我使用 bing 的 site: 站内搜索做为数据源，在服务端获取、解析、处理并缓存搜索结果，直接输出 HTML。这个方案唯一的问题是时效性难以保证，尽管我可以在发布和修改文章时主动告诉 bing，但它什么时候更新索引则完全不受我控制。 本着不折腾就浑身不自在的原则，我最终还是使用 Elasticsearch 搭建了自己的搜索服务。Elasticsearch 是一个基于 Lucene 构建的开源、分布式、RESTful 搜索引擎，很多大公司都在用，程序员的好伙伴 Github 的搜索也用的是它。本文记录我使用 Elasticsearch 搭建站内搜索的过程，目前支持中文分词、同义词、标题匹配优先、近期文章优先等常见策略。

    最近本站 HTTPS 方面有两个变化：一是本站域名（imququ.com）加入了 Chrome 的 HSTS Preload List，从 Chrome 49 开始生效；二是我给本站 HTTPS 证书启用了 Certificate Transparency 策略。HSTS Preload List 在我之前的文章中写过，更多介绍及如何申请加入请点这里。本文主要介绍 Certificate Transparency。

    上篇文章中，我介绍了由 Google 推动的 Certificate Transparency 技术，它旨在通过开放的审计和监控系统，提高 HTTPS 网站证书安全性。本文要介绍的 HTTP Public Key Pinning（HPKP），也是用来防范由「伪造或不正当手段获得网站证书」造成的中间人攻击，但有着与 CT 不同的思路。 我们知道，受信任的 CA（证书颁发机构）有好几百个，他们成为整个网站身份认证过程中一个较大的攻击面。现有的证书信任链机制最大的问题是，任何一家受信任的 CA 都可以签发任意网站的站点证书，这些证书在浏览器看来，都是合法的。前面提到的 CT 技术能改善这种情况，但 CT 还没有普及，现阶段浏览器不能贸然阻断没有提供 SCT 信息的 HTTPS 网站。

    最近好几个朋友在给网站开启 HTTP/2 后，都遇到了无法访问的问题。其中有的网站只是 Firefox 无法访问，通过控制台网络面板可以看到请求被 Abort；有的网站不但 Firefox 无法访问，连 Chrome 也会跳到错误页，错误代码是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。诡异的是，只要去掉对 HTTP/2 的支持（例如去掉 Nginx listen 配置中的 http2）就一切正常。也就是说无法访问的现象只存在于 HTTPS + HTTP/2 的组合，单独提供 HTTPS 服务时就是好的。

    最近收到的几封读者邮件，都是询问为什么在 Nginx 中无法开启 OCSP Stapling。具体现象是在 Nginx 中明明配置了 ssl_stapling on，但通过 SSL Labs 等工具查看，OCSP stapling 这一项并没有生效。本文就这个问题详细探讨下，如果你只关心结论，直接跳到最后一节即可。

     也就是说在相同的服务端配置下，移动运营商过来的流量中有 30% 走了 HTTP/1.0，而作者所使用的 HTTP Server，不对 HTTP/1.0 响应启用 GZip。 为什么在移动运营商网络下会有这么高比例的 HTTP/1.0 请求，本文按下不表，总之这一定是移动的原因。直接看另外一个问题，也就是本文标题所写：Nginx 为什么默认不压缩 HTTP/1.0？