Web安全学习笔记二 计算机网络与协议

部分来源 https://github.com/LyleMi/Learn-Web-Hacking

计算机网络协议

1.1 网络基础

1.1.1 计算机通信网的组成

计算机网络由通信子网和资源子网组成。其中通信子网负责数据的无差错和有序传递，其处理功能包括差错控制、流量控制、路由选择、网络互连等。

其中资源子网是计算机通信的本地系统环境，包括主机、终端和应用程序等， 资源子网的主要功能是用户资源配置、数据的处理和管理、软件和硬件共享以及负载 均衡等。

总的来说，计算机通信网就是一个由通信子网承载的、传输和共享资源子网的各类信息的系统。

1.1.2 通信协议

为了完成计算机之间有序的信息交换，提出了通信协议的概念，其定义是相互通信的双方（或多方）对如何进行信息交换所必须遵守的一整套规则。

协议涉及到三个要素，分别为：

• 语法：语法是用户数据与控制信息的结构与格式，以及数据出现顺序的意义
• 语义：用于解释比特流的每一部分的意义
• 时序：事件实现顺序的详细说明

1.1.3 OSI七层模型

OSI（Open System Interconnection）共分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层七层，其具体的功能如下。

1.1.3.1 物理层

• 提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性

• 通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理

• 从数据链路层接收帧，将比特流转换成底层物理介质上的信号

1.1.3.2 数据链路层

• 在物理链路的两端之间传输数据

• 在网络层实体间提供数据传输功能和控制

• 提供数据的流量控制

• 检测和纠正物理链路产生的差错

• 格式化的消息称为帧

1.1.3.3 网络层

• 负责端到端的数据的路由或交换，为透明地传输数据建立连接

• 寻址并解决与数据在异构网络间传输相关的所有问题

• 使用上面的传输层和下面的数据链路层的功能

• 格式化的消息称为分组

1.1.3.4 传输层

• 提供无差错的数据传输

• 接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地

• 在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

1.1.3.5 会话层

• 提供节点之间通信过程的协调

• 负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接

• 使用上面的表示层和下面的传输层的功能

1.1.3.6 表示层

• 提供数据格式、变换和编码转换

• 涉及正在传输数据的语法和语义

• 将消息以合适电子传输的格式编码

• 执行该层的数据压缩和加密

• 从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

1.1.3.7 应用层

• 包括各种协议，它们定义了具体的面向用户的应用：如电子邮件、文件传输等

1.1.3.8 总结

低三层模型属于通信子网，涉及为用户间提供透明连接，操作主要以每条链路（ hop-by-hop）为基础，在节点间的各条数据链路上进行通信。由网络层来控制各条链路上的通信，但要依赖于其他节点的协调操作。

高三层属于资源子网，主要涉及保证信息以正确可理解形式传送。

传输层是高三层和低三层之间的接口，它是第一个端到端的层次，保证透明的端到端连接，满足用户的服务质量（QoS）要求，并向高三层提供合适的信息形式。

1.2 UDP协议

UDP是定义用来在互连网络环境中提供数据报交换的计算机通信的协议。此协议默认是IP下层协议。此协议提供了向另一用户程序发送信息的最简便的协议机制，不需要连接确认和保护复制，所以在软件实现上比较简单，需要的内存空间比起TCP相对也小。

1.2.1 主要特点

协议开销小、效率高。
UDP是无连接的，即发送数据之前不需要建立连接。
UDP使用尽最大努力交付，即不保证可靠交付。
UDP没有拥塞控制。
UDP支持一对一、一对多、多对一和多对多交互通信。
UDP的首部开销小，只有8个字节。

1.2.2 UDP数据格式与包结构

UDP包头由4个域组成，其中每个域各占用2个字节。

• （1）源端口号（16位）：UDP数据包的发送方使用的端口号。
• （2）目标端口号（16位）：UDP数据包的接收方使用的端口号。UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和rap协议正是采用这一机制，实现对同一时刻内多项应用同时发送和接收数据的支持。
• （3）数据包长度（16位）。数据包的长度是指包括包头和数据部分在内的总的字节数。理论上，包含包头在内的数据包的最大长度为65535字节。不过，一些实际应用往往会限制数据包的大小，有时会降低到8192字节。
• （4）校验值（16位）。UDP协议使用包头中的校验值来保证数据的安全。

1.3 TCP协议

1.3.1 简介

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由RFC 793定义。

1.3.2 TCP包结构

• 源端口号（ 16 位）：它（连同源主机 IP 地址）标识源主机的一个应用进程。

• 目的端口号（ 16 位）：它（连同目的主机 IP 地址）标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。

• 顺序号（ 32 位）：用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 32 － 1 后又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN（ Initial Sequence Number ）。

• 确认号（ 32 位）：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。

• TCP 报头长度（ 4 位）：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20 字节。

• 保留位（ 6 位）：保留给将来使用，目前必须置为 0 。

• 控制位（ control flags ， 6 位）：在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为：

  • URG ：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
  • ACK ：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
  • PSH ：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
  • RST ：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
  • SYN ：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步（ synchronize ）。
  • FIN ：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。

• 窗口大小（ 16 位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个16bit 字段，因而窗口大小最大为 65535字节。

• 校验和（ 16 位）：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。

• 紧急指针（ 16 位）：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

• 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数。

• 数据： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

1.3.3 三次握手

三次握手（Three-Way Handshake）是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

第一次握手客户端将标志位 SYN 置为1，随机产生一个值 seq=s ，并将该数据包发送给服务端，客户端进入 SYN_SENT 状态，等待服务端确认。

第二次握手服务端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务端将标志位 SYN 和 ACK 都置为1，ack=s+1，随机产生一个值 seq=k ，并将该数据包发送给客户端以确认连接请求，服务端进入 SYN_RCVD 状态。

第三次握手客户端收到确认后，检查ack值是否为s+1，ACK标志位是否为1，如果正确则将标志位 ACK 置为1，ack=k+1，并将该数据包发送给服务端，服务端检查ack值是否为k+1，ACK标志位是否为1，如果正确则连接建立成功，客户端和服务端进入 ESTABLISHED 状态，完成三次握手。

1.3.4 四次挥手

四次挥手（Four-Way Wavehand）指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

第一次挥手客户端发送一个 FIN ，用来关闭客户端到服务端的数据传送，客户端进入 FIN_WAIT_1 状态。

第二次挥手服务端收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到序号+1，服务端进入 CLOSE_WAIT 状态。

第三次挥手服务端发送一个 FIN ，用来关闭服务端到客户端的数据传送，服务端进入 LAST_ACK 状态。

第四次挥手客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务端，确认序号为收到序号+1，服务端进入 CLOSED 状态，完成四次挥手。

