标签：HTTPS

共 32 篇相关文章

IT 累计浏览 3,469

iOS安全系列之一：HTTPS

这篇讲的是HTTPS，但不是泛泛而谈。作者从iOS开发者普遍对安全不够重视的现状出发，指出即便是未越狱设备，网络安全依然是不可回避的课题。文章的核心，是厘清HTTPS并非什么新协议，其本质只是在HTTP之下增加了一层SSL/TLS加密。最硬核的部分在于对SSL/TLS原理的拆解：它通过四次握手交换三个随机数来生成安全的“对话密钥”，并依赖数字证书体系（PKI）进行身份验证。文章用清晰的逻辑讲透了证书的签发与验证流程——接收端如何通过哈希对比和递归验证，最终追溯到操作系统内置的根CA。这解释了“为什么信任链的起点如此重要”。在实现层面，文章没停留在理论。它具体展示了如何在iOS的NSURLConnection中处理证书验证回调，利用Security Framework的API完成Trust Object的评估。无论是使用系统默认验证，还是为自建证书等高安全场景进行更严格的本地匹配校验，都给出了可落地的代码思路。对于想用AFNetworking简化流程的开发者，也有明确的指引。从概念辨析到原理图解，再到代码级实践，这篇文章提供了一条清晰的路径，帮助开发者完成从HTTP到HTTPS的安全升级。

IT 累计浏览 17,438

HTTPS, SPDY和 HTTP/2性能的简单对比

这篇翻译文章源于作者对抗运营商网络劫持的关注，借此机会详细对比了传统HTTPS、SPDY/3.1以及新兴的HTTP/2协议在性能上的具体差异。测试以Google英国首页为例，在相同条件下对比三者。一个关键区别在于报头压缩：HTTP/2采用的HPACK算法，在报头大小上显著优于SPDY所使用的DEFLATE压缩，使得HTTP/2的空请求报头体积最小，优势明显。在响应信息大小方面，情况则更为复杂。对于图片资源，三者表现相近。但对于文本内容，虽然HTTP/2报头更小，但其数据帧的可选填充字节，使得最终响应信息反而大于SPDY。文章解释，这种填充机制主要是为了对抗如BREACH等特定安全攻击。总体来看，HTTP/2在连接初期的数据传输效率上建立了优势，尤其是在报头处理上更为高效。而SPDY在某些特定内容的传输中依然保持着竞争力。文章通过具体的截图和数据，清晰地展示了下一代网络协议在优化性能与保障安全方面的不同设计权衡。

IT 累计浏览 3,526

SSLStrip 的未来 —— HTTPS 前端劫持

这篇文章探讨的是在HTTPS日益普及的今天，传统的中间人攻击工具SSLStrip面临的挑战与进化。作者从后端劫持的局限性出发，指出SSLStrip这类纯流量层的工具在现代Web面前已力不从心，难以处理动态生成的链接、数据包分片以及高昂的性能开销。核心思路因此转向“前端劫持”。通过向页面注入脚本，利用事件捕获机制（如监听全局点击事件），攻击者可以在用户点击链接的瞬间，临时将HTTPS地址修改为HTTP。这种方法巧妙地绕过了后端的种种问题：只需处理页面首个数据块即可完成渗透，对性能影响极小；同时能应对各种动态添加的链接，甚至表单提交、脚本弹窗和框架页面。文章详细解释了如何通过修改链接的href属性并在下个事件循环中还原，来实现实时且无痕的替换，比传统的DOM扫描轮询方案更为优雅和彻底。本质上，这篇内容揭示了网络攻击手段随技术栈演进的路径——从粗放的流量篡改，转向更精细、更贴近应用层的前端逻辑操控。对于安全研究人员和前端开发者而言，它清晰地展示了一种新型攻击面的技术原理与实现细节。

IT 累计浏览 2,667

Linux使用curl访问https站点时报错汇总

这篇整理了在使用Linux的curl命令行工具访问HTTPS站点时，几类最常见的证书相关报错及其解决方法。文章指出，问题的根源往往在于不同客户端（如curl、浏览器、Java程序）使用独立的证书库，而Linux的curl默认依赖位于 `/etc/pki/tls/certs/ca-bundle.crt` 的文件。摘要列举了四种典型情况：遇到“Peer’s Certificate issuer is not recognized”时，多是由于自签名证书未被信任，解决方法是将私有CA的公钥追加到系统证书库中。而“certificate verify failed”错误，则常因本地CA证书库过旧，无法识别新签发的证书，需要下载最新的cacert.pem进行替换或使用系统命令更新。当遇到“unknown message digest algorithm”时，根源在于系统的OpenSSL版本过低，不支持如SHA-256等新算法，升级OpenSSL是必要步骤。文章最后还对比了Java和PHP处理HTTPS的机制，指出它们拥有自己的证书库（如Java的cacerts），与系统curl的证书库相互独立。整篇文章以实战报错为线索，提供了直接的操作路径，对于解决这类环境配置问题很有参考价值。

