Caddy服务器中关于无SNI请求的TLS处理机制解析

Caddy作为一款现代化的Web服务器，其TLS处理机制一直是其核心优势之一。在最新版本中，开发者们针对无SNI(Server Name Indication)的TLS请求处理进行了深入讨论和功能增强。

问题背景

在实际部署场景中，特别是当Caddy位于AWS NLB(网络负载均衡器)后方时，会遇到一个特殊现象：当客户端直接通过NLB的公共IP地址发起HTTPS请求而不提供SNI信息时，Caddy的on_demand_tls功能会向配置的ask端点查询服务器自身的内部IP地址，而非客户端实际访问的公共IP。

技术原理分析

这种现象源于TLS协议和网络架构的基本原理：

1. SNI机制：TLS握手过程中，客户端通过SNI扩展告知服务器它要连接的主机名。当客户端直接通过IP地址访问时，通常不会提供SNI信息。

2. 网络拓扑影响：当Caddy位于负载均衡器后方时，它只能看到负载均衡器的内部IP地址，无法感知客户实际访问的公共IP。

3. 默认行为：在没有SNI的情况下，Caddy会使用连接的目标IP地址(即服务器自身IP)作为证书请求的域名。

安全考量

这种默认行为可能带来一些安全隐患：

1. 潜在滥用风险：恶意用户可以通过扫描公共IP地址，强制Caddy向ask端点发起大量查询请求。

2. 证书管理：对于仅需处理域名请求的场景，为IP地址签发证书可能不符合安全策略。

解决方案演进

Caddy开发团队针对这一问题提供了多种解决方案：

1. ask端点过滤：建议在ask端点实现快速过滤逻辑，立即拒绝不符合预期的域名模式。

2. 权限插件：从v2.8.0-beta.1开始，开发者可以编写自定义的permission模块替代ask端点，实现更快速的过滤逻辑。

3. 新增drop选项：最新提交中增加了直接丢弃无SNI请求的功能，可通过JSON配置实现：

{
  "apps": {
    "http": {
      "servers": {
        "your_server": {
          "tls_connection_policies": [
            {
              "drop": true
            }
          ]
        }
      }
    }
  }
}

最佳实践建议

对于不同场景下的部署建议：

1. 公共Web服务：建议启用drop选项，仅接受带有有效SNI的TLS连接。

2. 内网环境：如需支持IP证书，可保留默认行为，但应在ask端点实现严格的访问控制。

3. 混合环境：可通过tls_connection_policies精细控制不同连接策略下的行为。

总结

Caddy对无SNI请求的处理机制体现了其在安全性和灵活性之间的平衡。随着drop选项的引入，管理员现在可以更精确地控制TLS握手行为，适应各种复杂的部署场景。理解这些底层机制有助于构建更安全、高效的Web服务架构。