1.3.5 拥塞控制

拥塞是指网络中报文数量过多，使得服务端来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿即出现死锁现象。

TCP采用拥塞控制算法来减少或者避免拥塞现象的发生，TCP的拥塞算法有过多种实现，包括Tahoe、Reno、NewReno、Vegas、Hybla、BIC 、CUBIC、SACK、Westwood、PRR、BBR等。

1.3.6 参考链接

UDP协议分析

TCP协议分析

RFC 793 TRANSMISSION CONTROL PROTOCOL
RFC 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
RFC 3390 Increasing TCP’s Initial Window
RFC 5681 TCP Congestion Control
TCP congestion control wik

1.4 DHCP协议

1.4.1 简介

动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) 是一个用于局域网的网络协议，位于OSI模型的应用层，使用UDP协议工作，主要用于自动分配IP地址给用户。

DHCP服务器端使用67/udp，客户端使用68/udp。DHCP运行分为四个基本过程，分别为请求IP租约、提供IP租约、选择IP租约和确认IP租约。客户端在获得了一个IP地址以后，就可以发送一个ARP请求来避免由于DHCP服务器地址池重叠而引发的IP冲突。

优点：

减少错误
减少手工配置IP地址导致的错误，如已分配的IP地址再次分配给另一设备引起的地址冲突
减少网络管理
TCP/IP配置是集中化和自动完成的，不需手工配置，集中定义全局和特定子网的TCP/IP配置
大部分路由器能转发DHCP配置请求，减少了在每个子网设置DHCP服务器的必要
客户机配置的地址变化必须经常更新，DHCP能高效而自动地进行配置

1.4.2 DHCP包结构

DHCP一共有8种报文，分别为DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。各种类型报文的基本功能如下：

• DHCP Discover
  DHCP客户端在请求IP地址时并不知道DHCP服务器的位置，因此DHCP客户端会在本地网络内以广播方式发送Discover请求报文，以发现网络中的DHCP服务器。所有收到Discover报文的DHCP服务器都会发送应答报文，DHCP客户端据此可以知道网络中存在的DHCP服务器的位置。

• DHCP Offer
  DHCP服务器收到Discover报文后，就会在所配置的地址池中查找一个合适的IP地址，加上相应的租约期限和其他配置信息（如网关、DNS服务器等），构造一个Offer报文，发送给DHCP客户端，告知用户本服务器可以为其提供IP地址。但这个报文只是告诉DHCP客户端可以提供IP地址，最终还需要客户端通过ARP来检测该IP地址是否重复。

• DHCP Request
  DHCP客户端可能会收到很多Offer请求报文，所以必须在这些应答中选择一个。通常是选择第一个Offer应答报文的服务器作为自己的目标服务器，并向该服务器发送一个广播的Request请求报文，通告选择的服务器，希望获得所分配的IP地址。另外，DHCP客户端在成功获取IP地址后，在地址使用租期过去1/2时，会向DHCP服务器发送单播Request请求报文请求续延租约，如果没有收到ACK报文，在租期过去3/4时，会再次发送广播的Request请求报文以请求续延租约。

• DHCP ACK
  DHCP服务器收到Request请求报文后，根据Request报文中携带的用户MAC来查找有没有相应的租约记录，如果有则发送ACK应答报文，通知用户可以使用分配的IP地址。

• DHCP NAK
  如果DHCP服务器收到Request请求报文后，没有发现有相应的租约记录或者由于某些原因无法正常分配IP地址，则向DHCP客户端发送NAK应答报文，通知用户无法分配合适的IP地址。
  DHCP Release
  当DHCP客户端不再需要使用分配IP地址时，就会主动向DHCP服务器发送RELEASE请求报文，告知服务器用户不再需要分配IP地址，请求DHCP服务器释放对应的IP地址。

• DHCP Decline
  DHCP客户端收到DHCP服务器ACK应答报文后，通过地址冲突检测发现服务器分配的地址冲突或者由于其他原因导致不能使用，则会向DHCP服务器发送Decline请求报文，通知服务器所分配的IP地址不可用，以期获得新的IP地址。

• DHCP Inform
  DHCP客户端如果需要从DHCP服务器端获取更为详细的配置信息，则向DHCP服务器发送Inform请求报文；DHCP服务器在收到该报文后，将根据租约进行查找到相应的配置信息后，向DHCP客户端发送ACK应答报文。目前基本上不用了。

DHCP服务的8种报文的格式是相同的，不同类型的报文只是报文中的某些字段取值不同。DHCP报文格式基于BOOTP的报文格式。下面是各字段的说明。
OP：报文的操作类型。分为请求报文和响应报文。1：请求报文，2：应答报文。即client送给server的封包，设为1，反之为2。
请求报文：DHCP Discover、DHCP Request、DHCP Release、DHCP Inform和DHCP Decline。
应答报文：DHCP Offer、DHCP ACK和DHCP NAK。
Htype：DHCP客户端的MAC地址类型。MAC地址类型其实是指明网络类型，Htype值为1时表示为最常见的以太网MAC地址类型。
Hlen：DHCP客户端的MAC地址长度。以太网MAC地址长度为6个字节，即以太网时Hlen值为6。
Hops：DHCP报文经过的DHCP中继的数目，默认为0。DHCP请求报文每经过一个DHCP中继，该字段就会增加1。没有经过DHCP中继时值为0。(若数据包需经过router传送，每站加1，若在同一网内，为0。)
Xid：客户端通过DHCP Discover报文发起一次IP地址请求时选择的随机数，相当于请求标识。用来标识一次IP地址请求过程。在一次请求中所有报文的Xid都是一样的。
Secs：DHCP客户端从获取到IP地址或者续约过程开始到现在所消耗的时间，以秒为单位。在没有获得IP地址前该字段始终为0。(DHCP客户端开始DHCP请求后所经过的时间。目前尚未使用，固定为0。)
Flags：标志位，只使用第0比特位，是广播应答标识位，用来标识DHCP服务器应答报文是采用单播还是广播发送，0表示采用单播发送方式，1表示采用广播发送方式。其余位尚未使用。(即从0-15bits，最左1bit为1时表示server将以广播方式传送封包给client。)
【注意】在客户端正式分配了IP地址之前的第一次IP地址请求过程中，所有DHCP报文都是以广播方式发送的，包括客户端发送的DHCP Discover和DHCP Request报文，以及DHCP服务器发送的DHCP Offer、DHCP ACK和DHCP NAK报文。当然，如果是由DHCP中继器转的报文，则都是以单播方式发送的。另外，IP地址续约、IP地址释放的相关报文都是采用单播方式进行发送的。
Ciaddr：DHCP客户端的IP地址。仅在DHCP服务器发送的ACK报文中显示，在其他报文中均显示0，因为在得到DHCP服务器确认前，DHCP客户端是还没有分配到IP地址的。只有客户端是Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。
Yiaddr：DHCP服务器分配给客户端的IP地址。仅在DHCP服务器发送的Offer和ACK报文中显示，其他报文中显示为0。
Siaddr：下一个为DHCP客户端分配IP地址等信息的DHCP服务器IP地址。仅在DHCP Offer、DHCP ACK报文中显示，其他报文中显示为0。(用于bootstrap过程中的IP地址)
Giaddr：DHCP客户端发出请求报文后经过的第一个DHCP中继的IP地址。如果没有经过DHCP中继，则显示为0。(转发代理（网关）IP地址)
Chaddr：DHCP客户端的MAC地址。在每个报文中都会显示对应DHCP客户端的MAC地址。
Sname：为DHCP客户端分配IP地址的DHCP服务器名称（DNS域名格式）。在Offer和ACK报文中显示发送报文的DHCP服务器名称，其他报文显示为0。
File：DHCP服务器为DHCP客户端指定的启动配置文件名称及路径信息。仅在DHCP Offer报文中显示，其他报文中显示为空。
Options：可选项字段，长度可变，格式为"代码+长度+数据"。