IT 累计浏览 5,427

HTTPS、SSL与数字证书介绍

这篇讲的是HTTPS、SSL与数字证书三者如何协同工作，共同构筑起现代互联网通信的安全基石。作者从安全通信的基本需求出发，清晰地拆解了HTTPS（安全的超文本传输协议）的本质——在HTTP和TCP之间加入一个加密层，而SSL（或其升级版TLS）正是实现这个加密层的关键协议。文章没有停留在概念罗列，而是深入到了实现机制。它通过一个生动的A与B对话场景，形象地演示了SSL/TLS协议的“握手”过程：如何巧妙地结合非对称加密（用于安全地协商密钥）和对称加密（用于高效地传输数据）来平衡安全性与性能。同时，详细阐述了数字证书的核心作用——它如同网络世界的“身份证”，由权威的证书颁发机构签发，用于验证服务器身份并分发公钥，从而防止中间人攻击。对于证书的信任链，文章也给出了直观解释：客户端（如浏览器）内置了受信任的根证书列表，只有由这些机构颁发的证书才会被信任。整体而言，这篇文章将抽象的安全概念落到了具体的协议交互与文件验证上，是理解HTTPS工作原理的一篇扎实导读。

IT 累计浏览 2,858

在 Django/Flask 开发服务器上使用 HTTPS

这篇讲的是，如何在 Django 或 Flask 的开发服务器上，提前实现并测试 HTTPS 连接，而无需等待部署到生产环境。作者指出，框架自带的开发服务器默认不支持 HTTPS，这给需要在本地验证加密通信的开发者带来了不便。为了解决这个问题，文章引入了 **stunnel** 这个外部工具。stunnel 的核心作用是充当一个“加密翻译”，它监听 HTTPS 请求（如443端口），解密后转发给实际运行的 Django/Flask 服务（如8000端口），再将响应加密返回，从而为开发服务器“套上”一个安全通道。文章详细给出了实现步骤：首先在系统中安装 stunnel；其次，使用 OpenSSL 命令生成一个用于测试的自签名证书；然后，编写一个简单的 stunnel 配置文件，定义监听与转发的端口；最后，分别启动 stunnel 服务和 Django/Flask 开发服务器。值得注意的是，针对 Django 需要设置环境变量，而 Flask 则只需指定相同的监听端口即可。整体方案简洁实用，它通过一个轻量的外部组件巧妙地绕过了开发服务器的限制，让开发者能在本地完整模拟 HTTPS 环境，方便调试 Cookie、重定向等与安全协议相关的问题。

IT 累计浏览 1,029

以keystore方式为play!应用建立单向/双向SSL

这篇讲的是如何在Play!框架中配置SSL安全连接，而且特别澄清了官方文档的不足之处，避免读者被过时资料误导。作者先理清了SSL的核心：用对称加密传输数据，非对称加密（RSA）安全传递密钥。在此基础上，解释了单向SSL（服务端验证）和双向SSL（服务端与客户端互相验证）的区别，后者适用于需要严格控制访问权限的内部服务。配置的关键在于正确设置keystore。文章详细演示了生成服务端密钥库（certificate.jks）的命令，并特别指出密钥库口令与密钥口令必须一致这个容易忽略的坑。对于单向SSL，配置到此即可。如果需要双向SSL，流程还涉及在客户端生成并导出证书，然后将该证书导入服务端的密钥库进行“授信”。整个过程通过具体的keytool和openssl命令逐步拆解，甚至涵盖了使用curl和浏览器进行测试的不同方法，非常实操。文章用清晰的步骤，把Play!应用如何建立从单向到双向的SSL连接，从原理到命令都讲透了。

IT 累计浏览 6,376

你会做Web上的用户登录功能吗？

