内部OTS硬件的TLS证书
2019年6月26日 星期三
多年前，某客户委托我测试一款接入家庭网络提供服务的硬件设备。该设备通过HTTP Web界面进行管理（这类设备通常如此）。测试时恰逢Chrome即将更新——即将突出显示通过HTTP访问或提交内容的情况。我与客户讨论了这一变化，询问他们是否有应对计划。
客户表示曾考虑使用自签名证书，但这同样会显示安全警告，迫使用户忽略警告接受证书。由于该硬件旨在增强网络安全性，这种方案显然不妥。
经与知名TLS专家Scott Helme讨论后，我们设计了以下工作流程，使内部设备能获得有效的TLS证书。
参与角色
- OTS：需要证书的现成硬件设备
- HQ：设备制造商
- LE：Let’s Encrypt证书颁发机构
初始设置
HQ需拥有一个专门用于OTS设备的域名（例如主域ots.space可派生ots-cert.space）。
工作流程
- OTS首次启动时生成随机令牌，通过HTTPS将令牌及IP地址发送至HQ
- HQ为设备生成唯一名称（如nifty-babbage）
- HQ在设备域名下创建DNS A记录指向OTS提交的内网IP（如nifty-babbage.ots-cert.space → 192.168.0.7）
- HQ将名称返回给OTS
- OTS基于该名称生成私钥和CSR发送至HQ
- HQ利用CSR通过LE的DNS验证机制签发子域名证书
- HQ创建包含证书和认证令牌的数据包
- OTS通过HTTPS轮询HQ（使用步骤1的随机令牌作为标识），下载数据包后安装证书，并在Web服务器设置HTTP到HTTPS的重定向（如http://192.168.0.7 → https://nifty-babbage.ots-cert.space）
- OTS每日检查证书有效期，若剩余天数≤7天（或设备重启时），使用认证令牌向HQ申请新证书
此处可查看实际演示；服务端运行在HQ，客户端运行在OTS。
注意事项
- LE签发的所有证书会提交到证书透明度日志，虽可能暴露设备名称，但由于无法关联具体用户，风险可控
- 公共DNS记录中包含内网IP地址同样不会造成实际问题
- 为用户提供自定义设备名称可能增加证书透明度和DNS记录的风险
- LE证书有效期为90天，设备关机91天后启动时证书将过期，但启动时的回调机制会自动申请新证书
- 在DHCP网络中IP频繁变更时，OTS可在每次IP变化时通知HQ更新DNS记录。短TTL可缓解此问题。若设备为路由器，可拦截DNS请求直接返回自身IP
- 为防止所有OTS设备同时回调导致HQ被DDoS攻击，每日任务应设置为随机时间执行
- 若生产流程允许，可为设备预置客户端证书替代随机令牌和认证令牌。但需注意证书有效期问题（可通过同时签发服务端和客户端证书缓解，但会增加复杂性）
- 私钥在OTS本地生成，从不通过网络传输。HQ仅能接触（可能缓存）证书，但无私钥则证书无用
概念验证
我已创建完整可运行的概念验证供实践使用。只需简单配置即可运行，对大多数用户而言应较为简单。