列出部分可选的选项：
代码1
长度(字节)：4
说明：子网掩码
代码3
长度：长度可变，必须是4个字节的倍数。
说明：默认网关（可以是一个路由器IP地址列表）
代码6
长度：长度可变，必须是4个字节的整数倍。
说明DNS服务器（可以是一个DNS服务器IP地址列表）
代码15
长度：长度可变
说明：域名称（主DNS服务器名称）
代码44
长度：长度可变，必须是4个字节的整数倍。
说明：WINS服务器（可以是一个WINS服务器IP列表）
代码51
长度：4
说明：有效租约期（以秒为单位）
代码53
长度：1
说明：报文类型
1: DHCP Discover
2: DHCP Offer
3: DHCP Request
4: DHCP Decline
5: DHCP ACK
6: DHCP NAK
7: DHCP Release
8: DHCP Inform
代码58
长度：4
说明：续约时间

包结构：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+---------------+---------------+---------------+---------------+
|                            xid (4)                            |
+-------------------------------+-------------------------------+
|           secs (2)            |           flags (2)           |
+-------------------------------+-------------------------------+
|                          ciaddr  (4)                          |
+---------------------------------------------------------------+
|                          yiaddr  (4)                          |
+---------------------------------------------------------------+
|                          siaddr  (4)                          |
+---------------------------------------------------------------+
|                          giaddr  (4)                          |
+---------------------------------------------------------------+
|                          chaddr  (16)                         |
+---------------------------------------------------------------+
|                          sname   (64)                         |
+---------------------------------------------------------------+
|                          file    (128)                        |
+---------------------------------------------------------------+
|                          options (variable)                   |
+---------------------------------------------------------------+

1.4.3 参考

DHCP Wiki

DHCP协议分析

1.5 路由算法

1.5.1 简介

路由算法是用于找到一条从源路由器到目的路由器的最佳路径的算法。存在着多种路由算法，每种算法对网络和路由器资源的影响都不同；由于路由算法使用多种度量标准 (metric)，所以不同路由算法的最佳路径选择也有所不同。

1.5.2 路由选择算法的功能

源/宿对之间的路径选择，以及选定路由之后将报文传送到它们的目的地。

路由选择算法的要求：

• 正确性：确保分组从源节点传送到目的节点
• 简单性：实现方便，软硬件开销小
• 自适应性：也称健壮性，算法能够适应业务量和网络拓扑的变化
• 稳定性：能长时间无故障运行
• 公平性：每个节点都有机会传送信息
• 最优性：尽量选取好的路由

1.5.3 自治系统 AS (Autonomous System)

经典定义：

• 由一个组织管理的一整套路由器和网络。
• 使用一种AS 内部的路由选择协议和共同的度量以确定分组在该 AS 内的路由。
• 使用一种 AS 之间的路由选择协议用以确定分组在AS之间的路由。

尽管一个 AS 使用了多种内部路由选择协议和度量，但对其他 AS 表现出的是一个单一的和一致的路由选择策略。

1.5.4 两大类路由选择协议

因特网的中，路由协议可以分为内部网关协议 IGP (Interior Gateway Protocol)和外部网关协议 EGP (External Gateway Protocol)。

IGP是在一个AS内部使用的路由选择协议，如RIP和OSPF协议，是域内路由选择 (interdomain routing)。当源主机和目的主机处在不同的AS中，在数据报到达AS的边界时，使用外部网关协议 EGP 将路由选择信息传递到另一个自治系统中，如BGP-4，是域间路由选择 (intradomain routing)。

1.5.5 RIP

路由信息协议 (Routing Information Protocol, RIP) 是一种基于距离 向量的路由选择协议。RIP 协议要求网络中的每一个路由器都要维护从它自己到自治系统内其他每一个目的网络的距离和下一跳路由器地址。

路由表的初始化 。
路由表的更新 。
对于本路由表中已有的路由项，当发送响应报文的RIP邻居相同时，不论响应报文中携带的路由项度量值是大还是小，都更新该路由项（度量值相同时只将其老化定时器清零）。
对于本路由表中已有的路由项，当发送响应报文的RIP邻居不同时，只在路由项度量值减少时，更新该路由项。
对于本路由表中不存在的路由项，在度量值小于协议规定的最大值时，在路由表中增加该路由项。
路由表的维护
rip的特性：最多 15 跳；30s一次刷新；保存25条路由信息；使用UDP协议的520端口。

1.5.6 OSPF

开放最短路径优先(Open Shortest Path First，OSPF)，这个算法名为“最短路径优先”是因为使用了 Dijkstra 提出的最短路径算法SPF，只是一个协议的名字，它并不表示其他的路由选择协议不是“最短路径优先”。

OSPF是一种典型的链路状态路由协议，运行OSPF的每一台路由器都维护一个描述AS拓扑结构的数据库，该数据库由每一个路由器的链路状态信息、路由器相连的网络状态信息、该AS的外部状态信息等组成。

1.5.7 参考

动态路由协议RIP OSPF实训

1.6 域名系统

1.6.1 简介

DNS是一个简单的请求-响应协议，是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP协议的53端口。

1.6.2 相关术语

1.6.2.1 mDNS

Multicast DNS (mDNS)，多播DNS，使用5353端口，组播地址为 224.0.0.251 或 [FF02::FB] 。在一个没有常规DNS服务器的小型网络内可以使用mDNS来实现类似DNS的编程接口、包格式和操作语义。mDNS协议的报文与DNS的报文结构相同，但有些字段对于mDNS来说有新的含义。

