解读

在国内金融、政务、医疗等合规场景，面试官问“如何加密传输”并不是想听你简单答一句“开 HTTPS”。他想知道：

1. 你是否清楚 CouchDB 的传输层安全机制与国产密码合规要求（国密/等保 2.0）；
2. 你是否能在不中断业务的前提下完成证书轮换、强制 TLS1.3、双向认证、HSTS、加密套件白名单；
3. 你是否能把“加密传输”与“离线同步”“集群节点间复制”两条链路分开设计，并给出可落地的运维脚本与回滚方案。

一句话：这道题考察的是生产级、合规级、可灰度、可回滚的加密传输落地能力。

知识点

1. CouchDB 传输通道两条链路

   • 对外：HTTP API（含 CORS、_session、_utils、_replicator）
   • 对内：节点间复制（_cluster_setup、_nodes、_dbs 元数据同步）

2. TLS 开关与版本

   • 配置项 [ssl] port=6984 与 [daemons] httpsd={couch_httpd, start_link, [https]}
   • Erlang/OTP 24+ 才默认支持 TLS1.3；国内 CentOS 7 自带 Erlang 19 需升级至 Erlang 25 并打开 tlsv1.3 选项，否则等保测评直接判不合格

3. 国产密码合规

   • 等保 2.0 三级要求“传输完整性、保密性、不可否认性”
   • 若客户明确国密双证书（SM2 签名 + SM2 加密），需通过 TASSL 或 BabaSSL 动态库替换 Erlang 的 crypto，重新编译 couch_ssl，并在 ssl 段添加 {ciphers, ["ECC-SM2-WITH-SM4-SM3"]}；同时把 Nginx 前置做 SM2 卸载，CouchDB 内部仍走 RSA 通道，实现“外部国密、内部 RSA”的混合方案，既过测评又不改代码

4. 双向 TLS（mTLS）

   • 在 [ssl] verify=verify_peer + {fail_if_no_peer_cert,true} 开启
   • 证书链需把根 CA 导入操作系统信任区，否则 Erlang 会报 unknown_ca；国产场景下根 CA 往往是国密 SM2 CA，需要 patch OTP 的 public_key 模块

5. HSTS 与加密套件白名单

   • CouchDB 本身不返回 Strict-Transport-Security，需在前置 Nginx/OpenResty 添加 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
   • 加密套件白名单示例： {ciphers, ["TLS_AES_256_GCM_SHA384","TLS_CHACHA20_POLY1305_SHA256"]}，禁用所有 CBC 套件，防止 Lucky13 攻击

6. 离线同步链路加密

   • PouchDB<->CouchDB 同步默认走 https://，但国内小程序容器（微信、支付宝）要求域名需备案 + TLS 证书需国内 CA 签发；否则视为“不安全域名”被屏蔽
   • 若终端处于纯内网离线，需搭建本地 https 网关（自签证书 + 预置公钥到 App 信任库），并在 CouchDB 层强制 require_valid_user=true，防止匿名脱库

7. 证书轮换与灰度

   • Erlang 的 SSL 表缓存在内存，直接替换文件不会生效；需调用 curl -X POST http://localhost:5986/_reload_tls（自定义端点，内部执行 ssl:clear_pem_cache()）实现热加载
   • 生产建议：双证书模式（RSA+SM2），通过 Nginx stream 模块按客户端 TLS Hello 里的 SNI 分流，灰度切换流量比例，回滚只需改 upstream

8. 审计与测评

   • 使用 ssllabs-scan 或知道创宇、奇安信等国内测评工具做评级，要求 A+ 且无弱算法
   • 打开 [log] level=debug，记录 TLS handshake_failure 便于等保现场审计

答案

“CouchDB 的加密传输需要分层治理：

1. 对外 API：通过 [ssl] 段开启 6984 端口，强制 TLS1.3，加密套件仅留 TLS_AES_256_GCM_SHA384 等安全套件；若客户要求国密，我们采用TASSL 编译 Erlang 并在 Nginx 前置做 SM2 卸载，CouchDB 内部仍走 RSA，实现合规与性能双赢。
2. 节点间复制：在 vm.args 添加 -proto_dist inet_tls，使用自签集群证书，并开启 verify_peer，防止横向渗透。
3. 离线同步：小程序端必须备案域名 + 国内 CA 证书；纯离线场景预置公钥到 App，并启用 require_valid_user，杜绝匿名访问。
4. 运维灰度：证书轮换通过 _reload_tls 热加载，配合 Nginx 双证书灰度，可在 30 秒内完成回滚，保证 4 个 9 可用性。
5. 合规闭环：测评前用奇安信扫描拿 A+，并留存 TLS 调试日志，等保现场可直接出示。”

拓展思考

1. 如果客户要求零信任架构，CouchDB 每个连接都需短期证书（SPIFFE/SPIRE），你会如何把 Envoy 或 MOSN sidecar 与 CouchDB 集成，做到证书 5 分钟自动轮换且业务无感知？
2. 在跨地域双活场景，北京与深圳集群通过公网 VPN+TLS 双层加密还是单 TLS 隧道？如何权衡 MTU、延迟与等保测评的“双重加密”条款？
3. 当终端数量达到百万级 PouchDB，每次同步都触发全握手会导致 CPU 暴涨，你是否考虑Session Ticket 分布式缓存（Redis 集群） 以及TLS 层 False Start 优化？请给出 Erlang/OTP 参数调优细节。