3. HTTP 攻击防御

TLS Transport Layer Security

在传输层中 tcp 协议并不能保证信息的 confidentiality, integrity, authenticity 因此在传输层和应用层之间加了一层专门用来保护安全的协议

tls 协议假设用户端和服务器端是安全的，而沟通信道 network 是危险的 (malicious) 并且在网络上有两种攻击模式:

passive: only eavesdrops
active: can see inject modify or block

TLS 功能

confidentiality and integrity protection for app data
client 可以确保服务器的身份 (authenticate)

无法做到

用户端/服务器内病毒
应用软件本身脆弱性
社会工程学等信息泄漏
浏览记录、网页元数据分析
Denial of Service (DoS) 攻击

发展历史

现代 tls 拥有超过 30 年的研制历史

TLS 握手机制

用户端向服务器提供可以使用的安全算法, 服务器选择一个并且返回
客户端和服务器交换密钥，使用 DH 密钥交换算法
给所有握手信息添加一个 hash 加密, 并且用 private key 签名

TLS 握手流程

如下图所示，tls 两端的信息通过最小时间延迟来进行通信，其中用户会猜测服务器选择哪个交换算法并且提前准备好估算方法，如果猜错了则后续会重新发送一个 RTT 的新共享密钥

X.509 证书

用户端如何获得服务器的公钥呢？服务器会使用一个证书来说明: 一个信息来表明 server 的身份和它的密钥，通过 certificate authority (CA) 来签名

每一个 ca 证书都是一个被用户端信任而用来验证服务器身份的实体
每一个大型平台和浏览器都会包含一系列信任的 CA 证书和对应的公钥，这些称为 root CAs, 用户端使用这些密钥来验证身份, TLS 使用的是 X.509 验证格式

获取证书

一个服务器如果想要获取一个证书，必须要向 CA 证明其身份，简单的身份验证方式有:

HTTP (在域名下的某个特定路径放置一个包含验证码的文件);
DNS (在域名 dns 服务器下添加一个记录来保存对应网站的验证码)
email (在指定邮箱内收到验证码来说明其属于哪个域名)

在上图中的交流机制中，分为两个阶段:
第一阶段是证书签发 (Certs Issuance), 即服务器向 CA 发送自己的公钥并且和 CA 实现公钥交换 (这一步包含了向 CA 证明自己的地址身份); 然后CA 验证信息之后使用 private key 签名服务器的公钥; 服务器存储来自 CA 的证书并且可以迎接用户.
第二阶段是证书使用阶段 (Certs Use), 即当客户端向服务器发起连接请求的时候，服务器发送一个证书到 Client, 并且等待客户端验证了签名 (客户端有 CA 的公钥)并且从服务器获得了服务器公钥
注意在日常客户端-服务器交互过程中并不存在 CA 的干扰和影响(这样不会影响整个交互的速度)

ACME

这是一个开源协议，由 Let’s Encrypt 协会设计，将这些过程可以自动化实现 (ACME=Automatic Certificate Management Environment)

证书链条 Certificate Chains

CA 有时候会发出中间CA证书来进行更多的验证，来代表信任给其他小 CA 机构
并且可以使用和长时期保存在本地的 root key 分离的密钥，防止 root 密钥被攻击，用户验证的时候也是逐层进行检验，直到找到 root 的验证 (是本地存储的可以直接验证的)

Public Key Infrastructure (PKI)

在网络中会存储一系列的 CA, 由一个大组织管理，该组织包含成员来自:

CA 协会
浏览器/平台开发者
CA/Broswer 论坛

You Connection is not Private 警告

可能的原因有四种:

Certificate has expired
写在 url 中的域名不属于任何拥有证书的域名
证书验证链不能回到一个可以信任的 root CA
CA 将证书给吊销了 (revoke)
使用 ACME 的自动化流程可以帮助 server 避免这种 warning

HTTPS 攻击

Fooling Users: Homograph

使用一个视觉相似的域名来欺骗用户，简单且有效

IDN homograph attack