启动mDNS的主机会在进入局域网后向所有主机组播消息，包含主机名、IP等信息，其他拥有相应服务的主机也会响应含有主机名和IP的信息。

mDNS的域名是用 .local 和普通域名区分开的。

1.6.2.2 FQDN

FQDN (Fully-Qualified Domain Name) 是域名的完全形态，主要是包含零长度的根标签，例如 www.example.com. 。

1.6.2.3 TLD

Top-Level Domain (TLD) 是属于根域的一个域，例如 com 或 jp 。

TLD一般可以分为 Country Code Top-Level Domains (ccTLDs) 、Generic Top-Level Domains (gTLDs) 以及其它。

1.6.2.4 IDN

Internationalized Domain Names for Applications (IDNA) 是为了处理非ASCII字符的情况。

1.6.2.5 CNAME

CNAME即Canonical name，又称alias，将域名指向另一个域名。

1.6.2.6 TTL

Time To Live，无符号整数，记录DNS记录过期的时间，最小是0，最大是2147483647 (2^31 - 1)。

1.6.3 请求响应

1.6.3.1 DNS记录

• A记录
  • 返回域名对于IPv4地址
• NS记录
  • 域名服务器
  • 返回该域名由那台域名服务器解析
• PTR记录
  • 反向记录
  • 从IP地址到域名的记录
• MX记录
  • 电子邮件交换记录
  • 记录邮件域名对应的IP地址

1.6.3.2 响应码

• NOERROR

No error condition

• FORMERR

Format error - The name server was unable to interpret the query

• SERVFAIL

Server failure - The name server was unable to process this query due to a problem with the name server

• NXDOMAIN

this code signifies that the domain name referenced in the query does not exist

• NOTIMP

Not Implemented - The name server does not support the requested kind of query

• REFUSED

Refused - The name server refuses to perform the specified operation for policy reasons

• NODATA

A pseudo RCODE which indicates that the name is valid, for the given class, but [there] are no records of the given type A NODATA response has to be inferred from the answer.

1.6.4 域名系统工作原理

1.6.4.1 解析过程

DNS解析过程是递归查询的，具体过程如下：

• 用户要访问域名www.example.com时，先查看本机hosts是否有记录或者本机是否有DNS缓存，如果有，直接返回结果，否则向递归服务器查询该域名的IP地址
• 递归缓存为空时，首先向根服务器查询com顶级域的IP地址
• 根服务器告知递归服务器com顶级域名服务器的IP地址
• 递归向com顶级域名服务器查询负责example.com的权威服务器的IP
• com顶级域名服务器返回相应的IP地址
• 递归向example.com的权威服务器查询www.example.com的地址记录
• 权威服务器告知www.example.com的地址记录
• 递归服务器将查询结果返回客户端

1.6.4.2 域传送

DNS服务器可以分为主服务器、备份服务器和缓存服务器。域传送是指备份服务器从主服务器拷贝数据，并使用得到的数据更新自身数据库。域传送是在主备服务器之间同步数据库的机制。

1.6.5 服务器类型

1.6.5.1 根服务器

根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。

根服务器在域名树中代表最顶级的 . 域， 一般省略。

13台IPv4根服务器的域名标号为a到m，即a.root-servers.org到m.root-servers.org，所有服务器存储的数据相同，仅包含ICANN批准的TLD域名权威信息。

1.6.5.2 权威服务器

权威服务器上存储域名Zone文件，维护域内域名的权威信息，递归服务器可以从权威服务器获得DNS查询的资源记录。

权威服务器需要在所承载的域名所属的TLD管理局注册，同一个权威服务器可以承载不同TLD域名，同一个域也可以有多个权威服务器。

1.6.5.3 递归服务器

递归服务器负责接收用户的查询请求，进行递归查询并响应用户查询请求。在初始时递归服务器仅有记录了根域名的Hint文件。

1.6.6 DNS利用

1.6.6.1 DGA

DGA（Domain Generate Algorithm，域名生成算法）是一种利用随机字符来生成C&C域名，从而逃避域名黑名单检测的技术手段，常见于botnet中。一般来说，一个DGA域名的存活时间约在1-7天左右。

通信时，客户端和服务端都运行同一套DGA算法，生成相同的备选域名列表，当需要发动攻击的时候，选择其中少量进行注册，便可以建立通信，并且可以对注册的域名应用速变IP技术，快速变换IP，从而域名和IP都可以进行快速变化。

DGA域名有多种生成方式，根据种子类型可以分为确定性和不确定性的生成。不确定性的种子可能会选用当天的一些即时数据，如汇率信息等。

1.6.6.2 DNS隧道

DNS隧道工具将进入隧道的其他协议流量封装到DNS协议内，在隧道上传输。这些数据包出隧道时进行解封装，还原数据。

1.6.7 加密方案

作为主流的防御方案，DNS加密有五种方案，分别是 DNS-over-TLS (DoT)、DNS-over-DTLS、DNS-over-HTTPS (DoH)、DNS-over-QUIC以及DNSCrypt。

1.6.7.1 DoT

DoT方案在2016年发表于RFC7858，使用853端口。主要思想是Client和Server通过TCP协议建立TLS会话后再进行DNS传输，Client通过SSL证书验证服务器身份。

1.6.7.2 DNS-over-DTLS

DNS-over-DTLS和DoT类似，区别在于使用UDP协议而不是TCP协议。

1.6.7.3 DoH

DoH方案在发表RFC8484，使用 https://dns.example.com/dns-query{?dns} 来查询服务器的IP，复用https的443端口，流量特征比较小。DoH会对DNS服务器进行加密认证，不提供fallback选项。目前Cloudflare、Google等服务商对DoH提供了支持。

1.6.7.4 DNSCrypt

DNSCrypt使用X25519-XSalsa20Poly1305而非标准的TLS，且DNSCrypt的Client需要额外的软件，Server需要的专门的证书。

1.6.8 DNS相关漏洞

1.6.8.1 DNS劫持

DNS劫持有多种方式，比较早期的攻击方式是通过攻击域名解析服务器，或是伪造DNS响应的方法，来将域名解析到恶意的IP地址。

随着互联网应用的不断发展，出现了基于废弃记录的劫持方式。这种方式发生的场景是次级域名的解析记录指向第三方资源，而第三方资源被释放后，解析记录并没有取消，在这种场景下，可以对应申请第三方资源，以获取控制解析记录的能力。

1.6.8.2 拒绝服务

DNS服务通常会开启UDP端口，当DNS服务器拥有大量二级域NS记录时，通过DNS的UDP反射攻击可以实现高倍的拒绝服务。

1.7 HTTP协议簇

1.7.1 HTTP标准

