IT技术博客大学习 共学习 共进步
首页 / Jerry Qu
IT 2016-12-22 23:35:13 / 累计浏览 1,900

HTTPS 常见部署问题及解决方案

这篇文章整理了作者在 HTTPS 和 HTTP/2 部署实践中收集的典型故障与解决方案，堪称一份实用的排错手册。 遇到问题时，作者推荐首先使用 Qualys SSL Labs 的在线测试工具进行诊断。针对 Let's Encrypt 证书申请验证失败的情况，文章建议改用 acme.sh 的 DNS 验证模式，通常能绕过服务器访问限制。对于 Chrome 53 浏览器报告的 ERR_CERTIFICATE_TRANSPARENCY_REQUIRED 错误，根因是 Chrome 的一个 Bug，解决方案是升级浏览器版本。 当浏览器提示证书错误时，文章指出需检查证书链的完整性，特别是不要遗漏中间证书。如果问题仅出现在老旧浏览器（如 IE8），则很可能是未启用 SNI（服务器名称指示）导致，可通过将站点部署在不同服务器、使用 SAN 证书或直接忽略这些旧浏览器来解决。 启用 HTTP/2 后访问异常（如 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY），通常是因为 CipherSuite 配置不当，可参考 Mozilla 或 CloudFlare 的权威配置进行调整。若浏览器在 Nginx 启用 HTTP/2 后仍降级为 HTTP/1.1，则可能是 OpenSSL 版本过低（低于 1.0.2）不支持 ALPN 协议协商所致。 最后，升级 HTTPS 后网站部分资源无法加载，原因往往是混用了 HTTP 资源，解决方案是确保所有外链资源均使用 HTTPS 协议。文章内容会持续更新，为开发者提供了具体的排查思路和改进方案。

IT 2016-04-05 14:54:35 / 累计浏览 2,780

三种解密 HTTPS 流量的方法介绍

这篇讲的是如何从技术层面解密 HTTPS 流量，作者从三种最常规的方法入手，深入浅出地剖析了 HTTPS 并非绝对安全背后的原理。 文章首先介绍了中间人攻击（MITM）方式，Fiddler、Charles 等调试工具就是通过向系统导入自签的根证书，充当浏览器和服务器间的“中间人”来解密流量。其次，文章探讨了如何使用 Wireshark 配合网站的 RSA 私钥进行解密。不过，作者明确指出了这种方法的局限：它只能解密采用 RSA 密钥交换的流量，对于目前主流的、具备前向安全性的 ECDHE 密钥交换则无能为力。因此，它也无法解密 HTTP/2 流量。 第三种方法则依赖于浏览器自身的 `SSLKEYLOGFILE` 环境变量。设置后，浏览器会导出密钥日志，使得 Wireshark 能够解密包括 ECDHE 在内的所有流量，但这主要用于开发者调试，并非安全漏洞。 文章最后给出了切实的安全建议：网站应启用具有前向安全性的 ECDHE 算法，并部署证书透明度等机制；用户则需警惕不受信的证书导入，并关注客户端自身的安全，因为恶意扩展同样能在浏览器内部窃取数据。

IT 2016-04-02 22:59:49 / 累计浏览 1,840

使用 Elasticsearch 实现博客站内搜索

作者从使用 Bing 的 `site:` 搜索作为博客站内搜索方案所遇到的索引更新延迟问题出发，转而决定自建搜索服务。这篇实操记录详细介绍了如何使用 Elasticsearch 这一分布式搜索引擎来实现这一目标。 文章首先指导读者在 Ubuntu 环境下手动安装 Elasticsearch，随后重点讲解了配置的关键步骤：安装并编译 IK Analysis 插件以支持智能的中文分词（提供了 `ik_max_word` 与 `ik_smart` 两种粒度选项），以及通过修改配置文件添加同义词过滤器，让搜索能识别“js”和“javascript”这类等价术语。 在基础服务搭建完毕后，作者进一步展示了如何通过 Node.js 客户端将 Elasticsearch 无缝集成到现有的博客系统中。最终实现的搜索不仅支持中文分词与同义词，还通过定制查询策略达成了“标题匹配优先”和“近期文章优先”的优化效果，为读者提供了一个从部署到应用的全链路参考。

IT 2016-04-02 22:41:54 / 累计浏览 2,440

Certificate Transparency 那些事

这篇深入探讨了 Certificate Transparency（证书透明度）的重要性和实践。作者从本站启用 HTTPS 策略的两个变化切入，重点解释了 CT 要解决的核心问题：现有证书信任体系中，受信任的 CA 可能因失误或恶意签发“非法证书”，且域名管理不善也可能导致证书被冒领，而这些风险在传统机制下难以快速发现和消除。 文章清晰地拆解了 CT 系统的三部分——Certificate Logs、Certificate Monitors 和 Certificate Auditors，阐明了其作为现有 CA 体系补充的开放审计与监控原理。核心价值在于提供了实时、透明的证书状态查询能力，让域名所有者能主动发现错误签发。 文中重点对比了启用 CT 的三种方案：由 CA 承担高成本的 X.509v3 扩展、使用者成本较高的 TLS 扩展（通过 Web Server 发送 SCT），以及需 CA 配合的 OCSP Stapling。作者最终选择了普适性最强的 TLS 扩展方案，并提供了在 Nginx 环境下的具体操作步骤：从使用 ct-submit 工具获取 SCT 文件，到编译加入 nginx-ct 模块，再到最终的配置修改，形成了一个完整的实践闭环。对于关注 HTTPS 安全增强的技术人员而言，这是一份从理论到落地的详实参考。

