宿舍上网报文分析
文章目录
-
- 一、实验环境
- 二、实验目的
- 三、实验原理
-
- 3.1 身份验证过程
- 3.2 动态主机配置（DHCP）IP
- 3.3 浏览网页
- 四、实验步骤
- 五、协议抓包分析
-
- 5.1 基于HTTP协议的身份验证包
-
- 5.1.1 DNS协议得到验证网站IP
- 5.1.2 TCP在无连接时的选择
- 5.1.3 登陆身份验证网站
- 5.2 浏览网页过程报文
-
- 5.2.1 DNS查询IP过程
- 5.2.2 TCP建立连接过程
- 5.2.3 TSLv1.2 协议 数据传输过程
一、实验环境
XUST宿舍网络，电脑用有线电缆与外接路由器相连，然后以HTTP协议为验证方式的上网方式，登陆界面如下图
二、实验目的
通过抓包分析，了解我们目前常用的上网验证方式，并对抓取的包进行分析，在分析过程中了解各协议工作机制、协议运行原理等，加深对网络协议的理解。
三、实验原理
一般来说，在以太网上想要实现用户上网，底层应为PPP协议，电信局通过基于PPPoE等协议实现对用户上网的控制与收费等。但学校因其特殊性会有所不同，而我们西安科技大学的上网方式则更加的别具一格。因此，这里就暂不研究常规上网方式，以我校上网方式为例分析。
3.1 身份验证过程
PS:下面的分析仅代表个人从所抓包得到的个人见解，不代表真实情况，如有误差，纯属作者个人理解和知识层面不够。
首先，在学校宿舍上网，并不是用的拨号上网，因为在宿舍上网，用有线电缆连接的宿舍的接口，所连接到的首先是学校的信网中心，只需要通过信网中心的基于HTTP协议的身份验证即可上网，而不必经过PPP协议的协商阶段。
由图中可以看出，当前阶段由于未授权所以只有tcp的SYN请求报文，而由于服务器端没有响应的ACK报文，因此TCP连接建立失败，同时客户端又由于没有收到ACK报文而不断重发，导致如图所示的情况。
3.2 动态主机配置（DHCP）IP
动态主机配置协议是一个局域网的网络协议。指的是由服务器控制一段 IP 地址范围，客户
机登陆服务器就可以自动获得一个服务器分配的 IP 地址和子网掩码。由于普通的家用路由器已
经默认开启了 DHCP 服务，则当客户机完成身份认证之后，该 DHCP 服务将会从 IP 地址池中
动态分配一个 IP 地址给客户机。在租用期内，客户机可以通过该 IP 地址完成与其他主机的通信
3.3 浏览网页
浏览网页的过程分析在后面具体分析，这里暂不介绍
四、实验步骤
- 用户PC在未联网的情况下打开wireshark,开始监听指定网卡的数据包。（这里监听以太网卡）
- 将连接宿舍网线接口的网线与电脑接通，确认到 IP为 202.200.48.24 的网页自动弹出并打开（
这也是我们学校宿舍上网的特色呢）。 - 在弹出的 202.200.48.24 网页中输入正确的用户名和密码，完成用户身份验证，开始上网。
- 打开浏览器，访问任意一个网站，捕获该过程的数据包。
五、协议抓包分析
5.1 基于HTTP协议的身份验证包
5.1.1 DNS协议得到验证网站IP
如上图所示，该过程完成的主要是DNS的查询与回应过程，我们以一组查询与回应为例具体分析。
如上图所示，DNS询问请求报文中标志： Flags：0x0100（standard query）
0……….….= Respone：Messsage is a query0表示为dns查询报文
.000 0…….….= opcode：standard query(0) 操作码为标准查询
.……0.….….= Truncated：message is not truncated 信息没有被截断
.……1.….….=Recursion desired：Do query recursively 执行递归查询
….…. .0………=z：reserved（0）
….….…0……=Nontheticated data：unacceptable
问题数：Question:1 只查询一个主机名
回答RR数：Answer RRS:0
权威RR数：Authority RRS:0
附加RR数：Additional RRS:0
这是DNS请求报文的首部信息
下面我们再来看看回复报文
这个首部大体和请求报文近似，图中均有所标识，重点来看回复报文的回复消息部分
正如图中所标，可以看到，由DNS回复报文，回复了，要访问的网站 events.gfe.nvidia.com 的IP地址为 8.36.80.215 ，由这个DNS返回的即可访问到该网站。
5.1.2 TCP在无连接时的选择
如上图所示，TCP依然在每隔一段时间就发送一次SYN请求连接报文，但当一直失败时，就会发送一个RST，ACK报文，用于复位相应的TCP连接。
5.1.3 登陆身份验证网站
过程大致如上图，首先通过ARP进行路由选择，然后通过UDP及TCP协议，这里可以看到TCP的3次握手，成功建立对身份验证网站的连接，可以注意到在这个身份验证网站连接过程中有数据传输，因此有一个PSH,ACK报文，详细报文格式如下。
好了，前面分析了这么多，终于到重点的身份验证报文了~~（不容易啊！！）~~，直接上报文图吧
5.2 浏览网页过程报文
5.2.1 DNS查询IP过程
由于之前已分析过DNS协议，这里就不再多加叙述。
5.2.2 TCP建立连接过程
如上图所示，是TCP的连接过程，相信大家都很清楚了，就是所谓的三次握手，我们直接看报文段吧。
5.2.3 TSLv1.2 协议 数据传输过程
这里由于中间夹杂很多杂乱的包，因此这里我们直接采用过滤只看TLSv1.2协议包，如下所示
这里展示了TLSv1.2的工作过程，下面我们来具体看各报文段。
首先看Client Hello报文段
他是客户端发送的，属于TLS握手协议（TLS handshake）的一部分，其内容包括客户端的一个Unix时间戳（GMT Unix Time）、一些随机的字节（Random Bytes），还包括了客户端接受的算法类型(Cipher Suites)，同时还有其他的扩展参数，这里就不做介绍了。
Server Hello报文段也类似，都是互相交互一些信息，用于后续的各操作。
Certificate 是服务器或者客户端发送的，依旧属于TLS handshake，它一般和Server Hello在同一个TCP报文中传送。显然的，这里服务器将自己的数字证书发送给客户端，客户端就会进行证书验证，如果不通过的话，客户端会中断握手的过程。如果也要求客户端提供证书的话，Client Hello后面也会紧跟着该报文，形式完全一样，就不再解释了。
Server Key Exchange 是服务器发送的，属于TLS handshake，一般也和Server Hello与Certificate在一个TCP报文中。服务器将自己的公钥参数传输给了客户端，因为使用的是ECDHE，这里传输的内容有：椭圆曲线域参数，以及公钥的值。
Client Key Exchange 是客户端发送的， 客户端收到了服务器的证书进行验证，如果验证通过了，就会继续密钥交换的过程，向服务器发送自己的公钥参数。待服务器收到之后进行数学计算，就可以协商出密钥了。
Change Cipher Spec 代表自己生成了新的密钥，通知对方以后将更换密钥，使用新的密钥进行通信。
Encrypted Handshake Message 是进行一下测试，一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方，如果密钥协商正确无误的话，对方应该可以解密。这段加密内容的明文一般是协议中规定好的，双方都知道。
New Session Ticket 用处就是在一段时间之内（超时时间到来之前），双方都以刚刚交换的密钥进行通信。从这以后，加密通信正式开始。
Application Data 是应用层的数据，是加密的，使用密钥交换协议协商出来的密钥加密。
至此，TLSv1.2协议的传输数据的报文就全部解析完毕。总的来说，TLSv1.2的作用就是对传输的数据做一个加密、解密等信息安全保护操作，整个协议中涉及证书认证、密钥协商以及加密传输3个部分，较好的完成了对数据的保护。