1.7.1.1 报文格式

1.7.1.1.1 请求报文格式

<method><request-URL><version>
<headers>

<entity-body>

1.7.1.1.2 响应报文格式

<version><status><reason-phrase>
<headers>

<entity-body>

1.7.1.1.3 字段解释

• method
  • HTTP动词
  • 常见方法 ：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE
  • 扩展方法 ：LOCK / MKCOL / COPY / MOVE
• version
  • 报文使用的HTTP版本
  • 格式为 HTTP.
• url
  • /:@:/ ;?#

1.7.1.2 请求头列表

• Accept

  • 指定客户端能够接受的内容类型
  • Accept:text/plain,text/html

• Accept-Charset

  • 浏览器可以接受的字符编码集
  • Accept-Charset:ios-8859-5

• Accept-Encoding

  • 指定浏览器可以支持的web服务器返回内容压缩编码类型
  • Accept-Encoding:compress,gzip

• Accept-Language

  • 浏览器可以接受的语言
  • Accept-Language:en,zh

• Accept-Ranges

  • 可以请求网页实体的一个或多个子范围字段
  • Accept-Ranges:bytes

• Authorization

  • HTTP授权的授权证书
  • Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Cache-Control

  • 指定请求和响应遵循的缓存机制 Cache-Control: no-cache

• Connection

  • 表示是否需要持久连接 // HTTP 1.1默认进行持久连接
  • Connection: close

• Cookie

  • HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器
  • Cookie: role=admin;ssid=1

• Content-Length

  • 请求的内容长度
  • Content-Length: 348

• Content-Type

  • 请求的与实体对应的MIME信息
  • Content-Type: application/x-www-form-urlencoded

• Date

  • 请求发送的日期和时间
  • Date: Tue, 15 Nov 2010 08:12:31 GMT

• Expect

  • 请求的特定的服务器行为
  • Expect: 100-continue

• From

  • 发出请求的用户的Email
  • From: [email protected]

• Host

  • 指定请求的服务器的域名和端口号
  • Host: www.github.com

• If-Match

  • 只有请求内容与实体相匹配才有效
  • If-Match: “737060cd8c284d8af7ad3082f209582d”

• If-Modified-Since

  • 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
  • If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

• If-None-Match

  • 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
  • If-None-Match:“737060cd8c284d8af7ad3082f209582d”

• If-Range

  • 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag
  • If-Range: “737060cd8c284d8af7ad3082f209582d”

• If-Unmodified-Since

  • 只在实体在指定时间之后未被修改才请求成功
  • If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

• Max-Forwards

  • 限制信息通过代理和网关传送的时间
  • Max-Forwards: 10

• Pragma

  • 用来包含实现特定的指令
  • Pragma: no-cache

• Proxy-Authorization

  • 连接到代理的授权证书
  • Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Range

  • 只请求实体的一部分，指定范围
  • Range: bytes=500-999

• Referer

  • 先前网页的地址，当前请求网页紧随其后,即来路
  • • Referer: http://www.zcmhi.com/archives/71.html

• TE

  • 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息
  • TE: trailers,deflate;q=0.5

• Upgrade

  • 向服务器指定某种传输协议以便服务器进行转换（如果支持）
  • • Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

• User-Agent

  • User-Agent的内容包含发出请求的用户信息
  • User-Agent: Mozilla/5.0 (Linux; X11)

• Via

  • 通知中间网关或代理服务器地址，通信协议
  • Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

• Warning

  • 关于消息实体的警告信息
  • Warn: 199 Miscellaneous warning

1.7.1.3 相应头列表

• Accept-Ranges

  • 表明服务器是否支持指定范围请求及哪种类型的分段请求
  • Accept-Ranges:bytes

• Access-Control-Allow-Origin

  • 配置有权限访问资源的域
  • Access-Control-Allow-Origin:|*

• Age

  • 从原始服务器到代理缓存形成的估算时间（以秒计，非负）
  • Age:12

• Allow

  • 对某网络资源的有效的请求行为，不允许则返回405
  • Allow:GET,HEAD

• Cache-Control

  • 告诉所有的缓存机制是否可以缓存及哪种类型
  • Cache-Control:no-cache

• Content-Encoding

  • web服务器支持的返回内容压缩编码类型。
  • Content-Encoding:gzip

• Content-Language

  • 响应体的语言
  • Content-Language:en,zh

• Content-Length

  • 响应体的长度
  • Content-Length:348

• Content-Location

  • 请求资源可替代的备用的另一地址
  • Content-Location:/index.htm

• Content-MD5

  • 返回资源的MD5校验值
  • Content-MD5:Q2hlY2sgSW50ZWdyaXR5IQ==

• Content-Range

  • 在整个返回体中本部分的字节位置
  • Content-Range:bytes21010-47021/47022

• Content-Type

  • 返回内容的MIME类型
  • Content-Type:text/html;charset=utf-8

• Date

  • 原始服务器消息发出的时间
  • Date:Tue,15Nov201008:12:31GMT

• ETag

  • 请求变量的实体标签的当前值
  • ETag:“737060cd8c284d8af7ad3082f209582d”

• Expires

  • 响应过期的日期和时间
  • Expires:Thu,01Dec201016:00:00GMT

• Last-Modified

  • 请求资源的最后修改时间
  • Last-Modified:Tue,15Nov201012:45:26GMT

• Location

  • 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
  • Location:http://www.zcmhi.com/archives/94.html

• Pragma

  • 包括实现特定的指令，它可应用到响应链上的任何接收方
  • Pragma:no-cache

• Proxy-Authenticate

  • 它指出认证方案和可应用到代理的该URL上的参数
  • Proxy-Authenticate:Basic

• Refresh

  • 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）
  • Refresh:5;url=http://www.zcmhi.com/archives/94.html

• Retry-After

  • 如果实体暂时不可取，通知客户端在指定时间之后再次尝试
  • Retry-After:120

• Server

  • web服务器软件名称
  • Server:Apache/1.3.27(Unix)(Red-Hat/Linux)

• Set-Cookie

  • 设置HttpCookieSet-Cookie:UserID=JohnDoe;Max-Age=3600;Version=1

• Strict-Transport-Security

  • 设置浏览器强制使用HTTPS访问
  • max-age:x秒的时间内访问对应域名都使用HTTPS请求
  • includeSubDomains:网站的子域名也启用规则
  • Strict-Transport-Security:max-age=1000;includeSubDomains

• Trailer

  • 指出头域在分块传输编码的尾部存在Trailer:Max-Forwards

• Transfer-Encoding

  • 文件传输编码
  • Transfer-Encoding:chunked

• Vary

  • 告诉下游代理是使用缓存响应还是从原始服务器请求
  • Vary:*

