9. 安全考虑
9.1. 变更端口
使用替代服务至少意味着会在替代端口上访问某个源的资源. 因此, 如果攻击者能够注入替代服务并在被宣告的端口上监听, 就能够劫持该源. 在某些服务器上, 用户能够控制共享端口上可用的一些个人页面, 同时也能够在较低权限要求的端口上接受请求, 这是常见情况.
例如, 如果攻击者能够向某些页面添加 HTTP 响应头字段, 就可以使用 Alt-Svc 头字段将整个源的流量重定向到同一主机上的另一个端口; 如果该端口受攻击者控制, 攻击者就可以伪装成 HTTP 服务器.
第 2.1 节中的要求缓解了这一风险.
在服务器侧, 还可以通过限制宣告替代服务的能力, 以及限制谁可以在该主机上打开端口进行监听, 来降低这一风险.
9.2. 变更主机
当使用替代服务导致主机发生变化时, 攻击者就有机会劫持到某个源的通信.
例如, 如果攻击者能够成功将 "evil.example.com" 关联为替代服务, 使用户代理把发往 "innocent.example.org" 的所有流量发送到 "evil.example.com", 攻击者就可以伪装成该源. 这可以在本地完成 (缓解措施见第 9.1 节), 也可以远程完成, 例如由中间方实施中间人攻击.
这正是第 2.1 节要求客户端获得合理保证的原因: 替代服务必须受整个源控制并对整个源有效. 例如, 出示该源的证书可以证明替代服务被授权为该源处理流量.
注意, 这种保证的强度只取决于用于认证替代服务的方法. 特别是使用 TLS 认证时, 已知存在一些利用方式可使攻击者的证书看起来是合法的.
替代服务还可能被用来维持这种攻击. 例如, 中间方可以对目标的 TLS 保护通信实施中间人攻击, 然后将所有流量指向一个新鲜生命周期很长的替代服务, 使用户代理即使不再经过该中间方, 仍然把流量发送给攻击者.
实现必须 (MUST) 像处理到源的直接连接一样, 对替代服务执行任何证书固定 (certificate pinning) 校验, 例如 [RFC7469]. 实现还可以选择增加其他要求, 规定哪些证书可被替代服务接受.
9.3. 变更协议
当使用替代服务导致 ALPN 协议发生变化时, 到源的新连接的安全属性可能不同于到该源的"正常"连接, 因为协议标识符本身就隐含了这种差异.
例如, 如果某个 "https://" URI 宣告的协议不使用某种形式的端到端加密 (最可能是 TLS), 这就违反了该 URI 方案所隐含的安全预期. 因此, 客户端不能盲目使用替代服务, 而应评估所提供的选项, 确保满足规范、实现和最终用户的安全要求与预期.
9.4. 使用替代服务跟踪客户端
选择替代服务意味着连接到一个由服务器提供的新主机名. 服务器可以通过使用唯一名称来跟踪客户端请求. 当使用 "persist" 标志时, 这种跟踪甚至可能跨多个网络跟随用户.
希望防止请求被关联的客户端可以决定不为多个请求使用替代服务, 尤其是这些请求在其他情况下本不允许被关联时.
在用户代理中, 当清除特定于源的数据时, 必须 (MUST) 删除任何替代服务信息. 典型情况是清除 cookie [RFC6265] 时.
9.5. 关于请求方案的混淆
一些服务器端 HTTP 应用会基于连接上下文对安全性作出假设; 例如, 将通过端口 443 提供服务等同于使用 "https://" URI 及其隐含的各种安全属性.
这不仅影响连接本身的安全属性, 也影响连接另一端客户端的状态. 例如, Web 浏览器在许多方面都会以不同方式处理 "https://" URI 和 "http://" URI, 并不只是协议处理不同.
由于替代服务的用途之一是允许连接迁移到不同协议和端口, 这些应用可能会对给定连接的安全属性产生混淆, 从而把本应发送到安全上下文 (例如 "https://" URI) 的信息 (例如 cookie 和内容) 发送给并未将其视为安全上下文的客户端.
服务器可以通过使用协议显式携带的 URI 方案作为安全上下文指示来缓解这一风险, 而不是依赖其他连接属性. 例如, HTTP/2 中的 ":scheme", 或 HTTP/1.1 中请求目标的 "absolute form" ([RFC7540] 第 8.1.2.3 节和 [RFC7230] 第 5.3.2 节).
当协议没有显式携带方案时 (HTTP/1.1 over TLS 通常如此), 服务器可以通过两种方式缓解这一风险: 假定所有请求都处于不安全上下文, 或避免为不安全方案 (例如 HTTP) 宣告替代服务.