使用非英语字符进行基本一致的非同义攻击
浏览器会使用 punycode (ascii) 来转义文字来防止这类攻击

Fooling Users: SSL Stripping

这里利用了安全访问机制: 一般浏览器会率先向一个 url 采用 https 进行发送，但是如果失败就改用 http 协议，除非对应网址强制要求 https 协议
MITM 模型利用该机制，首先主动阻挡用户发送 https 请求，将用户发送的 http 协议请求 (不够安全) 加装一层本地的 https 协议之后再次发送给服务器并且将收到的 html 修改之后转发给客户端

Mitigation 缓解措施: HSTS (HTTP Strict Transport Security)

服务器发送一个特殊的 HTTP 表头 Strict-Transport-Security: max-age=... 这里浏览器会只使用 https 来访问对应的域名并且持续 max-age seconds 并且拒绝 bypass certificate error (指忽略 CA cert 错误直接访问的方法)
对于第一次访问某个域名的用户，由于对应网站并没有存储HSTS的记录，因此更加容易被攻击; 对应域名可以使用 hsts preload list (来自浏览器内置)

Fooling Users: Phishing 网络钓鱼攻击

攻击者伪装成常用的网站

Mitigation: Google Safe Browsing

利用 ML 来识别危险的网址并且警告用户
类似的反钓鱼身份验证方式例如 WebAuthN 和 passkey
这些需要3种特性:

Non-forwardability (不可转发性): 每次验证码只能使用一次且只能给创造者验证
origin binding: 这个验证码只能在请求的网站里面使用
channel binding: 这个验证码只能在使用过的物理设备上登录

Web 设计要求

Mixed Content

在一个 https 网页下可能有些资源是来自 http 的，因此需要强制所有的资源都使用 https 协议

Cookies 泄漏

默认条件下通过 https 发送的协议其中的 cookies 是不会进行加密的，由于从 https 上设置的协议的安全性并不能保证到 http 传输过程
需要给 cookie 设一个 Secure 属性, 来确保只通过 https 协议发送

HTTPS 信息泄漏

https 本身具有网站的一般信息，其中 tls 在用户端建立连接数据包中会发送 Server Name Indication (SNI) 来告诉服务器其需要连接的网站对象以便获得 TLS 信息
需要使用 CPN 或者 Tor 来防御，或者给用户连接请求进行加密 Encrypted Client Hello

CA Weakness: Fooling Validation

攻击者可以欺骗 CA 协会来获得一个合法的 TLS 证书并且制作成钓鱼网站
防御方式:

CAA (Certificate Authority Authorization): 域名持有者可以指定哪些 CA 证书可支持本网站，并且制作了一个 DNS 记录 (因为只有domain持有者才能掌控DNS服务器信息)
禁止一般用户申请类似 administrator 等名字的邮件以确保类似的验证邮箱名都归属于官方所有防止滥用
多个视角: CA 不止会从一个数据中心验证域名，而是通过多个数据中心共同验证, 从而防止单个数据中心被挟持的问题

2.1.1 Homograph攻击（同形异义字攻击）

原理：利用视觉相似的域名欺骗用户（如国际字符IDN）。
- 示例：使用西里尔字母伪装“apple.com” → “аpple.com”。
- 攻击流程：
  1. 攻击者注册视觉相似的域名。
  2. 申请合法证书。
  3. 搭建钓鱼网站。
- 缓解措施：
  - 浏览器使用Punycode编码显示国际化域名。
  - 用户警惕非预期域名。

2.1.2 SSLStrip攻击（HTTPS降级攻击）

原理：中间人（MITM）强制用户从HTTPS回退到HTTP。
- 攻击流程：
  1. 用户输入“bank.com”（未显式指定HTTPS）。
  2. MITM劫持请求，返回HTTP响应。
  3. 用户会话通过未加密通道传输。
- 缓解措施：
  - HSTS（HTTP严格传输安全）：
    - 服务器发送Strict-Transport-Security头，强制浏览器仅使用HTTPS。
    - 首次访问问题：通过HSTS预加载列表（如hstspreload.org）。

2.1.3 钓鱼攻击