• Via

  • 告知代理客户端响应是通过哪里发送的
  • Via:1.0fred,1.1nowhere.com(Apache/1.1)

• Warning

  • 警告实体可能存在的问题
  • Warning:199Miscellaneouswarning

• WWW-Authenticate

  • 表明客户端请求实体应该使用的授权方案
  • WWW-Authenticate:Basic

• X-Content-Type-Options

  • 配置禁止MIME类型嗅探
  • X-Content-Type-Options:nosniff

• X-Frame-Options

  • 配置页面是否能出现在,,,等标签中，防止点击劫持
  • • X-Frame-Options:deny

• X-XSS-Protection

  • 配置XSS防护机制
  • X-XSS-Protection:1;mode=block

1.7.1.4 HTTP状态返回代码1xx（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。

code	代码	说明
100	继续	服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
101	切换协议	请求者已要求服务器切换协议，服务器已确认并准备切换

1.7.1.5 HTTP状态返回代码 2xx （成功）

表示成功处理了请求的状态代码。

code	代码	说明
200	成功	服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201	已创建	请求成功并且服务器创建了新的资源
202	已接受	服务器已接受请求，但尚未处理
203	非授权信息	服务器已成功处理了请求，但返回的信息可能来自另一来源
204	无内容	服务器成功处理了请求，但没有返回任何内容
205	重置内容	服务器成功处理了请求，但没有返回任何内容
206	部分内容	服务器成功处理了部分GET请求

1.7.1.6 HTTP状态返回代码 3xx （重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

code	代码	说明
300	多种选择	针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301	永久移动	请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302	临时移动	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303	查看其他位置	请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304	未修改	自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305	使用代理	请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307	临时重定向	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

1.7.1.8 HTTP状态返回代码 4xx（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。

code	代码	说明
400	错误请求	服务器不理解请求的语法。
401	未授权	请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403	禁止	服务器拒绝请求。
404	未找到	服务器找不到请求的网页。
405	方法禁用	禁用请求中指定的方法。
406	不接受	无法使用请求的内容特性响应请求的网页。
407	需要代理授权	此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408	请求超时	服务器等候请求时发生超时。
409	冲突	服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410	已删除	如果请求的资源已永久删除，服务器就会返回此响应。
411	需要有效长度	服务器不接受不含有效内容长度标头字段的请求。
412	未满足前提条件	服务器未满足请求者在请求中设置的其中一个前提条件。
413	请求实体过大	服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414	请求的 URI 过长	请求的 URI（通常为网址）过长，服务器无法处理。
415	不支持的媒体类型	请求的格式不受请求页面的支持。
416	请求范围不符合要求	如果页面无法提供请求的范围，则服务器会返回此状态代码。
417	未满足期望值	服务器未满足”期望”请求标头字段的要求。

1.7.1.9 HTTP状态返回代码 5xx（服务器错误）

这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

code	代码	说明
500	服务器内部错误	服务器遇到错误，无法完成请求。
501	尚未实施	服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。
502	错误网关	服务器作为网关或代理，从上游服务器收到无效响应。
503	服务不可用	服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504	网关超时	服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505	HTTP 版本不受支持	服务器不支持请求中所用的 HTTP 协议版本。

1.7.2 HTTP 版本

1.7.1 HTTP

HTTP 是基于 TCP/IP 协议的应用层协议，主要规定了客户端和服务器之间的通信格式，默认使用80端口。

1.7.2 HTTP 0.9

HTTP 0.9最早在1991年发布，仅支持GET命令，请求格式只有简单的 GET /url ，服务端仅响应HTML，响应完毕后关闭TCP连接。

1.7.3 HTTP 1.0

1996年5月，HTTP/1.0 版本发布，丰富了传输的格式和内容，还引入了POST、HEAD两个动词。从1.0开始，必须在尾部添加协议版本。在1.0中，也引入了状态码(status code)、多字符集支持、多部分发送(multi-part type)、权限(authorization)、缓存(cache)、内容编码(content encoding)等内容。

HTTP 1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢(slow start)，所以，HTTP 1.0版本的性能比较差。

1.7.4 HTTP 1.1

1997年1月，HTTP/1.1 版本发布，进一步完善了 HTTP 协议。1.1版本主要是引入了持久连接、管道机制、Content-Length、分块传输编码等内容。管道机制即在同一个TCP连接里面，客户端可以同时发送多个请求，这样就改进了HTTP协议的效率。PUT、PATCH、HEAD、 OPTIONS、DELETE等动词方法也是在HTTP 1.1版本引入的。另外1.1版本新增了Host字段，用于指定服务器的域名，这也是后来虚拟主机得以发展的基础。

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。如果有一个请求很慢，就会阻塞后面的请求。

1.7.5 SPDY

2009年，谷歌公开了自行研发的 SPDY 协议，用于解决 HTTP/1.1 效率不高的问题，而后被当做 HTTP/2 的基础。

1.7.6 HTTP/2

2015年，HTTP/2 发布，HTTP/2是一个二进制协议，头信息和数据体都是二进制，统称为帧(frame)，帧分为头信息帧和数据帧。HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序回应。

1.7.3 HTTPS

1.7.3.1 简介

HTTPS (HyperText Transfer Protocol over Secure Socket Layer)可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL。

1.7.3.2 交互

1.7.3.2.1 证书验证阶段

• 浏览器发起 HTTPS 请求
• 服务端返回 HTTPS 证书
  • 其中证书包含：
    • 公钥
    • 公司信息
    • 域名
    • 有效期
    • 指纹
• 客户端验证证书是否合法，如果不合法则提示告警

1.7.3.2.2 数据传输阶段

• 当证书验证合法后，在本地生成随机数
• 通过公钥加密随机数，并把加密后的随机数传输到服务端
• 服务端通过私钥对随机数进行解密
• 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

1.7.3.2.3 CA

CA (Certificate Authority) 是颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

1.7.4 Cookie

1.7.4.1 简介

Cookie（复数形态Cookies），类型为「小型文本文件」，指某些网站为了辨别用户身份而储存在用户本地终端上的数据。

1.7.4.2 属性

键值对

• name：cookie的名称
• value：cookie的值
• expires：当Expires属性缺省时，表示会话性cookie（临时），在浏览器关闭时cookie失效
• max-age：max-age 可以为正数、负数、0。如果 max-age 属性为正数时，浏览器会将其持久化，当 max-age 属性为负数，则表示该 Cookie 只是一个会话性 Cookie。当 max-age 为 0 时，则会立即删除这个 Cookie。Expires 和 max-age 都存在的条件下，max-age 优先级更高。
• domain：指定Cookie的域名，默认是当前域名。domain设置时可以设置为自身及其父域，子域可以访问父域的Cookie，反之不能。
• path：指定一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送对应的 Cookie。
• secure：只能通过 HTTPS 传输。
• httponly：限制Cookie仅在HTTP传输过程中被读取，一定程度上防御XSS攻击。
• SameSite：SameSite 支持 Strict / Lax / None 三种值。Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。Lax 允许部分第三方请求携带 Cookie，主要是链接、预加载、GET 表单三种情况。Cookie 的 SameSite 属性为 None ，且设置了 Secure 时，无论是否跨站都会发送 Cookie。