这篇讲的是Web用户登录功能中那些容易被忽略的安全陷阱。作者从实际观察到的许多网站登录实现问题出发，指出这个看似基础的功能，实际做起来比想象中复杂。文章首先拆解了常见的错误做法——比如前端明文传输密码、数据库使用明文存储、缺乏防护的暴力破解机制等。随后详细对比了安全实现的核心要素：必须使用HTTPS全站加密传输，后端密码存储需采用加盐哈希（如bcrypt），并设计合理的登录失败限流策略。同时，文章也提醒开发者关注会话管理（如HttpOnly、Secure标记的Cookie）和CSRF防护。这些细节直接关系到用户数据安全。作者通过具体案例说明，省略任何一个环节都可能导致账户被批量入侵。文章结尾强调，登录模块是安全架构的第一道门槛，值得开发者用更严谨的态度来设计和实现。

IT 累计浏览 5,887

HTTPS的七个误解

这篇讲的是HTTPS领域里那些广为流传却经不起推敲的说法。作者从日常开发调试观察HTTP通信的场景切入，指出尽管HTTPS已普及，但围绕它的认知误区依然大量存在。文章梳理了七个典型误解，比如“用了HTTPS就意味着网站绝对安全”、“HTTPS会导致性能严重下降”、“HTTPS证书需要昂贵费用”等。针对每个误解，作者都从技术原理和实际配置层面解释了为何这些观点不成立——例如，性能问题通过TLS 1.3和会话复用已极大改善，而Let’s Encrypt等服务让免费证书成为常态。它更像一份为开发者和运维人员准备的澄清清单，帮助大家跳出惯性思维，在安全与效率之间做出更合理的决策。读完你会明白，许多对HTTPS的担忧其实源于对配置细节的陌生，而非协议本身的缺陷。

IT 累计浏览 2,575

查看HTTP请求及HTTP响应的在线工具

这篇讲的是一个能让你在浏览器里直接窥探 HTTP 世界的小工具：web-sniffer。对于前端开发、接口联调或网络安全分析的同学来说，抓包是家常便饭，但本地安装配置工具总有些门槛。web-sniffer 提供了一个轻量的在线方案，只需输入网址，它就能模拟浏览器发起请求，并完整展示出请求头、响应头、状态码以及返回的正文内容。作者从实际开发中频繁需要调试 HTTP 交互的痛点出发，介绍了这款工具如何省去环境配置的麻烦，让查看 HTTP “情节”（即请求与响应全过程）变得像浏览网页一样简单。它尤其适合快速验证 API 返回数据、检查第三方请求是否携带了预期的 Header，或者临时排查线上资源的加载问题。尽管它不能替代本地专业抓包工具处理复杂场景，但其即开即用的特性，确实为日常的快速诊断提供了一个便捷入口。

IT 累计浏览 33,895

搜狐闪电邮箱的 Nginx/Postfix 使用模式

这篇讲的是搜狐闪电邮箱如何将 Nginx 反向代理的能力用到极致。文章从邮箱服务全面启用 HTTPS 这一动作切入，核心揭示了在这一架构转型中，Nginx 所扮演的“超级网关”角色——它不仅处理常规的 HTTP/HTTPS 流量，更被用来代理 POP(S)/IMAP(S) 等传统邮件协议，统一了各类 TLS 加密通信的入口。作者详细梳理了这一模式的实际应用效果：通过将所有协议层的连接与代理都交由 Nginx 处理，团队实现了架构的统一与管理的简化。这种设计让原本复杂的邮件协议安全加固（如全面 TLS 化）变得更为可控和集中。文章的亮点在于，它不仅展示了一个成熟互联网产品的基础设施演进案例，更点出了一个具有启发性的架构思路：利用高性能反向代理来整合和治理异构的协议流量。对于正在考虑服务架构统一化或面临多协议安全升级的团队来说，这篇分享提供了非常具体且已验证的参考路径。

IT 累计浏览 2,965

Browse+Identity=？

这篇讲的是，我们是否真的理解每天使用的浏览器？作者从一个看似简单的问题切入，挑战了将浏览器仅仅视为“获取信息的工具”这一普遍观点。他深入剖析了浏览器与用户网络身份之间那种常被忽视的共生关系。文章的核心洞察在于，现代浏览器远不止是访问网页的通道，它本身正在成为一个关键的“身份载体”。通过管理Cookie、存储登录状态、处理授权，浏览器实际上在持续地构建和维护用户在线的“身份画像”。作者将浏览器与身份的关系比喻为一个乘法算式（Browse × Identity），而非简单的相加。这意味着两者的结合产生了全新的特性：一个能记住你、理解你偏好、并在不同网站间保持一致体验的智能前端环境。从隐私管理到无密码登录，再到跨站点的个性化体验，文章列举了这种结合带来的具体变化。它引导我们思考，当我们谈论浏览器升级时，是否也该重新评估它作为数字身份核心基础设施的潜力与责任。