一次调试接口的意外发现
上周在排查一个第三方API对接问题时，随手开了个抓包工具，本想看看请求头有没有写错参数，结果一眼就看到登录用的用户名和密码清清楚楚地显示在请求体里。当时心里咯噔一下——这用的是HTTP，数据根本没加密。
这种场景其实在内部系统、测试环境里太常见了。开发图省事，直接上明文传输，等上线再切HTTPS。可就是这个“临时”操作，让数据在局域网里裸奔。
什么是明文协议
明文协议指的是通信过程中数据以原始可读格式传输，不经过加密处理。常见的如HTTP、FTP、Telnet、SMTP（未启用STARTTLS时）都属于这类。它们的优点是结构简单、调试方便，缺点也明显：谁都能看。
拿HTTP做个解析示例
假设你提交一个登录表单，浏览器发起一个POST请求：
POST /login HTTP/1.1\r\nHost: example.com\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 27\r\n\r\nusername=admin&password=123456上面这段完整的HTTP请求，只要中途有人能截获，比如在同一Wi-Fi下的设备，或者中间路由器被监听，就能直接提取出账号密码。不需要解密，因为压根就没加密。
怎么抓一个明文包
用curl加上--verbose参数，可以打印出完整通信过程：
curl -v -X POST \n -d \"username=test&password=hello123\" \n http://api.dev.local/login输出中你会看到> POST 和 < HTTP/1.1 200 这样的标记，中间的请求头和body都是明文展示。这就是典型的明文协议交互。
另一个常见例子：SMTP发邮件
早期邮件服务默认使用25端口，不开启加密时，整个认证和内容都是明文。比如登录过程：
EHLO client.local\r\nAUTH LOGIN\r\nbase64编码的用户名\r\nbase64编码的密码\r\nMAIL FROM:<user@example.com>\r\nRCPT TO:<to@other.com>\r\nDATA\r\nSubject: 测试邮件\r\n\r\n这是一封测试邮件内容。\r\n.\r\n虽然用户名密码用了Base64编码，但这不是加密，只是转码。任何拿到数据的人，反解一下就原形毕露。
为什么还在用明文协议
不是不知道风险，而是有些场景确实需要简单高效。比如内网服务之间调用，交换一些非敏感配置；或者嵌入式设备资源有限，跑不动TLS；又或者开发调试阶段，不想折腾证书。
但问题往往出在边界模糊：测试环境用了明文，上线忘了改；内网以为安全，结果有设备带病毒往外传流量；设备日志打满了明文请求，备份文件一泄露，全白送。
看得见的数据才敢托付
有一次帮朋友公司查异常请求来源，翻日志发现他们的IoT设备把用户手机号拼在URL里传，像这样：/report?uid=138****1234&status=online，走的还是HTTP。基站附近的嗅探工具扫一圈，一堆手机号就收走了。
现在再看协议，习惯性先问一句：这是加密的吗？如果不是，就得考虑谁还能看到它。毕竟在网络世界里，看不见的传输路径，往往藏着最危险的路口。