第一次装完 Wireshark 的人十有八九会做同一件事挑个网卡打开登录页面把账号密码敲进去然后在过滤框里敲一个 http满怀期待地看着自己刚输入的字符从屏幕上滚过去。然后什么都没发生。屏幕上是一串TLSv1.3 Application Data长度一百来字节点开是十六进制乱码Follow Stream 出来的是一屏看不懂的二进制。这个落差感特别强尤其是当你搜到的教程还写着三步抓到别人网站的账号密码的时候。我第一次干这事是很多年前那会儿确实还有大量站点走明文 HTTP在 Follow TCP Stream 里能直接看到usernamexxxpasswordxxx那种原来网络上跑的东西长这样的震撼我到现在还记得。但今天同样的操作只会得到加密字节。这不是 Wireshark 退化了恰恰相反这说明整个 web 生态终于把该做的加密做上了。这篇想聊的是三件事Wireshark 抓登录流量时到底能看到什么、看不到什么背后的协议原理是什么把这套技能用在真正有价值的地方比如排查自己服务登录慢的问题、给自家站点做安全体检以及那条必须划清楚的线——抓自己可控的终端和自有服务是正常技术工作越界去拿别人的账号密码那就不是技术问题了。1. 先搞清楚一件事为什么大多数登录请求抓出来是乱码1.1 从明文表单到全站加密这十几年的变化早期 web 的登录流程非常裸。浏览器把表单字段拼成application/x-www-form-urlencoded的字符串作为一个 HTTP POST 请求体直接以纯文本形式发出去中间任何一个能碰到这条链路的人都能读到。那个年代抓包真有收获同网段里随便一台机器开个混杂模式往往就能捞到东西这也是为什么老一辈做安全的都习惯说办公网别乱填密码。转折点有两个。一个是证书签发成本的塌陷免费自动化证书方案普及之后给一个小站点上 HTTPS 从要找人申请、要花钱、要记得续期变成了跑一条命令。另一个是浏览器态度的转变地址栏明确标注不安全、混合内容拦截、HSTS 预加载列表一步步把 HTTP 挤到了墙角。今天你去抓任何一家正经做生意的网站登录接口百分之百在 TLS 里面。所以用 Wireshark 抓登录账号密码这个动作在今天的技术现实里默认结果就是抓不到。理解这一点比学会点哪个菜单重要得多因为它决定了你后面所有操作的预期。1.2 一次登录在 Wireshark 里究竟长什么样我们拿一次真实的登录动作来拆。假设你在浏览器里打开某站登录页、输入、点击提交Wireshark 捕获到的包的顺序大概是这样的阶段典型包你能看到的内容域名解析DNS Query / Response完整域名、返回的 IP、解析耗时建连TCP SYN / SYN-ACK / ACK目标 IP、端口、握手 RTT密钥协商TLS ClientHello / ServerHelloSNI 域名、密码套件、随机数、版本证书与协商TLS 1.2Certificate / ServerKeyExchange 等证书链、有效期、密钥交换算法应用数据TLS Application Data只有长度、方向、时间戳后续请求TLS Application Data同上内容不可读关键在最后两行。登录表单提交的那一刻浏览器发出的 HTTP 请求体是加密的学名叫记录层载荷TLS record payload。Wireshark 能看到这条记录多长、从哪发到哪、什么时候发的但打开载荷只能看到密文。用户名也好、密码也好、CSRF token 也好全部在那一坨密文里。有人会问那 Follow HTTP Stream 呢在 HTTPS 里它根本识别不出 HTTP 层Wireshark 只能给你 Follow TLS Stream结果一样是乱码。这不是解码器偷懒是协议就这样设计的。1.3 为什么三步抓密码的老教程还满网都是我把这类教程归成四类识别它们对省时间很有用。第一类是针对纯 HTTP 站点的写得没错但现在几乎找不到活得久还能被拿来当例子的 HTTP 登录接口了。第二类是针对自己搭的本地实验环境比如教学场景里自己写一个 HTTP 表单页面抓出来的当然是明文但那是演示协议用的和抓某个真实网站完全不是一回事。第三类是把抓包和解密混在一起讲暗示有某种工具能一键把 HTTPS 变明文实际上它要么需要你在自己的终端上预置密钥日志要么需要你在链路上做证书替换——前者只能看到你自己的流量后者会让浏览器弹红警告。第四类就是纯流量生意标题写得很刺激点进去是卖课、卖工具、拉群。看清这几类之后你会发现抓不到这件事本身就是一个结论而且是个好结论说明这条链路的安全假设成立。2. TLS 握手那几百毫秒里Wireshark 能看到什么2.1 ClientHello 里那些还没加密的线索TLS 握手的第一个包是 ClientHello它是明文发的这给了我们不少可读信息。最有用的是 SNIserver_name 扩展也就是你访问的域名这个字段在绝大多数场景下是可见的只有启用了加密客户端问候ECH的站点才会把它藏起来而目前覆盖度还不高。其次是 ALPN 扩展它告诉服务器客户端支持 HTTP/2 还是 HTTP/1.1从这个小字段能反推出浏览器和站点的协议协商能力。再往下看supported_versions 扩展能告诉你客户端支持哪些 TLS 版本key_share 和 signature_algorithms 会暴露一些实现细节。安全研究里有一个方向叫TLS 指纹就是拿这些字段的组合去判断对面是 Chrome、Firefox 还是某个自动化客户端甚至能区分版本号。做风控的人会用到这个做爬虫对抗的人也会研究这个这是同一套知识的两个方向。ServerHello 同样是明文的里面有服务器选定的版本、选定的密码套件和一个随机数。到这里为止双方还没开始加密tls.handshake.type 1和 2这两个显示过滤器就是专门用来快速定位这两个包的。2.2 证书交换在两个 TLS 版本里的可见性差异这是 TLS 1.2 和 TLS 1.3 最直观的一个区别很多人第一次对比会以为抓包工具有问题。在 TLS 1.2 里ServerHello 之后服务器会以明文发送 Certificate 消息你能在 Wireshark 里展开证书链看到签发者、有效期、公钥算法、SAN 列表甚至能直接看出对方用的是不是 ECDHE 密钥交换。如果是那种古老的 RSA 密钥交换TLS_RSA_*套件握手过程中会用服务器公钥加密预主密钥——这正是老教程里理论上可以解密的来源但前提是你得拿到服务器私钥。现代站点早就不用这套了因为 ECDHE 提供前向保密每次会话临时生成密钥对即使服务器私钥哪天泄露历史流量也解不开。TLS 1.3 就更彻底了。ServerHello 之后的所有握手消息包括 EncryptedExtensions、Certificate、CertificateVerify、Finished全部被加密。你在 Wireshark 里看到的包里Certificate 那一行直接在包里就找不到了取而代之的是连续的 Application Data。所以抓 TLS 1.3 的流量明面上你能确定的只有一件事对端在讲 TLS 1.3。对比项TLS 1.2TLS 1.3ClientHello / ServerHello明文明文服务端证书明文可见已加密密码套件协商明文可见只看到选定项前向保密取决于套件默认具备握手往返次数2-RTT1-RTT 或 0-RTT2.3 加密之后剩下的东西长度、时序和方向内容读不了不代表什么都读不了。剩下的这层信息量其实不小业内叫流量分析或侧信道分析。包的长度是首要信号。一个登录请求的请求体长度取决于字段多少如果某个站点的用户名长度和密码长度会直接反映在记录层长度上那么理论上可以通过长度分布对输入做一定的推断。方向和时间戳同样有价值点击提交之后多久收到第一个响应字节这个间隔就是用户感知的加载时间响应的分包模式能反映后端是走了一次性返回还是流式渲染。学术界做过网站指纹识别通过加密流量的包长序列去判断用户在看哪个页面准确率在受控条件下能做得相当高防御手段就是填充和长度归一化以及 ECH 这种把 SNI 也藏起来的技术。对做工程的人来说这层信息最实际的用途就是性能分析不能看内容但完全可以看慢在哪个阶段下一节就展开讲这个。3. 把 Wireshark 用对地方登录链路的故障排查实战3.1 动手前的准备选网卡和设置捕获过滤器打开 Wireshark 第一件事是选对接口。有线、无线、虚拟网卡、回环接口选错了抓半天全是别的进程的噪音。如果你只关心本机某个进程的流量回环接口往往更干净。第二件事是设捕获过滤器capture filter这个是在抓之前生效的 BPF 表达式直接决定哪些包被写进文件。为什么要先过滤一是减少噪音二是控制抓包文件的体积和内存占用更重要的是减少无关数据的收集——只抓你确实需要的流量这本身就是一个良好的工程习惯。# 只抓与某个内网服务相关的 HTTPS 流量 tshark -i eth0 -f host 10.20.30.40 and tcp port 443 -w login.pcapng # 抓完只看 TLS 握手的第一个包和 SNI 字段 tshark -r login.pcapng -Y tls.handshake.type1 \ -T fields -e frame.time_relative -e ip.dst \ -e tls.handshake.extensions_server_name显示过滤器display filter是抓之后再叠加的语法更友好常用的几个建议提前记下来tcp.stream eq 5只看某一条流、tls.alert_message看告警、tcp.analysis.flags看异常标记、dns看解析。抓包文件保留原始数据显示过滤器可以反复换所以真正落盘的时候宁可宽一点事后收窄比事后重抓省事。3.2 登录慢问题到底出在哪一段这是我用 Wireshark 最多的场景用户反馈登录按钮点下去要等好几秒。把时间显示格式改成自捕获开始的相对秒数View Time Display Format然后顺着这条 tcp.stream 往下读时间会被切成四段。第一段是 DNS。看 DNS Query 和 Response 的时间差如果这里就花了 300 毫秒以上说明解析链路有问题可能是本地 DNS 服务器响应慢、也可能是域名用了 CNAME 链做了好几跳。第二段是 TCP 建连看 SYN 到 SYN-ACK 的间隔这个基本等于一个 RTT超过 100 毫秒说明链路本身绕远了或者走了不优的出口。第三段是 TLS 握手从 ClientHello 到客户端发出第一个 Application Data包含 1 到 2 个 RTT 加上服务端计算耗时正常在 100 到 300 毫秒之间如果用 TLS 1.3 并且命中会话复用这一段时间可以被压到接近 0。第四段是 TTFB也就是从请求发出到收到第一个响应字节。这一段才是真正体现后端逻辑的如果前三段加起来只有 200 毫秒而 TTFB 有 2 秒那问题一定在服务端可能是登录接口里同步做了外部调用、可能是数据库慢查询、可能是密码哈希算法强度设得太高这个是真事成本因子调得太激进会明显拖慢登录。用 Statistics Conversations 可以从宏观上看哪一对 IP 之间流量最大、耗时最长配合 Service Response Time 菜单能快速定位嫌疑协议。这套流程用过几次之后你会发现性能问题的定位速度会明显快于纯看日志。3.3 重传、TLS 告警和那些不好读的异常标记Wireshark 的 Expert Information 面板Analyze Expert Information会把异常包按严重程度归类这是排查疑难问题的入口。常见的标记和含义我整理成一张表标记常见原因处理方向TCP Retransmission丢包、链路拥塞、对端处理不过来看丢包率检查中间链路TCP Dup ACK对端收到乱序包重复确认通常伴随重传一起看TCP Zero Window接收方缓冲区满了应用层读取太慢查服务端TCP Out-of-Order路径上多链路负载不均一般可容忍量大要查TLS Alert: handshake_failure密码套件协商不上检查双方支持的套件和版本TLS Alert: unknown_ca证书链不被信任补齐中间证书TLS Alert: certificate_expired证书过期直接续期TLS Alert: unrecognized_nameSNI 与站点配置不匹配检查虚拟主机配置这里有个经验不要一看到重传就归因网络。我遇到过一次登录偶发失败的案例抓包显示客户端在收到 ServerHello 之后立刻发 RST配合 TLS Alert 一看是客户端主动拒绝最后定位到是本机时间偏差太大导致证书校验失败。如果只盯着 TCP 层看会一直以为是网络抖动。还有一点tcp.analysis.retransmission这个显示过滤器可以把所有重传挑出来但要注意重传的定义依赖于捕获点。如果你在客户端抓看到的重传可能是自己发出去没被确认如果在服务端抓同样的丢包会表现为没收到。搞清楚抓包点的位置比背过滤器语法更重要。4. 用抓包给自家登录接口做一次安全体检4.1 确认没有明文漏网这件事听起来很基础但我在真实的项目里确实遇到过漏网的接口。方法是打开自家站点走完整个注册登录流程然后在 Wireshark 里跑几个显示过滤器逐一排查# 有没有明文 HTTP 的 POST http.request.method POST # 有没有明文里出现敏感字段字样 frame contains password frame contains token # 有没有常见的表单编码变体 frame contains passwd需要注意如果站点做了正确的加密这几个过滤器应该是零结果。如果真有结果说明有某条链路没走加密可能是早期遗留的接口、可能是某个第三方组件回调的地址、也可能是配置漏了一项。frame contains这个过滤器对编码后的数据匹配效果有限比如 URL 编码之后 password 这个字符串可能被打散所以要配合手工看几个包。顺手还要检查混合内容主页面是 HTTPS但里面加载了 HTTP 的资源浏览器会拦一部分、放一部分被放过去的那部分就是隐患。这个在 Wireshark 里表现为同一个会话里既有 443 的流量又有 80 的流量一眼能看出来。4.2 重定向链路和响应头里的细节登录流程里往往有几次重定向访问首页、跳登录页、提交后跳回目标页。这条链路上最容易出问题的地方是把票据塞在 URL 查询串里。查询串会被写进各级日志、会被带进 Referer 头、会被浏览器历史记录保存等于把凭证到处撒了一遍。抓包的时候重点看 3xx 响应的 Location 头如果里面带了长串参数就该改成走请求体或者设置到 Cookie 里。响应头本身也值得逐条看。Cookie 有没有 Secure只走加密连接、HttpOnly脚本读不到、SameSite限制跨站携带这几个属性直接决定了会话票据被脚本或跨站请求带走的难度。HSTS 响应头决定了浏览器后续会不会强制走加密加上它等于给整站上了一道长效保险。还有 Cache-Control登录后的页面如果被标记成可缓存共用设备上就存在被翻出来的可能。这些检查不需要任何高级工具就是把抓包结果当一份实际发出的证据来看。配置写没写是一回事实际发出去的是什么是另一回事抓包看的是后者。4.3 解密自有终端流量的机制与它天然的边界如果你在做自己的站点调试需要看到请求体到底长什么样有一个正规做法让客户端把自己协商出来的会话密钥写到一个日志文件里然后让 Wireshark 读这个文件去还原会话。具体做法是给浏览器进程设置环境变量SSLKEYLOGFILE指向一个文件路径浏览器会把每个 TLS 会话的密钥材料追加进去然后在 Wireshark 的 Preferences Protocols TLS 里把 (Pre)-Master-Secret log filename 指向同一个文件。刷新登录页面之前那些 Application Data 就能被还原成可读的 HTTP 请求和响应你就能直接看到表单提交的字段和结构。这个机制有一个根本性的边界必须讲清楚它只对设置了该环境变量的那个客户端进程生效。密钥是会话双方协商出来的日志文件里只有你自己的那半边所以你只能解开你自己这台机器上、由这个被配置过的进程发起的会话。它解不开别人终端上的流量也解不开同网段其他人的流量因为它从原理上就不具备那个信息。换句话说这是一个自助调试工具用途非常明确。用完记得把环境变量清掉把密钥日志文件删掉。那里面存的是会话密钥材料虽然是临时的但没有必要留在磁盘上。5. 关于抓别人密码这件事必须说清楚的几条线5.1 技术上走不通方向上也不该走把前面几节的结论合起来看现代站点全站加密、TLS 1.3 把握手消息也藏起来、密钥交换默认具备前向保密。想在中间截获并还原别人的登录凭证可行路径只剩下两条——控制对方终端或者在链路上做证书替换把加密降级掉。前者需要你在别人机器上装东西后者会让浏览器弹出明显的证书警告正常用户都会停下来。这两条路都不是技术技巧层面的东西了。它们绕过的不是协议是别人的知情和同意。做技术的人对这种边界应该格外敏感因为能力越大越需要自己给自己划范围。5.2 那些热词背后的东西为什么都不靠谱围绕这个标题周边你会看到一堆看起来很诱人的词批量账号、破解口令、万能绕过、超管密码。我直接把结论摆出来。所谓批量可用的现成账号绝大多数来源是被撞库或被钓鱼收集的用它们等于接手别人的身份风险全在你这边。所谓破解工具装入即失效的占多数剩下的是借你的机器跑别人的任务。至于输入特定字符就能绕过验证这种说法针对的是十几年前那种把用户输入直接拼进查询语句的写法现在的框架和参数化查询早就把这条路堵住了还留着这种漏洞的站点本身就是个雷碰它没有任何收益。这些东西共同的特点是收到的货不对板付出的代价却是真实的——可能是你的设备、你的账号也可能更多。5.3 给自己账号做安全自查的清单与其研究怎么抓别人的不如花二十分钟把自己账号的安全级别提上去。这张表可以直接照着做检查项具体做法为什么有用全站加密确认常用站点地址栏是加密标识让链路上的内容不可读双因素优先用应用生成的动态码口令泄露后仍有一道门密码复用每个站点用不同口令单点泄露不扩散口令管理用本地口令管理器生成与保存兼顾强度与可记忆性会话票据定期清理浏览器 Cookie 与登录状态减少共用设备残留公共网络不在陌生网络处理敏感业务减少被监听的面设备更新系统和浏览器保持更新补上已知问题再补一个我自己的习惯任何要求输入主账号密码来验证身份的页面先看域名是不是官方的再决定要不要输。这一条能挡掉绝大多数钓取行为成本几乎为零。回过头说抓包这件事本身它是我这些年用得最多的排查工具之一也是我认为最值得投入时间去学的基础技能。它的价值从来不在能看到别人的密码而在于它把抽象的网络行为变成了可以逐包阅读的事实——延迟卡在哪一段、连接为什么断、证书为什么不被信任这些问题的答案都在那些字节里。我个人的体会是学 Wireshark 最快的路径不是背过滤器语法而是找几个自己真实遇到的问题从头到尾用抓包定位一次做完两三个案例剩下的就都是查文档的事了。至于那个标题里描述的目标就让它留在上个时代吧。