跳到主要内容

RFC 2818 - 基于 TLS 的 HTTP (HTTPS) - 3. 端点识别 (Endpoint Identification)

3. 端点识别 (Endpoint Identification)​

3.1. 服务器身份 (Server Identity)​

核心要求: 客户端 MUST 验证服务器身份, 以防止中间人攻击 (man-in-the-middle).

身份验证过程 (Identity Verification Process)​

1. 客户端从 URI 中获取主机名
   例如: https://www.example.com

2. 服务器在 TLS 握手期间提供证书

3. 客户端检查主机名是否与证书中的身份匹配

身份字段优先级 (Identity Field Priority)​

优先级 1: subjectAltName (主题备用名称)

证书中的 subjectAltName 扩展 (dNSName 类型):
dNSName: www.example.com
dNSName: api.example.com

← MUST 使用此字段 (如果存在) →

优先级 2: Common Name (通用名称)

证书 Subject 字段中的 CN:
CN=www.example.com

← 仅在不存在 subjectAltName 时使用 →
← 已弃用, CA 应当使用 dNSName →

匹配规则 (Matching Rules)​

1. 通配符匹配 (Wildcard Matching):

证书: *.example.com
✅ 匹配: foo.example.com
❌ 不匹配: bar.foo.example.com

证书: f*.com
✅ 匹配: foo.com
❌ 不匹配: bar.com

2. IP 地址:

URI: https://192.168.1.1/
证书必须包含: iPAddress subjectAltName
值必须完全匹配: 192.168.1.1

3. 多个身份:

如果证书包含多个 dNSName:
- www.example.com
- api.example.com
- *.app.example.com

← 匹配其中任何一个都是可以接受的 →

未匹配时的行为 (Behavior When No Match)​

面向用户的客户端 (如浏览器):

  • ✅ MUST 通知用户
  • ⚠️ MAY 允许用户选择是否继续连接
  • 或者终止连接

自动化客户端 (如 API 客户端):

  • ✅ MUST 将错误记录到审计日志中
  • ✅ SHOULD 终止连接
  • ⚠️ MAY 提供配置选项来禁用此检查

安全警告 (Security Warning)​

不可信的 URI 来源:

攻击场景:
1. 用户点击 HTTP 页面中的链接
2. HTTP 页面本身是未加密的
3. 中间人可能已经替换了该 URI

防护措施:
用户应当仔细检查服务器证书

3.2. 客户端身份 (Client Identity)​

典型情况: 服务器通常没有关于客户端身份的外部已知信息.

如果服务器具备外部已知信息 (来自 HTTP 或 TLS 之外):

  • 应当按照上述方式检查身份

客户端证书认证:

常见场景:
- 企业内部系统
- API 访问控制
- Mutual TLS (双向 TLS, mTLS)

验证:
- 证书链植根于适当的 CA
- 可选: 验证特定的客户端身份