参考文章:
Wireshark 基本介绍和学习 TCP 三次握手
[技术流] Wireshark 对 HTTPS 数据的解密 https://zhuanlan.zhihu.com/p/36669377
- https://en.wikiversity.org/wiki/Wireshark/HTTPS
- Journey to HTTP/2
以 TCP/IP 协议为例, 如何通过 wireshark 抓包分析? https://zhuanlan.zhihu.com/p/36414915
TCP 三次握手和四次挥手 https://www.cnblogs.com/qdhxhz/p/8470997.html
Https 详解 + wireshark 抓包演示 https://www.jianshu.com/p/a3a25c6627ee
前言
面试被问到有没有用过抓包工具, 还真没有... 弥补一波. 一直以来看 http 和 https 的介绍, 都是文章, 然后图片, 理解的也不深入. 借此一个机会, 深入理解下.
入行不久, 写的哪里不对的, 请谅解. 还望各位路过的大佬帮忙指出, 十分感谢.
软件使用
软件使用分析
我刚开始用, 哪里不对的. 望大神们见谅.
操作步骤
在官网中有很舒服的操作原理说明: https://en.wikiversity.org/wiki/Wireshark/HTTPS
安装 Wireshark
装个浏览器就行了
点击开始捕获, 右上角, 鲨鱼标志
在浏览器中输入
http://www.cnblogs.com/zhangrunhao/
或者是 https
页面渲染完成后, 点击停止捕获
在筛选栏中输入 http, 看到一个 info 是
GET /zhangrunhao/ HTTP/1.1
记录下请求的 ip. (注: 当你找不到 ip 的时候, 不要慌, 尝试 ping <域名>即可, 例如:
- ping www.cnblogs.com
- )
筛选栏中改为
ip.addr == <记录下的 ip 地址>
大概你就可以看到你想要的了.
大概了解 tcp 字段
具体的 tcp 协议的讲解, 可以参考 TCP 协议 https://www.cnblogs.com/qdhxhz/p/10267932.html
tcp 协议中的各个字段.
这篇文章中需要用到的三个字段:
sequence number: 序列号
占 4 个字节, 是本报文段所发送的数据项目组第一个字节的序号. 在 TCP 传送的数据流中, 每一个字节都有一个序号. 例如, 一报文段的序号为 300, 而且数据共 100 字节, 则下一个报文段的序号就是 400; 序号是 32bit 的无符号数, 序号到达 2^32-1 后从 0 开始.
Acknowledgment number: 确认码
占 4 字节, 是期望收到对方下次发送的数据的第一个字节的序号, 也就是期望收到的下一个报文段的首部中的序号. 确认序号应该是上次已成功收到数据字节序号 + 1. 只有 ACK 标志为 1 时, 确认序号才有效.
Flag: 标志位.(共用 6 个标志位, 我们只看需要用的几个.)
ACK: 只有当 ACK=1 时, 确认序号字段才有效
SYN:SYN=1,ACK=0 时表示请求建立一个连接, 携带 SYN 标志的 TCP 报文段为同步报文段.
FIN: 发端完成发送任务.
HTTP 协议中 TCP 握手过程
三次握手的简单建立过程: 所有的 TCP 链接都是通过三次握手开始的, 也就是客户端和服务器在发送应用数据之前, 发送一系列的数据包.
一次完整的三次握手的过程就完成了, 客户端和服务器端的数据就可以开始传输了. 需要注意的是, 客户端一旦发送完最后一个 ACK 数据包, 就立即开始发送应用数据, 但是服务器端需要等到最后一个 ACK 包接受完成才会去响应请求.
抓包看三次握手
第一次握手:
客户端向服务器发出请求建立的链接, 标志为是 SYN, 这个时候报文中的同部位 SYN=1, 然后我们的序列号也回生成好, seq=x. 这个时候, 三次握手也就开始了.
第二次握手:
服务器收到请求, 并发送给客户端确认报文. 在确认的报文中, 标志位应该为 ACK SYN, 因为此时还没有携带数据, 所以这个时候,
ack = seq(x, 客户端发送过来的那个) + 1
, 并在这条报文中初始化序列号, seq = y. 发送给客户端, 让客户端用来确认, 我们第二次握手的请求建立过程. 询问下客户端是否准备完成了.
第三次握手:
客户端收到服务器发送过来的第二次握手的 tcp 请求, 再次向服务器发送确认. 只是确认的时候, 标志为只需要是 ACK, 同时生成确认序号:
ack = y(这里的 y, 是服务器第二次握手发送过来的 seq) + 1
. 这里表示客户端, 已经准备好了.
题外话: 为什么是三次握手, 而不是两次?
因为在我们第一次客户端发送握手请求的时候, 会出现网络情况不好, 发了很久才给服务器. 服务器收到请求后, 就会发送确认收到. 后面就会一直傻傻等待客户端传数据过来, 其实不知道, 这条请求链接在客户端那边已经作废了. 从而造成资源的浪费.
抓包看四次挥手
在实际的捕获中, 只抓到三个 tcp 的数据包, 有资料讲解, 服务器给客户端确认关闭, 并向客户端发起关闭请求的的链接合并成了一个. 也就是第二和第三次挥手, 都是由服务器端发送给客户端的, 这个时候合并成了一个请求.
第一次挥手:
第一次挥手的过程, 是客户端向服务器端发起请求. 发送一个带有 FIN ACK 标志位 tcp 包. 我们可以看到这个时候 seq = 1; ack = 1. 表示, 凡是带有 FIN 标志位的 tcp 包, 都是为了告诉另一端, 我再没有数据需要传递给你了.
第二次挥手和第三次挥手:
本来, 第二次挥手是, 服务器用来确认客户端发送过来的请求的. 然后再告诉客户端, 服务器也没什么好给你的东西了. 我理解的, 这应该是一种资源的优化, 既然都是服务器发送给客户端, 如果再服务器确认之后, 确实也没有要发送的了, 就直接一起发送过去了. 变成了 seq=1, ack=2. 标志位是 FIN ACK, 其中 ack = 2 表示确认第一次挥手.
第四次挥手:
这是我们的最后一次挥手过程, 由客户端向服务器发送确认过程. 标志位 ACK, 表示, 这是一个用于确认的 tcp 包. 发送 ack(确认二三次挥手 seq + 1) = 2. 至此一次完整的 http 通信过程就全部完成了.
那么问题来了: 为什么是四次挥手, 而不是三次呢?
因为, 在挥手的过程中, 第一次挥手的时候, 客户端发送向了服务器端不需要通信的请求. 服务器端通过第二次挥手确认了收到. 但并不能保证, 服务器端再没有需要给客户端发送的信息了啊. 只是表明了, 客户端没有要发送给服务器的数据了, 服务器知道了. 但是服务器没有需要给客户端的数据, 就需要通过第三次挥手来表示. 客户端回复收到. 至此才算完完全全的完成.
HTTPS 中的 TCP 交互过程
一句话概况: 通过非对称加密的方式来传递对称加密所需要的秘钥.
我懒, 还是贴图好了(原谅我这名盗图狗), 等会我们在抓包的过程中逐步分析.
注意一点: ssl / tls 的交互过程, 是在完成我们上面的三次握手开始的.
具体的抓包分析
此过程完全参考了 Wireshark 中关于 HTTPS 的操作说明.
步骤 1: 捕获 HTTPS
打开一个新的浏览器窗口或者 tab 页.
开始捕获.
浏览器导航到
- https://en.wikiversity.org
- .
停止捕获.
关闭浏览器窗口或者 tab 页.
步骤 2: 确定你要捕获的那个流量通道
在 Wireshark 最上面的列表中观察捕获到的链接列表. 为了只观察 HTTPS 的请求, 在筛选栏中输入 ssl, 然后回车.
选择第一个带有 Client Hello 标志的 TLS 包.
观察 IP 地址.
为了观察所有这个链接的 tcp 请求, 在筛选框中输入
ip.addr == <destination>
destination 是指, 我们的 ip 地址.
说两个事:
为什么筛选 ssl, 出现大量的 tsl? tsl 是以建立在 sslV3.0 的基础上, 两者的加密算法和 Mac 算法都不一样, 而协议本身差异性不大.
我还是感觉, 命令行, 直接 ping 域名, 找 ip, 比较方便哎~
ping en.wikiversity.org
多么舒服的做法..
步骤 3: 分析 tcp 数据包
观察数据包列表, 看到最上面的三次握手. 也就是带有 (SYN, SYN ACK, ACK) 标志位的数据包.
在中间的数据框中, 观察数据包的详细信息. 这里包含了, 物理层, 网络层, 传输层的详细信息.
展开 Ethernet II, 查看以太网, 数据链路层的详细信息.
我们可以看到本机和服务器的 Mac 地址. 你可以使用 ipconfig /all 和 arp -a 进行确认
展开
Internet Protocol Version 4
这一层, 查看网络层的详情.
你可以看到你的 ip 地址, 和服务器的 ip 地址.
展开
Transmission Control Protocol
, 你可以看到传输层的详细信息.
你可以看到本机提供的端口号, 和服务器的端口号(443).
注意: 所有的 tcp 数据包, 都含有匹配的 Mac 地址, ip 地址, 端口号.
步骤 4: 分析 SSL/TLSClient Hello 数据包
双击打开, 带有 Client Hello 标识的 tsl 数据包. 这里还有, 物理层, 链路层, 网络层, 传输层, 安全传输层的信息, 这里和步骤三中的各项数据保持一致.
展开安全传输层, TLS 和握手协议, 去查看 SSL/TLS 中的详细数据.
可以观察到客户端支持的各种加密方式.
观察下一个带有 TCP ACK 标识的 tcp 数据包, 那是服务器端对于收到客户端请求的回应.
步骤 5: 分析 SSL/TLSServer Hello 数据包
双击打开, 带有 Server Hello 标识的数据包.
依照我们上面的经验, 应该清楚我们要观察
Secure Sockets Layer
, 也就数安全数据层.
这个时候, 服务器端返回了他所支持的加密方式, 是客户端所传递的一个子集. 肯定要两边都行的嘛.
步骤 6: 分析 SSL/TLS 交换证书的阶段
双击, 打开带有
Certificate, Server Key Exchange, Server Hello Done.
标识的数据包.
展开
Secure Sockets Layer
, 让我们来仔细观察安全层所携带的数据.
我们可以看到这一次 tcp 上面, tsl 的数据包含了三块: 分别是: 证书, 非对称加密的公钥(Server Key), 还有一个服务器信息结束标识.
我们可以看到证书提供的信息.
我们还可以看到我们的公钥信息!.
客户端使用证书来验证公钥和签名. 这些工作浏览器会帮助我们进行处理.
步骤 7: 客户端的秘钥交换
双击打开, 带有
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
标识的 tcp 数据包.
这一次的交互中, 客户端使用公钥对将对称加密的秘钥进行加密, 并发送给了服务器.
从抓包上来看: 具体过程应该是, 客户端的秘钥交换, 然后更改加密规范, 然后对与握手的信息进行了加密.(对于, tls 层的操作还需要深入理解, 再次不再深究. 有希望继续学习的小伙伴, 留个言, 我们一起搞起来)
步骤 8: 开始数据交互
后面就是带有 Application Data 的数据之间的传递了, 此时的数据都是经过加密的.
留个疑问, 有些交互过程带有 New Session Ticket. 标识的数据包, 服务器用来确定加密信息, 有些不带有, 还不是很清楚的具体原因. 有待学习, 有待学习.
总结
不会的地方可真多... 文章若有错误的地方, 还望大家能够帮忙指出. 大恩不言谢, 他日以身相许.
来源: http://www.bubuko.com/infodetail-2966987.html