1.7.4.3 WebDAV

WebDAV （Web-based Distributed Authoring and Versioning） 一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1，在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法，使应用程序可对Web Server直接读写，并支持写文件锁定、解锁，以及版本控制等功能。

支持的方法具体为：

• OPTIONS
  • 获取服务器的支持
• GET/PUT/POST/DELETE
  • 资源操作
• TRACE
  • 跟踪服务器
• HEAD
• MKCOL
  • 创建集合
• PROPFIND / PROPPATCH
• COPY / MOVE
• LOCK / UNLCOK

1.7.4.4 相关CVE与博客

• CVE-2015-1833
• CVE-2015-7326
• Cookie 的 SameSite 属性
• HTTP 协议入门
• PHP开发-会话控制

1.8 邮件协议簇

1.8.1 简介

1.8.1.1 SMTP

SMTP (Simple Mail Transfer Protocol) 是一种电子邮件传输的协议，是一组用于从源地址到目的地址传输邮件的规范。不启用SSL时端口号为25，启用SSL时端口号多为465或994。

1.8.1.2 POP3

POP3 (Post Office Protocol 3) 用于支持使用客户端远程管理在服务器上的电子邮件。不启用SSL时端口号为110，启用SSL时端口号多为995。

1.8.1.3 IMAP

IMAP (Internet Mail Access Protocol)，即交互式邮件存取协议，它是跟POP3类似邮件访问标准协议之一。不同的是，开启了IMAP后，您在电子邮件客户端收取的邮件仍然保留在服务器上，同时在客户端上的操作都会反馈到服务器上，如：删除邮件，标记已读等，服务器上的邮件也会做相应的动作。不启用SSL时端口号为143，启用SSL时端口号多为993。

1.8.2 防护策略

1.8.2.1 SPF

发件人策略框架 (Sender Policy Framework, SPF) 是一套电子邮件认证机制，用于确认电子邮件是否由网域授权的邮件服务器寄出，防止有人伪冒身份网络钓鱼或寄出垃圾邮件。SPF允许管理员设定一个DNS TXT记录或SPF记录设定发送邮件服务器的IP范围，如有任何邮件并非从上述指明授权的IP地址寄出，则很可能该邮件并非确实由真正的寄件者寄出。

1.8.2.3 DMARC

基于网域的消息认证、报告和一致性 (Domain-based Message Authentication, Reporting and Conformance, DMARC) 是电子邮件身份验证协议，用于解决在邮件栏中显示的域名和验证的域名不一致的问题。要通过 DMARC 检查，必须通过 SPF 或/和 DKIM 的身份验证，且需要标头地址中的域名必须与经过身份验证的域名一致。

1.9 SSL/TLS

1.9.1 简介

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)在1994年时设计，主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

SSL最初的几个版本(SSL 1.0、SSL2.0、SSL 3.0)由网景公司设计和维护，从3.1版本开始，SSL协议由因特网工程任务小组(IETF)正式接管，并更名为TLS(Transport Layer Security)，发展至今已有TLS 1.0、TLS1.1、TLS1.2、TLS1.3这几个版本。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

• 认证性
  • 借助数字证书认证服务端和客户端身份，防止身份伪造
• 机密性
  • 借助加密防止第三方窃听
• 完整性
  • 借助消息认证码（MAC）保障数据完整性，防止消息篡改
• 重放保护
  • 通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务端端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。 在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

1.9.2 协议

TLS 包含几个子协议，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。

1.9.2.1 记录协议

记录协议(Record Protocol)规定了 TLS 收发数据的基本单位记录(record)。

1.9.2.2 警报协议

警报协议(Alert Protocol)用于提示协议交互过程出现错误。

1.9.2.3 握手协议

握手协议(Handshake Protocol)是 TLS 里最复杂的子协议，在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。

1.9.2.4 变更密码规范协议

变更密码规范协议(Change Cipher Spec Protocol)是一个“通知”，告诉对方，后续的数据都将使用加密保护。

1.9.3 包结构与交互过程

• Record Protocol
  （记录协议）是主要的封装协议，它传输不同的高层协议和运用层数据。它从上层用户协议获取信息并且传输，执行需要的任务，例如：分片，压缩，运用MAC和加密，并且传输最终数据。它也执行反向行为，解密，确认，解压缩和重组装来获取数据。记录协议包括四个上层客户协议，Handshake（握手）协议，Alert（告警）协议，Change Cipher Spec（修改密钥说明）协议，Application Data（运用层数据）协议。
• Handshake Protocols
  握手协议负责建立和恢复SSL会话。它由三个子协议组成。
  a、Handshake Protocol（握手协议）协商SSL会话的安全参数。
  b、Alert Protocol（告警协议） 一个事务管理协议，用于在SSL对等体间传递告警信息。告警信息包括
• 1.errors（错误），
• 2.exception conditions（异常状况）例如：错误的MAC或者解密失败，
• 3.notification （通告）例如：会话终止。
  c、Change Cipher Spec Protocol（修改密钥说明）协议，用于在后续记录中通告密钥策略转换。
  Handshake protocols（握手协议）用于建立SSL客户和服务器之间的连接，这个过程由如下这几个主要任务组成：
• 1、Negotiate security capabilities（协商安全能力）：处理协议版本和加密算法。
• 2、Authentication（认证）：客户认证服务器，当然服务器也可以认证客户。
• 3、Key exchange（密钥交换）：双方交换用于产生master keys（主密钥）的密钥或信息。
• 4、Key derivation（密钥引出）：双方引出master secret（主秘密），这个主秘密用于产生用于数据加密和MAC的密钥。

1.9.3.1 Client Hello

Client Hello 由客户端发送，内容包括客户端的一个Unix时间戳(GMT Unix Time)、一些随机的字节(Random Bytes)，还包括了客户端接受的算法类型(Cipher Suites)。

1.9.3.2 Server Hello

Server Hello 由服务端发送，内容包括服务端支持的算法类型、GMT Unix Time以及Random Bytes。

1.9.3.3 Certificate

由服务端或者客户端发送，发送方会会将自己的数字证书发送给接收方，由接收方进行证书验证，如果不通过的话，接收方会中断握手的过程。一般跟在Client / Server Hello报文之后。

