STARTTLS 暂时不支持解密 — 明文握手后升级 TLS
什么是 STARTTLS
STARTTLS 是一种 明文协议连接中动态升级到 TLS 的模式。常见协议：
| 协议 | 默认端口 | 说明 |
|---|---|---|
| SMTP（邮件发送） | 587 / 25 | 先明文握手发邮件命令 → 发 STARTTLS 指令 → 升级 TLS |
| IMAP（邮件接收） | 143 | 同上，升级 TLS 后继续 IMAP 命令 |
| POP3 | 110 | 同上 |
| XMPP（即时通讯） | 5222 | Jabber 协议里的升级 TLS |
| FTP | 21 | 命令通道升级 TLS |
和"直接 TLS"（比如 HTTPS 443、SMTPS 465）的区别：直接 TLS 是连接一建立就在 TLS 里，STARTTLS 是先明文、后升级。
为什么解不了
PCAPdroid 底层 mitmproxy 的 TLS 处理逻辑假设 TLS 握手从连接一开始就要发生。STARTTLS 的升级时序：
- TCP 三次握手完成 → 明文协议开始交互
- 客户端发 STARTTLS 指令
- 服务器响应可以升级
- 此时才开始 TLS 握手
mitmproxy 还没处理这种时序差异，所以 STARTTLS 连接在 PCAPdroid 里显示橙色锁（不支持解密）。详见 mitmproxy 官方 issue #4215。
临时变通
| 变通方法 | 说明 |
|---|---|
| 用 SSL 版本端口代替 STARTTLS | 邮件客户端优先用 SMTPS（465）/ IMAPS（993）/ POP3S（995），这些是直接 TLS，PCAPdroid 能正常解密 |
| 直接抓明文 | 如果 STARTTLS 没被强制，某些邮件客户端可以配置不升级 TLS——此时 PCAPdroid 看到的就是完整明文邮件内容 |
| 等 mitmproxy 支持 | 长期来看还是底层跟进 |
影响范围
STARTTLS 主要影响传统互联网协议（邮件、FTP、IRC、XMPP）。移动 App 场景下绝大多数用 HTTPS（直接 TLS，443 端口），STARTTLS 的实际影响范围比 QUIC 小得多。
快速判断
在 PCAPdroid Connections 里看到端口是 587 / 143 / 110 / 5222 且橙色锁的连接，大概率就是 STARTTLS。端口 465 / 993 / 995 是直接 TLS，应该是绿色或灰色锁。