HTTPS——这个本应保护我们免受窃听和篡改的安全协议，却在不经意间成为了钓鱼攻击最强大的盟友。当浏览器地址栏中的那把"小锁"从"安全标志"变成"默认配置"时，它也从"可信信号"退化为了"无意义噪音"。钓鱼者不需要破解HTTPS，他们只需要获得一张SSL证书——而在今天，获得一张证书比获得一个电子邮箱还要容易。HTTPS的悖论在于：它成功地加密了数据传输，却未能加密用户的信任。
本节内容导航
一、SSL证书的诞生：从奢侈品到必需品
1994年，网景公司（Netscape）开发了安全套接层协议（SSL），旨在为互联网通信提供加密和身份验证。次年，SSL 2.0随网景导航者（Netscape Navigator）浏览器发布，标志着HTTPS时代的开端。然而，在最初的十年里，SSL证书是一种昂贵的"奢侈品"——一张标准的SSL证书年费在100美元至500美元之间，而扩展验证（Extended Validation，EV）证书的价格更是高达数千美元。
高昂的价格使得SSL证书成为"可信网站"的象征。在2000年代初期，只有大型企业和金融机构才会部署HTTPS——普通的小型网站几乎清一色使用HTTP。这种"HTTPS稀缺"的状态，使得地址栏中的"https://"和"小锁图标"成为了用户判断网站可信度的关键信号。当用户访问一个使用HTTPS的网站时，他们会本能地认为"这个网站是认真的、是专业的、是安全的"。
使用Netscape控制台管理服务器
钓鱼者很快意识到了这一心理机制的价值。2001年至2003年间，第一批使用HTTPS的钓鱼网站开始出现。攻击者通过购买廉价的SSL证书（或使用自签名证书），在钓鱼页面上启用HTTPS加密。对于用户来说，地址栏中的"小锁"消除了他们对"这个网站是否安全"的疑虑——他们输入的密码虽然被传输到了攻击者的服务器，但传输过程是"加密"的，因此是"安全"的。这种逻辑上的荒谬——"加密地泄露密码"——在当时却被大多数用户视为理所当然。
自签名证书是早期HTTPS钓鱼的一个常见手段。攻击者使用OpenSSL等工具自行生成SSL证书，无需经过任何证书颁发机构（CA）的验证。虽然自签名证书会在浏览器中触发安全警告（"此网站的安全证书不受信任"），但许多用户并不理解警告的含义，或者因为"警告疲劳"而习惯性地点击"继续"。更重要的是，一些早期的浏览器版本对自签名证书的处理不够严格——在某些情况下，用户甚至不会看到任何警告。
HTTPS普及率趋势（2015—2025）
数据来源：Google Transparency Report、Let's Encrypt 年度报告、HTTP Archive上图展示了2015年Let's Encrypt推出前后HTTPS普及率的急剧变化。2015年9月Let's Encrypt上线时，互联网上仅有约25%的页面加载使用HTTPS；到2025年，这一比例已超过95%。与此同时，使用HTTPS的网站数量从约3000万激增至超过3.8亿个。HTTPS从"安全标志"变为"默认配置"，小锁图标从"可信信号"退化为"无意义噪音"——这正是HTTPS悖论的核心：加密了数据，却未能加密信任。
二、绿色地址栏的幻觉：EV证书的兴衰
2007年，扩展验证（Extended Validation，EV）SSL证书正式推出。EV证书的申请流程远比普通SSL证书严格——CA需要对申请者的身份进行深度验证，包括核实公司的法律存在、物理地址、运营状态等。作为回报，使用EV证书的网站在浏览器地址栏中显示绿色的背景和公司名称（如"PayPal, Inc. [US]"）。
EV证书的设计初衷是美好的：通过更严格的身份验证和更醒目的视觉标识，帮助用户区分"真正的大公司"和"假冒的小网站"。在2007年至2012年间，EV证书被广泛宣传为"最高级别的安全保证"，各大银行和电商平台纷纷斥巨资购买EV证书，以向用户展示其"可信赖的身份"。
然而，EV证书的"绿色地址栏"很快成为了钓鱼者的新目标。攻击者发现，注册一个与目标公司相似的合法公司，然后以该公司名义申请EV证书，是一条可行的欺骗路径。例如，攻击者可以注册一家名为"PayPal Security Services LLC（贝宝安全服务有限责任公司）"的公司，然后以该公司名义申请EV证书。虽然公司名称与真正的PayPal不同，但对于不仔细查看地址栏文字的用户来说，"绿色地址栏"本身就是"安全"的信号——他们看到绿色，就放松了警惕。
支持EV SSL的浏览器，地址栏显示绿色的SSL证书
更进一步的，一些钓鱼攻击直接利用"绿色地址栏"的心理效应来增强欺骗效果。攻击者在钓鱼页面上使用EV证书，地址栏显示绿色和公司名称——虽然公司名称与目标品牌不同，但"绿色"本身足以让大多数用户产生"这个网站是安全的"错觉。研究表明，超过70%的用户在看到绿色地址栏时，会认为网站"绝对安全"，而只有不到10%的用户会仔细查看地址栏中显示的公司名称。
EV证书的衰落始于2017年。Google在Chrome 77中移除了EV证书的绿色地址栏显示，改为在点击地址栏时才显示证书信息。Mozilla在Firefox 70中也采取了类似的措施。这一变化的理由是：研究表明，EV证书对防止钓鱼攻击的效果极为有限——钓鱼者可以轻易地获得EV证书，而用户几乎不会注意到地址栏中的公司名称差异。2019年，Apple在Safari中完全移除了EV证书的专门显示。EV证书从"安全皇冠"退化为"普通证书"，标志着浏览器厂商对"视觉信任信号"的彻底反思。
三、Let's Encrypt：免费证书的福音与诅咒
2015年9月，一个名为"Let's Encrypt"的证书颁发机构正式推出。它的使命是简单而激进的：让互联网上的每一个网站都能免费获得SSL证书。用户只需运行一个简单的命令行工具（Certbot），即"证书机器人"，就可以在几分钟内获得一张有效期为90天的免费SSL证书，无需支付任何费用，无需经过人工审核。
Let's Encrypt的推出是互联网安全史上的一件大事。在不到两年的时间里，它成为了世界上最大的证书颁发机构，颁发的证书数量超过了所有传统CA的总和。截至2025年，Let's Encrypt已经为全球超过3亿个网站提供了免费证书，极大地推动了HTTPS的普及。从2015年到2025年，互联网上使用HTTPS的网站比例从约25%上升到超过95%——Let's Encrypt功不可没。
然而，Let's Encrypt的免费和自动化机制也为钓鱼攻击者提供了前所未有的便利。在Let's Encrypt之前，攻击者要获得SSL证书，需要支付费用、提供身份信息、等待人工审核——这些门槛虽然不高，但至少增加了攻击的成本和复杂性。Let's Encrypt之后，攻击者可以在几分钟内批量获得数百张SSL证书，成本为零，身份验证几乎为零。
使用Certbot手动续订SSL证书
2017年3月，安全研究者约瑟夫·奥戈尔曼（Joseph O'Gorman）和埃里克·奥尼尔（Eric O'Neill）发表了一项令人震惊的研究：Let's Encrypt已经向超过15,000个包含"PayPal"字样的钓鱼网站颁发了SSL证书。这些域名包括"paypa1.com"、"paypal-secure.com"、"paypal-verification.com"等——所有这些都是明显的钓鱼域名，但Let's Encrypt的自动化验证系统无法识别它们的欺骗性。研究指出，Let's Encrypt的域名验证（DV）流程只验证申请者是否控制该域名，而不验证域名的合法性或申请者的身份。这意味着，任何人只要控制了一个域名，无论这个域名的用途是什么，都可以获得SSL证书。
Let's Encrypt的回应是：SSL证书的本质是"加密"而非"信任"。证书的作用是确保数据在传输过程中不被窃听或篡改，而不是证明网站的所有者是"好人"。将"信任验证"的责任推给证书颁发机构，是一种错误的安全模型——真正的信任验证应该由浏览器、搜索引擎和用户教育来完成。Let's Encrypt的创始人乔什·阿斯（Josh Aas）在2015年的博客文章中明确表示："我们的任务是加密互联网，而不是审查互联网。"
这一立场在网络安全社区引发了激烈的争论。支持者认为，免费证书的普及是互联网安全的巨大进步——它使得HTTPS从"大公司的特权"变成了"所有人的标配"，从根本上提升了互联网的整体安全水平。反对者则认为，Let's Encrypt的"零门槛"政策使得钓鱼攻击者可以轻易地获得"可信"的加密连接，从而增强了钓鱼页面的欺骗性。当用户看到地址栏中的"https://"和"小锁"时，他们会本能地认为"这个网站是安全的"——即使这个网站实际上是一个钓鱼页面。
Let's Encrypt与钓鱼攻击的关键数据
- 推出时间：2015年9月
- 证书数量：截至2025年，已为超过3亿个网站颁发证书
- 钓鱼滥用数据：2017年研究发现，Let's Encrypt已向超过15,000个含"PayPal"的钓鱼域名颁发证书
- 验证方式：仅进行域名控制验证（DV），不验证申请者身份或域名合法性
- 证书有效期：90天，鼓励自动化续期
- 成本：完全免费
- 争议焦点：免费和自动化机制降低了钓鱼攻击者获取SSL证书的门槛
- 官方立场：SSL证书的职责是加密而非信任验证，信任验证应由浏览器和搜索引擎负责
Let's Encrypt "PayPal"钓鱼证书签发趋势（2016.03—2017.03）
数据来源：The SSL Store（基于crt.sh证书透明度日志数据分析）、AsiaCCS 2021学术论文2016年3月至2017年3月间，Let's Encrypt共签发了15,270张包含"PayPal"字样的SSL证书。研究者通过随机抽样分析发现，其中96.7%（约14,766张）被用于钓鱼网站。2017年2月单月签发量突破5,000张，日均超过100张。学术研究进一步证实，91.6%的钓鱼滥用证书来自Let's Encrypt和cPanel等免费自动化CA，而商业CA仅占8.4%。这并非否定Let's Encrypt的价值——它确实推动了HTTPS的普及——但它也揭示了"零门槛加密"与"信任验证"之间的根本矛盾。
四、CloudFlare的Universal SSL：安全与便利的边界
CloudFlare在2014年推出的通用SSL（Universal SSL）服务，进一步模糊了"安全"与"可信"之间的边界。CloudFlare是全球最大的CDN和网络安全服务提供商之一，为数百万个网站提供加速和安全保护。通用SSL的核心承诺是：任何使用CloudFlare服务的网站，无论付费还是免费，都可以自动获得SSL证书。
CloudFlare的SSL证书颁发机制与Let's Encrypt类似——自动化、零成本、无需人工审核。但CloudFlare更进一步：它不仅为网站所有者提供证书，还充当了"中间人"的角色。当用户访问一个使用CloudFlare的网站时，用户的浏览器与CloudFlare的服务器建立HTTPS连接，然后CloudFlare再与网站的原始服务器建立连接（可能是HTTP或HTTPS）。这意味着，用户看到的SSL证书实际上是CloudFlare的证书，而不是网站原始服务器的证书。
这种"中间人"架构在技术上是有道理的——它使得CloudFlare可以对流量进行缓存、优化和安全过滤。但它也带来了一个安全问题：用户无法直接验证网站原始服务器的身份。如果CloudFlare的某个客户是一个钓鱼网站，用户看到的仍然是CloudFlare颁发的"有效"SSL证书，地址栏显示"安全"——即使原始服务器实际上是一个恶意网站。
2015年，Netcraft的一项调查揭露了CloudFlare SSL证书被滥用的严重程度。调查发现，多家证书颁发机构（包括CloudFlare）向已知的钓鱼网站颁发了SSL证书。一些钓鱼网站甚至获得了扩展验证（Extended Validation，EV）证书——最高级别的身份验证证书。Netcraft指出，证书颁发机构的验证流程存在系统性漏洞，使得钓鱼攻击者可以轻易地绕过身份检查。
CloudFlare对此的回应是加强了对恶意网站的检测和处置。当CloudFlare发现某个客户网站从事钓鱼或恶意活动时，会立即终止服务并报告给相关机构。然而，这种"事后处置"模式始终存在时间差——钓鱼网站可以在被封锁之前运行数小时甚至数天，而在这段时间内，它已经可能窃取了数百个用户的凭证。
五、证书颁发机构的信任危机
SSL/TLS体系的安全基础是"信任链"——浏览器内置了一组受信任的根证书颁发机构（Root CA），这些CA颁发的证书被浏览器自动信任。然而，这一体系的脆弱性在2011年的一次事件中暴露无遗。
2011年3月，荷兰证书颁发机构迪吉诺塔（DigiNotar）的服务器被黑客入侵，攻击者伪造了包括Google、Yahoo、Microsoft等在内的数百个知名网站的SSL证书。这些伪造证书在数周内被用于对伊朗用户的中间人攻击——攻击者可以拦截和窃听用户与这些网站之间的加密通信。DigiNotar事件震惊了整个互联网安全社区，它证明了：即使是最受信任的CA，也可能成为攻击者的突破口。
迪吉诺塔事件之后，Google、Mozilla和Microsoft迅速将迪吉诺塔的根证书从浏览器中移除。迪吉诺塔在事件发生后数周内宣布破产，成为第一家因安全事件而倒闭的CA。然而，迪吉诺塔事件揭示的问题远比迪吉诺塔本身更为深远：整个CA体系建立在"信任少数几个机构"的基础上，而这些机构中的任何一个被攻破，都会导致全球范围内的信任崩塌。
2011年3月15日，另一家CA——Comodo（科莫多）——也遭遇了类似的入侵事件。攻击者伪造了包括Google、Yahoo、Microsoft、Skype等在内的多个网站的SSL证书。虽然科莫多及时发现并撤销了这些伪造证书，但事件再次敲响了警钟：CA体系的安全依赖于"每个CA都绝对安全"——这是一个几乎不可能实现的前提。
为了应对CA信任危机，安全社区提出了多种解决方案。"证书透明度"（Certificate Transparency，CT）是其中最重要的一项。CT要求所有CA在颁发证书时，必须将证书信息记录到一个公开的、不可篡改的日志中。这使得安全研究者和浏览器厂商可以实时监控证书的颁发情况，及时发现异常的证书颁发行为。Google从2013年开始强制要求所有EV证书必须被记录到CT日志中，2018年进一步扩展到所有DV证书。
然而，CT并不能解决根本问题——它只能让伪造证书更容易被发现，而不能阻止伪造证书的产生。只要CA体系仍然依赖于"信任少数机构"的模型，它就始终存在单点故障的风险。一些安全研究者提出了更为激进的替代方案，如"去中心化身份验证"（基于区块链）或"基于DNS的命名实体身份验证"（DANE），但这些方案距离大规模部署仍有很长的路要走。
证书颁发机构（CA）信任危机事件
数据来源：ACM Queue、Fox-IT DigiNotar报告、Google Security Blog、Mozilla安全公告2011年是CA信任体系的"灾年"。Comodo在3月遭遇入侵，攻击者伪造了9张针对Google、Yahoo、Skype等顶级域名的证书；DigiNotar在8月被完全攻破，531张伪造证书被签发，其中一张*.google.com的通配符证书被用于对伊朗30万Gmail用户的大规模中间人攻击。DigiNotar因隐瞒事件超过两个月而遭到所有主流浏览器永久取消信任，最终破产倒闭——这是CA史上第一家因安全事件而倒闭的机构。此后TürkTrust（2011）、NICCA（2014）、CNNIC（2015）和Symantec（2015-2017）相继爆出证书滥用事件，每一次都在动摇整个PKI信任体系的根基。
六、HTTPS钓鱼的真实案例
HTTPS钓鱼的案例数量庞大，以下选取几个具有代表性的案例，以展示HTTPS钓鱼的多样性和危害性。
案例一：2017年PayPal钓鱼浪潮
2017年，安全研究者发现了一波大规模针对PayPal用户的HTTPS钓鱼攻击。攻击者注册了数百个包含"PayPal"字样的域名，使用Let's Encrypt颁发的免费SSL证书搭建钓鱼页面。这些页面在外观上与PayPal官方网站几乎完全一致，地址栏显示"https://"和"小锁"图标。攻击者通过钓鱼邮件将用户引导至这些页面，邮件中的链接文字显示为"https://www.paypal.com"，但实际指向的是"https://paypa1-secure.com"等钓鱼域名。由于使用了HTTPS，许多用户完全没有怀疑页面的真实性。据估计，这波攻击在数周内窃取了数千个PayPal用户的凭证。
案例二：2019年Office 365钓鱼攻击
2019年，微软Office 365成为HTTPS钓鱼的主要目标。攻击者利用Microsoft Azure的免费试用期，在Azure上搭建与Office 365登录页面完全一致的钓鱼网站。由于Azure默认提供SSL证书，这些钓鱼网站自动获得HTTPS加密。攻击者通过发送伪造的"SharePoint文档共享"邮件，诱导用户点击链接并输入Office 365的登录凭证。由于钓鱼页面托管在Microsoft自己的云服务上，一些安全过滤器甚至不会将其标记为可疑。这波攻击影响了全球数千家企业，包括多家财富500强公司。
案例三：2020年COVID-19主题HTTPS钓鱼
2020年新冠疫情期间，HTTPS钓鱼攻击呈现爆发式增长。攻击者利用人们对疫情信息的迫切需求，搭建了大量伪造的"政府卫生部门""疫苗预约平台""疫情补助申请"等钓鱼网站。这些网站全部使用Let's Encrypt或CloudFlare的免费SSL证书，地址栏显示"安全"。一项研究显示，2020年3月至6月间，使用HTTPS的新注册钓鱼域名数量同比增长了超过300%。"疫情恐慌"与"HTTPS信任"的结合，使得这波攻击的成功率异常之高。
七、用户认知的陷阱："有锁就是安全"
HTTPS钓鱼之所以能够成功，根本原因在于用户对HTTPS的误解。大多数用户将地址栏中的"小锁"视为"这个网站是安全的"的信号，而不是"这个连接是加密的"的技术指示。这种认知偏差是钓鱼攻击者最乐于利用的弱点。
多项用户研究证实了这一认知陷阱的存在。2017年，Google进行的一项大规模用户调查发现，超过70%的用户认为"HTTPS网站是安全的"，而只有不到20%的用户理解"HTTPS只保证加密，不保证网站内容的真实性"。更令人担忧的是，约30%的用户表示，他们在看到"小锁"时会"更放心地输入密码"——即使他们对这个网站本身并不熟悉。
这种认知偏差部分源于浏览器厂商早期的安全宣传。在HTTPS普及的初期，浏览器厂商大力宣传"HTTPS = 安全"，以鼓励网站所有者部署加密。这种宣传虽然有效地推动了HTTPS的普及，但也无意中塑造了用户的错误认知。当HTTPS从"稀缺资源"变成"默认配置"时，"小锁"的含义也应该从"这个网站很特别"转变为"这个连接是加密的"——但这种认知转变并未发生。
浏览器厂商在2018年之后开始调整策略。Chrome 68（2018年7月）开始将所有HTTP网站标记为"不安全"，而不是将HTTPS网站标记为"安全"。Chrome 77（2019年9月）移除了地址栏中的"安全"标签，只保留"小锁"图标。这些变化的意图是：将"HTTPS"从"加分项"转变为"默认项"，从而消除"有HTTPS = 特别安全"的认知偏差。然而，这些改变的效果仍然有限——"小锁"图标本身仍然携带着强烈的"安全"暗示，而大多数用户并不会注意到浏览器的细微UI变化。
八、HTTPS Everywhere之后：信任的重新定义
2010年代末期，互联网安全社区达成了一个共识：HTTPS应该成为所有网站的默认配置。Google、Mozilla、Microsoft和Apple共同推动"HTTPS Everywhere（无处不在的HTTPS）"运动，通过浏览器政策、搜索引擎排名激励和技术工具，加速HTTPS的普及。到2025年，超过95%的网页加载使用HTTPS，HTTP几乎被完全淘汰。
HTTPS Everywhere的成功带来了一个意想不到的后果：HTTPS从"安全信号"变成了"基础信号"。当几乎所有网站都使用HTTPS时，HTTPS本身就不再是判断网站可信度的依据——它只意味着"数据传输是加密的"，而不意味着"这个网站是合法的"。这种"信号贬值"使得钓鱼攻击者可以更加肆无忌惮地使用HTTPS——因为HTTPS不再是"可疑的加分项"，而是"必备的入场券"。
Google Chrome68的网站不安全警告
面对这一现实，安全社区开始重新思考"信任"的定义。一些研究者提出，未来的信任模型应该基于"多维信号"而非单一指标：除了HTTPS之外，还应该考虑域名的注册历史、网站的内容质量、用户的行为模式、第三方安全评级等多个维度。Google的安全浏览系统（Safe Browsing）和Microsoft的智能屏幕过滤器（SmartScreen），已经开始采用这种"多维信任评估"模式——它们不仅检查URL是否在黑名单中，还分析页面的内容、行为模式和用户反馈，以综合判断网站的可信度。
另一种思路是"去中心化信任"。区块链技术使得"无需信任第三方机构"的身份验证成为可能。一些实验性的项目（如Handshake、ENS）正在探索基于区块链的域名系统，其中域名的所有权和信任关系由分布式共识机制维护，而不是由中心化的CA控制。然而，这些技术距离大规模应用仍有很长的路要走，而且它们本身也面临着新的安全挑战。
HTTPS的悖论最终指向一个更深层的问题：在数字时代，"信任"究竟应该建立在什么基础之上？是技术协议（如HTTPS）、是机构背书（如CA）、是群体共识（如用户评价）、还是某种我们尚未发明的新机制？这个问题没有简单的答案，但HTTPS的历史告诉我们：任何单一的技术解决方案，都不足以承载"信任"这个如此复杂、如此人性、如此脆弱的概念。
"Let's Encrypt让我们加密了互联网，但也让我们加密了欺骗。当每一把锁都看起来一样时，锁本身就不再是安全的保证。HTTPS解决了'数据在传输过程中是否被窃听'的问题，但它无法解决'用户是否在被欺骗'的问题。后者不是一个技术问题，而是一个关于人性、关于认知、关于信任的永恒命题。" —— 引自网络安全研究者Troy Hunt在2017年的演讲
延伸阅读与参考
- "Let's Encrypt Has Issued Certificates to Over 14,000 PayPal Phishing Sites." The SSL Store, June 11, 2021. 详细分析Let's Encrypt证书被钓鱼攻击滥用的数据。
- "Let's Encrypt Issues 15,000 Fraudulent 'PayPal' Certificates Used for Cybercrime." SecurityWeek, March 27, 2017. 包含Let's Encrypt issued 15,270个含"PayPal"的SSL证书的分析。
- "Certificate Authorities Issue SSL Certificates to Fraudsters." Netcraft, October 12, 2015. 包含CloudFlare等CA向钓鱼网站颁发SSL证书的调查数据。
- "The CA's Role in Fighting Phishing and Malware." Let's Encrypt, October 29, 2015. Let's Encrypt官方关于证书颁发与钓鱼攻击的立场声明。
- "DigiNotar Files for Bankruptcy in Wake of Devastating Hack." PCWorld, September 20, 2011. DigiNotar因安全事件倒闭的详细报道。
- "Comodo Hacker Claims Credit for DigiNotar Attack." Threatpost, September 5, 2011. Comodo和DigiNotar CA入侵事件的关联分析。
- "Google's Safe Browsing: Protecting Users from Phishing and Malware." Google Security Blog. Google Safe Browsing系统的技术介绍和统计数据。
- "Certificate Transparency: Monitoring and Auditing Certificates." Google Transparency Report. 证书透明度（CT）日志系统的技术说明。
- "HTTPS Everywhere: Encrypting the Entire Web." Electronic Frontier Foundation. HTTPS普及运动的历史和影响分析。
- "The History of Phishing." Kaseya, March 10, 2026. 钓鱼攻击历史的系统性回顾，涵盖HTTPS钓鱼的关键节点。