去年某电商平台被曝出用户登录请求以明文形式在公网传输，明文攻击者只需在咖啡店连上同一个WiFi，传输用Wireshark抓包就能拿到账号密码。漏洞这不是修复孤例。明文传输漏洞的明文本质就一句话：数据在发送端和接收端之间裸奔，中间任何一跳都能看光。传输修复它不需要高深技术，漏洞但需要把几个关键环节做对。修复

最直接的明文办法是上TLS。别一听证书就头疼，传输Let's Encrypt的漏洞免费证书用certbot自动签发续期，十分钟能搞定。修复有个坑我见过太多次：网站首页挂了HTTPS，明文但登录接口还在用HTTP，传输或者图片、漏洞JS资源混着HTTP加载。浏览器地址栏那个锁头标志会骗人，得打开开发者工具看Network面板，把Mixed Content警告全清掉才算数。HSTS响应头也加上，`Strict-Transport-Security: max-age=31536000; includeSubDomains`，让浏览器强制走HTTPS，省得用户手输http://。

内部服务之间的通信经常被忽略。微服务架构里，服务A调服务B的API，觉得“内网安全”就不加密。问题是内网不等于可信网络，横向移动攻击就是这么来的。gRPC默认支持TLS，Spring Cloud可以配mTLS双向认证。嫌麻烦的话，至少把敏感字段单独加密——比如用AES-GCM对密码、身份证号做应用层加密，密钥通过KMS管理，不走配置文件硬编码。

数据库连接字符串里的`useSSL=false`是个经典雷区。MySQL 5.7之后默认要求SSL，但很多老项目为了省事直接关掉。改成`useSSL=true&requireSSL=true`，再配好truststore。Redis、MongoDB同理。有个细节：连接池初始化时如果SSL握手失败，很多框架会静默降级到明文，得把日志级别调到DEBUG确认握手成功。

文件传输场景更隐蔽。FTP早该淘汰了，SFTP或者FTPS是底线。但有人用HTTP POST传文件，觉得“反正传完就删”。去年某医院系统导出患者数据用HTTP，结果被运营商缓存节点留了副本。对象存储的预签名URL也要注意，默认可能是http://，生成时显式指定https。

代码层面有个容易漏的点：日志和异常信息。开发环境打印完整请求体方便调试，上了生产忘了关，密码直接进日志文件。用logback的或者Python logging的Filter把password、token字段脱敏。还有APM工具，SkyWalking、Pinpoint默认会采集HTTP body，得在配置里关掉或者配脱敏规则。

修复完怎么验证？别只靠人工看。写个pytest脚本，用scapy构造流量包，断言TCP payload里不出现明文密码字符串。CI流水线里加一步sslscan或者testssl.sh，检查协议版本和加密套件。Cipher Suite别留RC4、3DES这些老古董，TLS 1.2起步，有条件上1.3。

最后说个反直觉的：全站HTTPS之后，性能损耗没想象中大。TLS 1.3的握手只要1-RTT，会话恢复0-RTT。真觉得慢，上CDN做边缘终止，回源再加密。别拿性能当借口，明文传输的代价是数据泄露，那个成本高得多。