问题：HTTPS无法阻止钓鱼(多数钓鱼网站有合法证书)
- 示例：伪造亚马逊登录页(https://amzn.step412.top)
- 缓解措施：
  - 抗钓鱼认证技术（如WebAuthN/Passkeys）：
    1. 不可转发性：凭据仅限创建者使用。
    2. 源绑定：凭据仅限特定域名。
    3. 通道绑定：凭据与物理设备绑定。
  - Google Safe Browsing：基于机器学习识别危险网站并警告用户。

2.2.1 混合内容（Mixed Content）

原理：HTTPS页面加载HTTP资源（如图片、脚本）。
- 风险：HTTP资源可被篡改或泄露数据。
- 缓解措施：
  - 所有资源使用HTTPS。
  - 设置Cookie的Secure属性（仅通过HTTPS传输）。

2.2.2 TLS隐私泄露

问题：TLS协议暴露域名信息（如SNI头）。
- 风险：网络审查或监控。
- 缓解措施：
  - 使用Tor或VPN隐藏流量。
  - 加密客户端Hello（ECH）：新兴标准，隐藏SNI信息。

2.3.1 CA验证漏洞

攻击类型：
- 邮件验证攻击：攻击者伪造管理员邮箱（如admin@umich.edu）获取证书。
- HTTP验证攻击：MITM劫持CA的HTTP验证请求。
缓解措施：
- 多视角验证（Multi-Perspective Validation）：CA从多个网络位置发起验证，增加攻击难度。
- CAA记录：通过DNS记录限制可颁发证书的CA（如umich.edu. IN CAA 0 issue "Letsencrypt.org"）。

2.3.2 CA被攻击的历史案例

案例：2011年DigiNotar被黑，攻击者获取*.google.com证书。
- 后果：证书被用于伊朗的MITM攻击，CA最终破产。
缓解措施：
- 证书吊销列表（CRL）：CA定期发布被吊销证书列表。
- 证书透明度（Certificate Transparency, CT）：
  - 所有证书需记录在公开日志（CT Log）中。
  - 服务器可监控日志，检测非法证书。

2.4 TLS实现中的漏洞

2.4.1 Apple Goto Fail（2014）

问题：因代码中多余的goto语句跳过证书验证。
- 代码片段：
  1
  2
  3
  if (err) { goto fail; }
  goto fail; // 冗余语句
  fail: // 直接跳转，未执行后续验证
- 后果：近一年内所有Apple设备易受MITM攻击。
- 缓解：形式化验证（如miTLS库）。

2.4.2 OpenSSL Heartbleed（2014）

原理：心跳扩展未验证输入长度，导致内存泄漏。
- 后果：泄露私钥、密码等敏感数据（影响24-55%的HTTPS网站）。
- 缓解：
  - 更新OpenSSL版本。
  - 使用内存安全语言编写的TLS库（如Rust）。

2.5 TLS协议漏洞（版本<1.3）

2.5.1 加密算法弱点

RC4攻击：流密码偏差泄露Cookie/密码。
CBC攻击：BEAST/POODLE利用块填充漏洞。
导出级加密：旧版TLS支持弱密钥（如512位RSA），被FREAK/Logjam攻击利用。

2.5.2 TLS压缩攻击（CRIME）

原理：通过压缩数据长度推测明文内容。
- 示例：通过观察加密后长度，逐步泄露Cookie值。
- 缓解：禁用TLS压缩。

2.6 服务器漏洞与密钥管理

风险：私钥泄露（文件权限错误、未加密备份）。
- 案例：Pastebin上泄露的私钥可被用于伪造服务器。
缓解措施：
- 严格访问控制与隔离。
- 私钥泄露后立即吊销证书。
- 使用工具（如SSL Labs）测试服务器配置。

7. 防御技术总结

攻击类型	防御措施
用户欺骗	HSTS、抗钓鱼认证、Safe Browsing
CA弱点	证书透明度、多视角验证
TLS漏洞	升级至TLS 1.3、禁用弱加密算法
服务器配置	定期扫描（SSL Labs）、密钥隔离