1.9.3.4 Server Key Exchange

由服务端发送，将自己的公钥参数传输给了客户端，一般也和Server Hello与Certificate在一个TCP报文中。

1.9.3.5 Server Hello Done

服务端发送，一般也和Server Hello、Certificate和Server Key Exchange在一个TCP报文中。

1.9.3.6 Client Key Exchange

客户端发送，向服务端发送自己的公钥参数，与服务端协商密钥。

1.9.3.7 Change Cipher Spec

客户端或者服务端发送，紧跟着Key Exchange发送，代表自己生成了新的密钥，通知对方以后将更换密钥，使用新的密钥进行通信。

1.9.3.8 Encrypted Handshake Message

客户端或者服务端发送，紧跟着Key Exchange发送。进行测试，一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方，如果密钥协商正确无误的话，对方可以正确解密。

1.9.3.9 New Session Ticket

服务端发送，表示发起会话，在一段时间之内(超时时间到来之前)，双方都以刚刚交换的密钥进行通信。从这以后，加密通信正式开始。

1.9.3.10 Application Data

使用密钥交换协议协商出来的密钥加密的应用层的数据。

1.9.3.11 Encrypted Alert

客户端或服务端发送，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据。

1.9.4 版本更新内容

1.9.4.1 TLS1.3

• 引入了PSK作为新的密钥协商机制
• 支持 0-RTT 模式，以安全性降低为代价，在建立连接时节省了往返时间
• ServerHello 之后的所有握手消息采取了加密操作，可见明文减少
• 不再允许对加密报文进行压缩、不再允许双方发起重协商
• DSA 证书不再允许在 TLS 1.3 中使用
• 删除不安全的密码算法
  • RSA 密钥传输 - 不支持前向安全性
  • CBC模式密码-易受BEAST和Lucky13攻击
  • RC4流密码-在HTTPS中使用并不安全
  • SHA-1哈希函数-建议以SHA-2取而代之
  • 任意Diffie-Hellman组-CVE-2016-0701漏洞
  • 输出密码-易受FREAK和LogJam攻击

1.9.5 子协议

SSL/TLS协议有一个高度模块化的架构，分为很多子协议，主要是：

• Handshake 协议
  • 包括协商安全参数和密码套件、服务端身份认证(客户端身份认证可选)、密钥交换
• ChangeCipherSpec 协议
  • 一条消息表明握手协议已经完成
• Alert协议
  • 对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告
• Record协议
  • 包括对消息的分段、压缩、消息认证和完整性保护、加密等

1.10 IPsec

1.10.1 简介

IPsec（IP Security）是IETF制定的三层隧道加密协议，它为Internet上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证。特定的通信方之间在IP层通过加密与数据源认证等方式，提供了以下的安全服务：

• 数据机密性（Confidentiality）
  • IPsec发送方在通过网络传输包前对包进行加密。
• 数据完整性（DataIntegrity）
  • IPsec接收方对发送方发送来的包进行认证，以确保数据在传输过程中没有被篡改。
• 数据来源认证（DataAuthentication）
  • IPsec在接收端可以认证发送IPsec报文的发送端是否合法。
• 防重放（Anti-Replay）
  • IPsec接收方可检测并拒绝接收过时或重复的报文。

1.10.2 优点

IPsec具有以下优点：

• 支持IKE（InternetKeyExchange，因特网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA的服务，简化了IPsec的使用和管理。
• 所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。
• 对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。

1.10.3 构成

IPsec由四部分内容构成：

• 负责密钥管理的Internet密钥交换协议IKE（InternetKeyExchangeProtocol）
• 负责将安全服务与使用该服务的通信流相联系的安全关联SA（SecurityAssociations）
• 直接操作数据包的认证头协议AH（IPAuthenticationHeader）和安全载荷协议ESP（IPEncapsulatingSecurityPayload）
• 若干用于加密和认证的算法

1.10.4 安全联盟（Security Association，SA）

IPsec在两个端点之间提供安全通信，端点被称为IPsec对等体。

SA是IPsec的基础，也是IPsec的本质。SA是通信对等体间对某些要素的约定，例如，使用哪种协议（AH、ESP还是两者结合使用）、协议的封装模式（传输模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保护数据的共享密钥以及密钥的生存周期等。建立SA的方式有手工配置和IKE自动协商两种。

SA是单向的，在两个对等体之间的双向通信，最少需要两个SA来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的SA。

SA由一个三元组来唯一标识，这个三元组包括SPI（Security Parameter Index，安全参数索引）、目的IP地址、安全协议号（AH或ESP）。

SPI是用于唯一标识SA的一个32比特数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。

1.10.5 IKE

IKE（RFC2407，RFC2408、RFC2409）属于一种混合型协议，由Internet安全关联和密钥管理协议（ISAKMP）和两种密钥交换协议OAKLEY与SKEME组成。IKE创建在由ISAKMP定义的框架上，沿用了OAKLEY的密钥交换模式以及SKEME的共享和密钥更新技术，还定义了它自己的两种密钥交换方式。

IKE使用了两个阶段的ISAKMP：

第一阶段，协商创建一个通信信道（IKE SA），并对该信道进行验证，为双方进一步的IKE通信提供机密性、消息完整性以及消息源验证服务； 第二阶段，使用已建立的IKE SA建立IPsec SA（V2中叫Child SA）。

1.11 Wi-Fi

1.11.1 简介

Wi-Fi又称“无线热点”或“无线网络”，是Wi-Fi联盟的商标，一个基于IEEE 802.11标准的无线局域网技术。

1.11.2 攻击

1.11.2.1 暴力破解

WiFi密码是基于预置的秘钥，可以通过抓取报文的方式在本地快速的批量进行密码爆破尝试。

1.11.2.2 伪造热点

AP可以动态的广播自己，客户也可以主动发送探针请求。可以伪造AP发送对探针请求的响应包，来让客户端错误的识别。

1.11.2.3 密钥重装攻击

该漏洞由Vanhoef发现。Wi-Fi在握手时双方会更新秘钥，该攻击通过重放握手信息，令客户端重新安装相同的秘钥。

1.11.2.4 Dragonblood

最新版的WPA3标准在实现上存在一些问题，同样由Vanhoef发现。包含拒绝服务攻击、降级攻击、侧信道泄露等。

1.11.2.5 参考链接

Wi-FiAlliance
Dragonblood:AnalyzingtheDragonflyHandshakeofWPA3andEAP-pwd
ImprovingPrivacythroughFastPassiveWi-FiScanning
PracticalSide-ChannelAttacksagainstWPA-TKIP
KeyReinstallationAttacks:BreakingtheWPA2Protocol
RFC7664DragonflyKeyExchange