共 32 篇相关文章
作者在本文中详细记录了个人博客遭遇CDN盗刷的事件。在短短5分钟内，恶意流量消耗了1.55TB数据和661万次HTTPS请求，根源在于此前因头像兼容性问题关闭了防盗链功能。攻击IP均来自境外地区，如美国、日本、韩国等，作者通过多吉云后台识别后，利用AI工具整理IP段并一次性封禁。随后重新启用时间戳防盗链功能，确保资源访问安全，并设置精细的风控策略，包括每秒QPS限制、每小时流量封顶以及针对特定User-Agent的过滤。损失计算显示，多吉云实际费用约193元，若使用其他服务商如又拍云则需493元，突出了费用优化。文章通过这次教训强调，安全防护不能心存侥幸，事前防御措施如防盗链和风控规则至关重要，事故后需持续加固以避免类似风险。
在阿里云环境中使用 Traefik 3 实现 HTTPS 服务接入和 SSL 证书自动管理，是一种高效的云原生实践。通过 AliDNS DNS Challenge，Traefik 能够自动与 Let's Encrypt 交互，完成证书的申请和续签，避免了手动操作的繁琐。结合 Docker Provider，当容器启动时，Traefik 自动检测并配置路由，实现服务的动态发现和负载均衡。阿里云 RAM 的最小权限设计确保 Traefik 仅拥有必要的访问权限，降低了密钥泄露的风险。文章详细介绍了部署步骤，包括 Traefik 的配置文件、Docker 集成方法以及 RAM 策略设置，还涵盖了运维中的常见问题处理和性能优化建议。此外，Traefik 的自动续签功能确保证书始终有效，减少了因证书过期导致的服务中断。Docker Provider 的灵活性允许无缝集成到现有微服务架构中，支持多容器部署。RAM 策略的精细化控制符合安全最佳实践，防止未授权访问。整体方案不仅提升了自动化水平，还增强了系统的可维护性和可扩展性，是阿里云环境下部署 HTTPS 服务的理想选择。
在常见的Nginx反向代理后端Java应用的部署架构中，客户端与Nginx之间为HTTPS，但Nginx转发至后端服务器的请求协议为HTTP。这会导致后端应用通过`HttpServletRequest.getRequestURL()`获取到的URL为内网HTTP地址，且`HttpServletResponse.sendRedirect()`生成的重定向地址也为HTTP，无法反映真实的客户端访问协议。 解决此问题需结合Nginx配置与后端代码调整。对于URL获取问题，需在Nginx中通过`proxy_set_header Host $host`和`proxy_set_header X-Forwarded-Proto $scheme`向后端传递原始主机名与协议信息。后端Java应用则需通过自定义Servlet过滤器，读取`X-Forwarded-Proto`头并重写请求的`getScheme()`与`getRequestURL()`方法，确保返回正确的HTTPS URL。对于重定向问题，可通过Nginx的`proxy_redirect http:// $scheme://`指令，将后端响应中的Location头协议自动修正。 当架构中Nginx前存在负载均衡器时，需由负载均衡器透传`X-Forwarded-Proto`头，同时将Nginx配置中相关的`$scheme`变量替换为`$http_x_forwarded_proto`，以正确识别和传递最前端的访问协议。
这是一篇关于使用Go语言`go:embed`功能将HTTPS证书嵌入可执行文件的技术教程。文章首先阐述了为Web服务启用HTTPS的必要性，即使在内网环境中，以保障数据传输安全、完整性并规避浏览器限制。针对内网无域名的场景，文章重点介绍了使用`openssl`生成自签名证书的具体步骤。核心部分详细演示了如何利用`go:embed`指令在编译时将证书文件（`.crt`与`.key`或合并后的`.pem`）嵌入程序变量，并解决Gin框架无法直接加载嵌入式证书的问题。通过自定义`http.Server`的`TLSConfig`配置，成功加载字节形式的证书，最终实现了将静态资源与HTTPS证书一并打包、开箱即用的Gin HTTPS服务。教程明确了`RunTLS`方法不适用于此场景，并展示了最终效果。
这篇笔记从Go服务器部署HTTPS后的实际问题切入，作者遇到了HTTP 400错误——当用户直接输入IP地址访问时，浏览器自动补充HTTP协议，与HTTPS服务冲突，导致服务器返回“Client sent an HTTP request to an HTTPS server”。根因在于Go官方没有内置HTTP到HTTPS的重定向功能，而手动修改协议方式不够便捷。 作者最初尝试在Gin中间件中检测TLS报文，但发现多次请求后识别不可靠。后来发现开源库 `hlfhr`，它通过劫持 `net.Conn` 实现自动重定向。具体方案是加载证书后，用 `hlfhr.New` 创建服务器并监听端口，实现访问HTTP时自动302跳转HTTPS。作者还fork项目调整状态码为307，避免POST请求被误转为GET，提升兼容性。 效果上，改造后用户访问HTTP地址会自动跳转至HTTPS，解决了体验痛点。对于Go开发者，这提供了一个轻量级的实现思路。
这篇讲的是HTTPS证书在有效期内如果私钥泄露，该怎么紧急“作废”它的故事。作者从《长安十二时辰》的望楼加密系统联想到现实中的证书安全，抛出了这个关键问题。 文章的核心是清晰对比了两种主流的吊销状态检测机制。一种是传统的证书吊销列表，它像个定期发布的“黑名单”，但更新慢、文件可能大到1MB，拖慢访问速度。另一种是在线证书状态协议，它支持实时查询，但每次访问都要去CA服务器问一句，不仅慢，还会把用户的浏览地址暴露给CA。 作者进一步点出了OCSP机制面临的两难困境：如果浏览器查不到响应就拒绝访问，CA服务器就成了单点故障；如果查不到就默认信任，那这个机制又形同虚设。最终，文章引出了OCSP Stapling这个更优的方案——把查询工作交给网站服务器来做，并缓存响应，既保证了实时性，又解决了延迟和隐私问题。整篇文章从一个有趣的梦出发，把看似枯燥的安全机制讲得有层次、有取舍。
这篇讲的是浏览器中Referer丢失导致来源分析失效的常见痛点，以及一个巧妙的后端解决方案。作者从实际项目出发，梳理了Referer丢失的五种主要场景：代码因素如JavaScript构造链接、HTTPS降级到HTTP时的协议限制、多核浏览器切换内核或隐私模式、鼠标手势等高级功能的干扰，以及来自微信或微博等移动App的点击。这些问题逐一修补开发量巨大，且浏览器兼容性复杂。 核心方案是采用基于会话的站内来源地址URL还原。具体做法是在服务端设置会话Cookie，例如通过OpenResty的encrypted-session模块生成加密会话，然后在日志分析系统中跟踪同一Cookie的访问路径。这样就能模拟还原用户完整的站内导航轨迹，无需依赖前端Referer头。 作者指出，这种方法绕开了传统修复中代码层面的繁琐调整，尤其应对多核浏览器和隐私模式这类难以控制的因素。通过后台日志的会话跟踪，网站能可靠地进行来源分析，提升了数据追踪的完整性和可维护性。
这篇文章从手机APP防协议分析的实际需求出发，探讨对称加密算法的选型，并特别“吐槽”了国内开发者圈对TEA算法的盲目推崇。作者通过分析指出，TEA算法的安全性存疑，且其“速度快”的印象已是过时的陈旧观念。 文章的核心论点在于，在现代硬件环境下，AES算法凭借原生指令集支持，其性能已远超TEA。为了佐证，作者亲自编写代码，在骁龙835、联发科Helio P10以及苹果A8等多款典型手机处理器上进行了详细测试。数据清晰地显示，即使是在中低端CPU上，AES的加密速度也能达到TEA的数十倍。 结论非常明确：对于绝大多数APP开发场景，无论是在Android上使用Java，还是在iOS上使用Objective-C/Swift，AES都应当是首选的对称加密算法，它能同时提供最优的安全性和性能。文章为开发者提供了一个基于实测数据的、非常扎实的算法选型参考。
作者分享的是他将个人技术博客CoolShell从HTTP升级到HTTPS的完整实践过程。文章背景很具体：因为HTTP访问在国内被运营商劫持注入了广告，同时考虑到HTTP在搜索引擎中的排名劣势，作者决定为网站免费启用HTTPS加密。 核心方案围绕开源的证书颁发机构Let’s Encrypt展开。作者通过其官方推荐的Certbot工具，在Nginx和Ubuntu系统上实现了证书的自动签发与安装。文章不仅给出了具体的命令行步骤，还分享了一个关键优化点：建议在Nginx配置中开启HTTP/2协议，以显著提升HTTPS下的传输性能。此外，针对Let’s Encrypt证书90天过期的特点，作者演示了如何用crontab设置定时任务来自动续期证书，确保服务不间断。 最后，文章也指出了启用HTTPS后的“收尾工作”：需要在WordPress等内容管理系统中，将所有的资源链接从http://强制修改为https://，并更新相关缓存插件设置，否则浏览器会因混合内容而阻断页面加载。整个过程从问题出发，到具体实施与优化，形成了一个清晰可复现的免费方案闭环。
这篇讲的是通过部署 HSTS（HTTP 严格传输安全）协议来强制浏览器使用 HTTPS 加密连接，从而避免用户首次访问时因 HTTP 跳转而产生的安全风险。作者指出，尽管许多网站已提供 HTTPS 服务，但用户习惯于输入域名，浏览器默认发起 HTTP 请求。这个跳转的瞬间，攻击者可能实施中间人攻击。HSTS 通过服务器在响应头中下发指令，让浏览器记住该域名必须使用 HTTPS，后续访问会直接发起安全连接。 文章详细拆解了开启 HSTS 的三个关键参数：必填的 `max-age` 定义了指令的有效时长（如一年），设置过短会增加暴露风险，过长则可能影响网站故障时的降级处理；可选的 `includeSubdomains` 将策略扩展到所有子域名，但需确保所有子站均已支持 HTTPS；`preload` 则更进一步，将域名预置入浏览器核心列表，实现首次访问即安全，但这也意味着极高的变更代价。 作者提醒，HSTS 依赖客户端行为，配置需谨慎。好消息是，如今各大浏览器已广泛支持，且免费 SSL 证书获取便捷，实施 HSTS 的门槛已大大降低，是提升整体互联网安全环境的有效手段。
这篇文章整理了作者在 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 协议。文章内容会持续更新，为开发者提供了具体的排查思路和改进方案。
这篇讲的是如何从技术层面解密 HTTPS 流量，作者从三种最常规的方法入手，深入浅出地剖析了 HTTPS 并非绝对安全背后的原理。 文章首先介绍了中间人攻击（MITM）方式，Fiddler、Charles 等调试工具就是通过向系统导入自签的根证书，充当浏览器和服务器间的“中间人”来解密流量。其次，文章探讨了如何使用 Wireshark 配合网站的 RSA 私钥进行解密。不过，作者明确指出了这种方法的局限：它只能解密采用 RSA 密钥交换的流量，对于目前主流的、具备前向安全性的 ECDHE 密钥交换则无能为力。因此，它也无法解密 HTTP/2 流量。 第三种方法则依赖于浏览器自身的 `SSLKEYLOGFILE` 环境变量。设置后，浏览器会导出密钥日志，使得 Wireshark 能够解密包括 ECDHE 在内的所有流量，但这主要用于开发者调试，并非安全漏洞。 文章最后给出了切实的安全建议：网站应启用具有前向安全性的 ECDHE 算法，并部署证书透明度等机制；用户则需警惕不受信的证书导入，并关注客户端自身的安全，因为恶意扩展同样能在浏览器内部窃取数据。
这篇深入探讨了 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 安全增强的技术人员而言，这是一份从理论到落地的详实参考。
这篇讲的是如何通过 HTTP Public Key Pinning（HPKP）技术，让网站主动指定可信任的证书颁发机构，以抵御中间人攻击。作者从当前 HTTPS 证书信任体系的漏洞切入——任何一家受信任的 CA 都可能为任意网站签发合法证书，虽然 Certificate Transparency (CT) 能通过审计机制改善此问题，但尚未完全普及。 HPKP 提供了另一种思路：网站通过响应头“固定”自己证书链中特定证书的指纹。浏览器后续访问时，必须验证证书是否匹配这些指纹，否则即便证书合法也会拒绝连接。文章详细说明了配置字段，并重点讨论了 `pin-sha256` 指纹的生成策略：使用中间证书指纹在安全性和易用性间取得了较好平衡，同时建议预备备用指纹以应对 CA 变更。作者还给出了使用 OpenSSL 生成指纹和配置 Nginx 的具体示例。 不过，HPKP 也存在首次访问可能被劫持的局限，类似 HSTS，目前主要依赖浏览器内置的 Preload List 来解决。整篇文章清晰对比了 HPKP 与 CT 的不同防护路径，并给出了切实的配置指导。
这篇讲的是 HTTPS 是如何保障通信安全的，以及我们该如何亲手生成和部署证书。文章从一个生动的电信用户遭遇 DNS 劫持、被注入广告的案例切入，点明了在 HTTP 明文传输下隐私暴露的风险。 作者详细拆解了 HTTPS 的核心安全机制：它在 HTTP 基础上增加了加密、认证和鉴定。通过一张流程图和清晰的步骤，文章描述了客户端与服务器如何通过交换随机数并生成会话密钥（session key）来建立安全通道。同时，文章也指出了仅有非对称加密不够，必须引入受信任的第三方 CA 来签发数字证书，以防中间人攻击。 文章进一步科普了 CA 证书的三种验证等级（DV、OV、EV），并提供了实操部分：使用 OpenSSL 命令从生成密钥对、创建 CA 根证书，到最终签发服务器证书的完整流程。最后，对于个人或小型站点，文章也提到了自签名证书这一低成本解决方案。 整体上，这是一篇从原理到实践的指南，既解释了“为什么需要 HTTPS”以及“它是如何工作的”，也手把手教你“如何自己动手做”。
这篇讲的是HSTS（HTTP严格传输安全）这个容易被忽略但至关重要的安全机制。作者从在淘宝首页意外看到罕见的307状态码切入，揭示了HTTPS网站面临的一个实际威胁：中间人利用HTTP（80端口）的首次请求进行劫持，替换广告或注入代码。 文章核心指出，HSTS通过服务器响应头中的`Strict-Transport-Security`字段来强制浏览器使用HTTPS，能有效堵住这个缺口。一个关键细节是，HSTS触发的跳转会使用特殊的307内部重定向状态码，这与常规的302跳转不同——它不会改变请求方法（如POST不会变GET），并且跳转可以被缓存，节省了额外的请求。 同时，作者也指出了HSTS的“坑”：它对纯IP地址或非标准端口无效；最危险的是，如果HTTPS未配置好就启用了HSTS且设置了长期`max-age`，可能导致用户无法访问网站。总体而言，文章清晰阐明了HSTS的工作原理、实际价值与部署风险，对于全站HTTPS化有直接的实践参考。
这篇讲的是如何在一个服务器上，为多个不同的域名部署HTTPS服务。传统上，一张SSL证书通常绑定一个域名，但在实际运维中，我们常常遇到一个服务器需要同时承载多个域名的情况。文章从这个现实背景出发，梳理了几种主要的解决方案。 最直接的方式是采用虚拟主机技术，为每个域名分配独立的IP地址并绑定各自证书，但这对IP资源要求较高。对于同级子域名，可以申请通配符证书，但它只能匹配二级子域名，无法覆盖更深层级或主域名本身。更灵活的方案是使用支持“使用者可选名字”（SAN）扩展的证书，通过XCA等工具，就能将多个不同的域名都写入同一张证书中。 如果必须为每个域名单独签发证书，那么SNI（服务器名称指示）技术就成了关键。它允许服务器在SSL握手阶段就识别出客户端请求的域名，从而返回正确的证书，实现“单IP、多证书”。文章指出，这项技术已获得主流浏览器和Web服务器的支持，为灵活部署HTTPS提供了坚实的基础。
这篇讲的是作者为抵抗运营商劫持，在Ghost博客上部署HTTPS与HTTP/2的实战全过程。核心方案围绕Nginx代理与SSL证书展开：最初尝试免费的Let's Encrypt证书，但因DNS验证问题放弃，转而选用商业Comodo证书；Nginx需升级至mainline版本以支持http2，并在监听配置中显式添加http2参数。 部署后遇到混合内容（mixed content）导致浏览器警告，关键解决方案是将子域名的图片路径迁移至主域下，通过Nginx的alias规则统一提供服务，并配置了HTTP到HTTPS的301跳转。整个过程验证了HTTPS/HTTP/2对防御劫持的有效性，同时也指出了SHA-2证书对旧版IE和Android的兼容性限制。文章记录了从证书选择、Nginx调优到内容迁移的完整踩坑与解决思路，对同类博客升级有直接参考价值。
这篇讲的是随着HTTPS成为主流，如何优化TLS握手带来的性能开销。作者从TLS握手需要消耗两个RTT（往返时间）的痛点出发，详细拆解了False Start优化技术——它允许客户端在握手尚未完全结束时就提前发送加密的应用数据，从而将握手延迟从两个RTT压缩至一个。文章还深入分析了证书链的优化策略，指出证书过长或中间证书缺失会导致额外开销，并推荐了使用ECC证书来显著减小证书体积。通过Wireshark抓包图，文章直观展示了这些优化前后的对比效果。对于正在部署HTTPS的开发者来说，这些关于握手流程和证书配置的实践细节，能有效帮助他们在不牺牲安全性的前提下提升连接速度。
这篇讲的是在iOS开发中如何让HTTPS连接更安全，作者从实际遇到的HTTPS问题出发，深入剖析了中间人攻击的几种常见形式。文章首先模拟了最简单的钓鱼式攻击，通过Charles代理工具详细演示了攻击者如何利用伪造证书窃取HTTPS流量，直观暴露了许多App仅依赖系统默认校验的安全隐患。 在此基础上，作者对比了SSL剥离等更具隐蔽性的攻击手段，并针对性地指出了防范关键：不仅要依赖系统校验，App内部更应对服务器证书进行本地的、硬编码的对比校验。文中还延伸讨论了iOS 9引入的App Transport Security（ATS）特性，以及如何使用Wireshark调试SSL/TLS通信，将理论与开发实践紧密结合。 对于希望加固应用网络安全的开发者而言，文章从攻击原理到防御代码都提供了具体思路，特别是关于WebView中易忽略的URL协议校验等细节，具有很强的实操参考价值。
