Caddy完整指南：启用ECH加密SNI保护隐私

Caddy完整指南启用ECH加密SNI保护隐私【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddyCaddy跑站的站长总不想让运营商看清用户连的哪个域名。ECH加密客户端问候把TLS握手中明文外泄的SNI服务器名称指示即浏览器告诉服务器找谁的字段一并加密。本文带你用全局选项启用ECH并把配置自动发布到DNS。背景与痛点SNI明文发送让访问路径全暴露 先说两个真实会遇到的场景企业出口/运营商侧的域名可见性HTTPS 只加密了传输内容但握手里 ClientHello 携带的 SNI 是明文的。换句话说流量审计设备不需要破解任何加密就能完整记录谁在几点几分访问了 api.payments.com。你在企业内网部署了内部支付网关运维侧一份 SNI 日志就能把内部系统拓扑画出来。基于 SNI 的封锁部分地区对特定域名的拦截直接匹配明文 SNI 完成连接在握手阶段就被切断内容加密形同虚设。对比项无 ECH启用 ECH观察者看到的 SNI真实域名 api.example.com公共名称 ech.example.comClientHello 其余参数明文整体加密HPKE 封装需要客户端做什么无通过 DoH/DoT 读取 HTTPS 记录配置维护无Caddy 自动生成、发布、轮换密钥 本节要点SNI 明文是 HTTPS 最大的隐私短板ECH 让观察者只能看到公共名称客户端需经 DoH/DoT 获取 ECH 配置机制拆解ECH双层加密握手与密钥自动轮换 一句话总结Caddy 自动维护一套公共名称 HPKE 密钥把真实 ClientHello 加密后套上公共名称的外壳发出密钥自动生成、自动轮换、配置自动写进 DNS。生活化类比给朋友寄信内层信封写真实地址你的真实域名再套一个外层信封写通用地址公共名称。邮递员只看到外层信封但信仍能准确送达。Caddy 的实现源码见 modules/caddytls/分五步公共名称你指定一个public_nameCaddy 会为它自动申请证书它只做外壳不承载业务流量生成密钥启动时自动生成 DHKEM(X25519, HKDF-SHA256) 密钥对并持久化无需手工管理发布到 DNS后台协程把 ECH 配置以 base64 编码写进受保护域名的 HTTPS 记录RFC 9460的ech参数TTL 目前硬编码为5 分钟源码中标注为临时值握手解密客户端经 DoH 拿到配置用 HPKE 加密真实 ClientHello外层 SNI 填公共名称服务器解出真实域名。Caddy 会强制把启用了 ECH 的连接策略升级到 TLS1.3ECH 的硬性要求自动轮换密钥30 天生成新替身90 天后从存储中删除源码常量rotationInterval/deleteAfter版本演进一路标准化阶段名称核心特点2018ESNI只加密 SNI 字段未标准化2020ECH 草案加密整个 ClientHello引入公共名称2024RFC 9180正式标准主流浏览器落地 本节要点双层结构公共名称外壳 加密的真实 ClientHello密钥全程自动生成、发布、30天轮换启用 ECH 的连接自动升至 TLS 1.3快速上手JSON 配置启用ECH并自动发布DNS 前提需要包含 DNS provider 模块的 Caddy 二进制标准发行版不含第三方 DNS 提供商需用 xcaddy 构建公网 HTTPS 场景建议客户端已启用 DoH。下面这份 JSON 配置做了三件事声明一个公共名称、指定用 Cloudflare provider 发布、把配置投递到受保护域名的 HTTPS 记录。{ apps: { tls: { encrypted_client_hello: { configs: [ { public_name: ech.example.com } ], publication: [ { publishers: { dns: { provider: { name: cloudflare, api_token: ... } } } } ] } } } }验证配置语法并启动观察日志里是否出现 successfully published ECH configuration listcaddy validate --config /etc/caddy/ech.json caddy run --config /etc/caddy/ech.json 本节要点一个 public_name 一个 dns publisher 即可跑通无需手写密钥Caddy 全部托管启动日志可确认发布是否成功进阶调优公共名称与域名发布策略怎么选 你的场景是个人项目 → 单公共名称只保留一个public_name。源码注释明确建议尽可能少用公共名称以最大化匿名集——所有连接挤在同一个外壳下流量分析最难区分个体。多域名团队部署 → 共享外壳 显式域名清单多个站点共用一个public_name并在publication.domains里显式列出要保护的域名。特别注意On-Demand TLS 的域名不会自动进入发布列表Caddy 只在握手时才认识它们漏写会导致首连接明文暴露。高安全需求 → 依赖内置轮换 强制 DoH保持30 天轮换默认值不要改得更频繁——规范警告过度轮换会压缩匿名集。同时确认客户端走 DoH/DoT否则客户端读到的 DNS 记录本身可被篡改。 本节要点公共名称越少匿名集越大On-Demand TLS 域名必须显式列出轮换别贪快DoH 是发布通道的前提验证与排错三条命令确认ECH生效✅ 验证命令依次执行dig short api.example.com HTTPS # 1. 应能看到 ech 参数 caddy validate --config /etc/caddy/ech.json # 2. 配置语法与模块检查 curl -sI https://api.example.com | head -1 # 3. 确认 TLS 1.3 生效浏览器侧打开chrome://net-internals/#echChrome112Firefox113据各浏览器官方发布说明查看 ECH 握手是否真正发生。三个最常见坑点症状SNI 仍然明文 →原因客户端没启用 DoH/DoT或浏览器版本低于支持线 →解法开启 DoH 并升级到支持版本客户端读不到配置就不会用 ECH。症状日志报 unable to publish域名无 HTTPS 记录 →原因该域名是 CNAME或尚无任何 A/AAAA 记录publisher 会主动跳过避免破坏通配符解析 →解法先给域名加一条 A 记录再重启。症状连接不稳定客户端回退到明文 SNI →原因公共名称没有证书其 DNS 未指向本服务器Caddy 签不出证书 →解法把ech.example.com的 A 记录指向服务器 IP确认证书签发后再观察日志。 本节要点dig HTTPS 记录看 ech 参数是第一手证据CNAME 和无记录的域名会被跳过发布公共名称必须有可用证书小结与展望ECH的下一步演进️ ECH 把明信片收件人变成了加密信件Caddy 侧你只需指定一个公共名称和 DNS provider密钥生成、HTTPS 记录发布、30 天轮换、90 天清理全部自动完成。值得注意的是Caddy 已把 ECH 密钥挂到 QUIC 监听器上HTTP/3 连接同样受保护。后续可关注两个方向ECHClientHelloRetry客户端重试时携带 ECH 的机制源码中已有SendAsRetry预留以及 DNS 发布 TTL 从5 分钟临时值走向正式策略。 本节要点Caddy 全托管密钥生命周期运维成本趋近于零HTTP/3 与 TLS 1.3 通道均已覆盖关注 Retry 机制与 TTL 策略的后续演进【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考