IT 2016-04-02 22:36:28 / 累计浏览 2,180

HTTP Public Key Pinning 介绍

这篇讲的是如何通过 HTTP Public Key Pinning（HPKP）技术，让网站主动指定可信任的证书颁发机构，以抵御中间人攻击。作者从当前 HTTPS 证书信任体系的漏洞切入——任何一家受信任的 CA 都可能为任意网站签发合法证书，虽然 Certificate Transparency (CT) 能通过审计机制改善此问题，但尚未完全普及。 HPKP 提供了另一种思路：网站通过响应头“固定”自己证书链中特定证书的指纹。浏览器后续访问时，必须验证证书是否匹配这些指纹，否则即便证书合法也会拒绝连接。文章详细说明了配置字段，并重点讨论了 `pin-sha256` 指纹的生成策略：使用中间证书指纹在安全性和易用性间取得了较好平衡，同时建议预备备用指纹以应对 CA 变更。作者还给出了使用 OpenSSL 生成指纹和配置 Nginx 的具体示例。 不过，HPKP 也存在首次访问可能被劫持的局限，类似 HSTS，目前主要依赖浏览器内置的 Preload List 来解决。整篇文章清晰对比了 HPKP 与 CT 的不同防护路径，并给出了切实的配置指导。

IT 2016-04-02 13:15:20 / 累计浏览 800

从启用 HTTP/2 导致网站无法访问说起

这篇讲的是网站升级到 HTTP/2 后反而无法访问的典型案例。作者从朋友遇到的具体故障出发——启用 HTTP/2 后 Chrome 报「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」错误，Firefox 直接中断请求，而关闭 HTTP/2 则一切正常。 问题的根源在于 HTTP/2 协议对 TLS 有更严格的安全限制。它强制要求使用 TLSv1.2 或更高版本，并禁用了一大批在旧协议中可用的加密套件（CipherSuite）。当服务端配置的 CipherSuite 列表被包含在 HTTP/2 的黑名单中时，浏览器在 TLS 握手阶段就会直接终止连接，导致页面无法加载。文章通过 Wireshark 抓包和具体的 Nginx 配置示例，清晰地展示了这一协商失败的过程。 对于遇到类似问题的开发者，这篇不仅提供了调整 CipherSuite 配置的直接解法，更重要的是梳理了从现象到本质的排查思路，值得参考。

IT 2016-03-23 17:51:36 / 累计浏览 2,000

从无法开启 OCSP Stapling 说起

这篇讲的是，作者从读者常问的“为什么在Nginx中配置了 ssl_stapling on 却没生效”这个问题出发，深入剖析了OCSP Stapling的原理与实操。文章先简要回顾了OCSP（在线证书状态协议）会拖慢TLS握手，而OCSP Stapling（让服务端主动提供状态）是优化这一过程的关键。 接着，作者没有停留在理论，而是手把手教读者一个轻量的排查方法：使用openssl命令行工具进行验证。通过一条具体命令和对输出结果的解读（比如看到“OCSP Response Status: successful”就说明已开启），读者可以快速自检，而无需等待SSL Labs的漫长检测。 文章进一步深入，展示了完整的OCSP Response内容，并解释了其由“验证数据”和“签名证书”两部分组成。最后，文章还指导读者如何在本地获取证书链并主动查询OCSP信息，从原理层面帮助开发者真正理解这一机制，而不仅仅是配置一行代码。

IT 2016-03-21 23:42:29 / 累计浏览 2,000

从 Nginx 默认不压缩 HTTP/1.0 说起

这篇讲的是，Nginx 默认只为 HTTP/1.1 启用 GZip 压缩，而对 HTTP/1.0 请求关闭压缩，这背后并非配置疏忽，而是 HTTP 协议特性在服务端实现中的一个关键权衡。 文章从移动端异常高比例的 HTTP/1.0 流量这一现象切入，深入剖析了原因。Nginx 默认采用即时压缩（On-The-Fly Compression）以优化首字节时间，但这导致无法预知响应大小，无法设置 Content-Length。在 HTTP/1.0 中，没有 HTTP/1.1 的 Transfer-Encoding: chunked 分块传输机制，客户端只能依靠 Content-Length 或断开连接来判断结束。因此，Nginx 为了在 HTTP/1.0 上尽可能保持持久连接（keep-alive），默认选择了放弃压缩。一旦启用 HTTP/1.0 压缩，Nginx 就只能返回 Connection: close 来结束传输。 文章通过对比测试验证了这一机制，并给出了务实建议：对于动态内容（如 PHP 输出的 HTML），因其本身无法预知大小，不妨启用 GZip 以节省流量；对于可预知大小的静态文件（JS、CSS），则建议将关键资源内联，非关键资源用外链并启用压缩，接受连接断开以换取流量节省。一个看似简单的 Nginx 配置，背后其实是 HTTP/1.0 与 1.1 在协议能力上的深刻差异。