仅靠tls不安全，因配置落内存/磁盘后tls失效；敏感字段须在应用层用aes-gcm等aead加密，密钥不可硬编码，iv不可复用，解密前须校验tag并安全擦除明文。
为什么不能只靠 TLS 就认为配置安全？
TLS 确实能防中间人窃听，但配置项一旦落到客户端内存或磁盘（比如写进 config.json、被调试器 dump、或被恶意进程读取），TLS 就完全失效了。真实场景里，你发的是“数据库密码”“API密钥”，不是“用户昵称”，这类敏感字段必须在应用层再加密——不是为了替代 TLS，而是补上 TLS 保护不到的那一段。
常见错误现象：SSL_read 返回成功，但配置文件被逆向工具直接搜出 "db_password": "123456"；或者用 std::string 存密钥后没清零，core dump 里还能还原。
- 加密必须在序列化之后、发送之前做，不是对明文字段单独加密再拼 JSON
- 密钥不能硬编码在代码里，也不能从服务端明文下发（否则等于没加）
- 推荐用 AEAD 模式（如
AES-GCM），避免自己拼接 HMAC 导致侧信道或实现漏洞
怎么用 OpenSSL 实现 AES-GCM 加密（C++ 17+）
OpenSSL 1.1.1+ 原生支持 EVP_AEAD 接口，比老式 EVP_EncryptInit_ex 更安全、更难写错。重点不是“能不能用”，而是“怎么避开常见 crash 和解密失败”。
关键参数差异：key 必须是 32 字节（AES-256-GCM），iv 必须是 12 字节且**绝不能复用**，tag 固定 16 字节；少一个字节，EVP_AEAD_CTX_seal 就返回 0，但不会告诉你哪错了。
立即学习“C++免费学习笔记（深入）”；
- 用
RAND_bytes(iv, 12)生成 IV，随密文一起发（不加密），但每次请求必须新生成 - 额外认证数据（AAD）可填空，但如果配置含版本号或设备 ID，建议填进去防篡改
- 务必检查
EVP_AEAD_CTX_seal返回值，失败时调ERR_print_errors_fp(stderr)查原因（常见：key 长度错、IV 复用、输出缓冲区不够）
// 示例：加密 config_json_str
std::vector<uint8_t> cipher(config_json_str.size() + 16 + 12); // iv(12)+cipher+tag(16)
int out_len;
EVP_AEAD_CTX* ctx = EVP_AEAD_CTX_new(EVP_aead_aes_256_gcm(), key.data(), key.size(), 16);
EVP_AEAD_CTX_seal(ctx, cipher.data(), &out_len, cipher.size(),
iv.data(), 12, config_json_str.data(), config_json_str.size(),
nullptr, 0); // aad = nullptr
EVP_AEAD_CTX_free(ctx);
客户端解密失败的三个高频原因
服务端加密没问题，客户端一解就报 authentication failed 或直接 segfault，八成掉进这三个坑里：
-
IV被截断或错位：前端 JS 用Uint8Array解包二进制时默认按小端解析，C++ 发的是原字节流，必须确认两端对IV的起始偏移和长度理解一致 - 密钥派生方式不一致：服务端用
PBKDF2-SHA256，客户端用scrypt，哪怕密码一样也解不开；建议统一用HKDF-SHA256+ 固定 salt - JSON 解析前没校验 tag：先调
EVP_AEAD_CTX_open，成功才交给nlohmann::json::parse；否则非法输入可能触发 JSON 解析器异常，掩盖真实解密失败原因
密钥怎么安全存在客户端？
没有“绝对安全”的方案，只有“攻击成本是否高于收益”。硬编码 const uint8_t key[32] = {...} 是最差选择——反编译一眼可见。可行路径有限：
- Windows 上用
CryptProtectData封装密钥，绑定当前用户 SID；Linux 用keyctl创建 session keyring（需配合 daemon） - 如果客户端是 Qt 或 Electron，优先走系统密钥库（
QKeychain/keytar），别自己实现加密存储 - 绝对不要把密钥存在
%APPDATA%或~/.config下的明文文件里——连 base64 都算不上保护
最常被忽略的一点：加密配置项的生命周期。解密后的密钥字符串必须用 std::vector<:byte></:byte> 或 secure_vector（Botan）持有，并在作用域结束前显式擦除，而不是依赖 std::string 析构——它不保证清零内存。
