2.1. 网络基础

2.1.1. 计算机通信网的组成

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

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

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

2.1.2. 通信协议

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

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

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

2.1.3. OSI七层模型

2.1.3.1. 简介

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

2.1.3.2. 物理层

提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性
通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理
从数据链路层接收帧，将比特流转换成底层物理介质上的信号

2.1.3.3. 数据链路层

在物理链路的两端之间传输数据
在网络层实体间提供数据传输功能和控制
提供数据的流量控制
检测和纠正物理链路产生的差错
格式化的消息称为帧

2.1.3.4. 网络层

负责端到端的数据的路由或交换，为透明地传输数据建立连接
寻址并解决与数据在异构网络间传输相关的所有问题
使用上面的传输层和下面的数据链路层的功能
格式化的消息称为分组

2.1.3.5. 传输层

提供无差错的数据传输
接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地
在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

2.1.3.6. 会话层

提供节点之间通信过程的协调
负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接
使用上面的表示层和下面的传输层的功能

2.1.3.7. 表示层

提供数据格式、变换和编码转换
涉及正在传输数据的语法和语义
将消息以合适电子传输的格式编码
执行该层的数据压缩和加密
从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

2.1.3.8. 应用层

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

2.1.3.9. 总结

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

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

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

2.2. UDP协议

2.2.1. 主要特点

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

2.3. TCP协议

2.3.1. 简介

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

2.3.2. TCP状态

2.3.2.1. 三次握手

三次握手（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 状态，完成三次握手。

2.3.2.2. 四次挥手

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

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

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

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

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

2.3.3. 拥塞控制

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

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

2.3.4. 参考链接

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 wiki

2.4. DHCP协议

2.4.1. 简介

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

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

2.4.2. DCHP 报文格式

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) |+---------------------------------------------------------------+

2.4.3. 参考链接

DHCP Wiki

2.4.3.1. RFC

RFC 2131 Dynamic Host Configuration Protocol
RFC 2132 DHCP Options and BOOTP Vendor Extensions
RFC 3046 DHCP Relay Agent Information Option
RFC 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option
RFC 3442 Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
RFC 3942 Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
RFC 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
RFC 4436 Detecting Network Attachment in IPv4 (DNAv4)

2.5. 路由算法

2.5.1. 简介

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

2.5.2. 路由选择算法的功能

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

路由选择算法的要求：

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

2.5.3. 自治系统 AS (Autonomous System)

经典定义：

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

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

2.5.4. 两大类路由选择协议

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

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

2.5.5. RIP

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

2.5.6. OSPF

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

2.6. 域名系统

2.6.1. 简介

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

2.6.2. 术语

2.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 和普通域名区分开的。

2.6.2.2. FQDN

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

2.6.2.3. TLD

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

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

2.6.2.4. IDN

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

2.6.2.5. CNAME

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

2.6.2.6. TTL

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

2.6.3. 请求响应

2.6.3.1. DNS记录

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

2.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.

2.6.4. 域名系统工作原理

2.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的地址记录
递归服务器将查询结果返回客户端

2.6.4.2. 域传送

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

2.6.5. 服务器类型

2.6.5.1. 根服务器

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

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

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

2.6.5.2. 权威服务器

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

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

2.6.5.3. 递归服务器

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

2.6.6. DNS利用

2.6.6.1. DGA

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

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

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

2.6.6.2. DNS隧道

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

2.6.7. 加密方案

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

2.6.7.1. DoT

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

2.6.7.2. DNS-over-DTLS

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

2.6.7.3. DoH

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

2.6.7.4. DNS-over-QUIC

DNS-over-QUIC安全特性和DoT类似，但是性能更高，目前没有合适的软件实现。

2.6.7.5. DNSCrypt

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

2.6.8. 相关漏洞

2.6.8.1. DNS劫持

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

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

2.6.8.2. 拒绝服务

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

看到这里的大佬，动动发财的小手点赞 + 回复 + 收藏，能【关注】一波就更好了

我是一名渗透测试工程师，为了感谢读者们，我想把我收藏的一些网络安全/渗透测试学习干货贡献给大家，回馈每一个读者，希望能帮到你们。

干货主要有：

①　2000多本网安必看电子书（主流和经典的书籍应该都有了）

②　PHP标准库资料（最全中文版）

③　项目源码（四五十个有趣且经典的练手项目及源码）

④ 网络安全基础入门、Linux运维，web安全、渗透测试方面的视频（适合小白学习）

⑤ 网络安全学习路线图（告别不入流的学习）

⑥ 渗透测试工具大全

⑦ 2021网络安全/Web安全/渗透测试工程师面试手册大全

各位朋友们可以关注+评论一波然后私信【Web】即可免费获取全部资料

2.6.9. 参考链接

2.6.9.1. RFC

RFC 1034 DOMAIN NAMES CONCEPTS AND FACILITIES
RFC 1035 DOMAIN NAMES IMPLEMENTATION AND SPECIFICATION
RFC 1123 Requirements for Internet Hosts -- Application and Support
RFC 2535 Domain Name System Security Extensions
RFC 2930 Secret Key Establishment for DNS (TKEY RR)
RFC 2931 DNS Request and Transaction Signatures ( SIG(0)s )
RFC 3596 Legacy Resolver Compatibility for Delegation Signer (DS)
RFC 3755 DNS Extensions to Support IP Version 6
RFC 5001 Automated Updates of DNS Security (DNSSEC) Trust Anchors
RFC 5936 DNS Zone Transfer Protocol
RFC 5966 DNS Transport over TCP - Implementation Requirements
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
RFC 6762 Multicast DNS
RFC 6891 Extension Mechanisms for DNS (EDNS(0))
RFC 6895 DNS IANA Considerations
RFC 7766 DNS Transport over TCP - Implementation Requirements
RFC 7858 Specification for DNS over Transport Layer Security (TLS)
RFC 8082 NXDOMAIN
RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
RFC 8484 DNS Queries over HTTPS (DoH)
RFC 8490 DNS Stateful Operations
RFC 8499 DNS Terminology

2.6.9.2. 工具

Unbound
bind9

2.6.9.3. 研究文章

DGA域名的今生前世：缘起、检测、与发展
DNSSEC原理和分析
Plohmann D, Yakdan K, Klatt M, et al. A comprehensive measurement study of domain generating malware[C]//25th {USENIX} Security Symposium ({USENIX} Security 16). 2016: 263-278.
An End-to-End Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?

2.6.9.4. 相关CVE

SIGRed – Resolving Your Way into Domain Admin: Exploiting a 17 Year-old Bug in Windows DNS Servers

2.7. HTTP协议簇

内容索引:

2.7.1. HTTP标准

2.7.1.1. 报文格式
2.7.1.2. 请求头列表
2.7.1.3. 响应头列表
2.7.1.4. HTTP状态返回代码 1xx（临时响应）
2.7.1.5. HTTP状态返回代码 2xx （成功）
2.7.1.6. HTTP状态返回代码 3xx （重定向）
2.7.1.7. HTTP状态返回代码 4xx（请求错误）
2.7.1.8. HTTP状态返回代码 5xx（服务器错误）

2.7.2. HTTP 版本

2.7.2.1. HHTTP
2.7.2.2. HTTP 0.9
2.7.2.3. HTTP 1.0
2.7.2.4. HTTP 1.1
2.7.2.5. SPDY
2.7.2.6. HTTP/2

2.7.3. HTTPS

2.7.3.1. 简介
2.7.3.2. 交互
2.7.3.3. CA

2.7.4. Cookie

2.7.4.1. 简介
2.7.4.2. 属性

2.7.5. WebDAV

2.7.5.1. 简介
2.7.5.2. 相关CVE

2.7.6. 参考链接

2.7.6.1. RFC
2.7.6.2. Blog

2.7.1. HTTP标准

2.7.1.1. 报文格式

2.7.1.1.1. 请求报文格式

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

2.7.1.1.2. 响应报文格式

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

2.7.1.1.3. 字段解释

method HTTP动词常见方法：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE 扩展方法：LOCK / MKCOL / COPY / MOVE
version 报文使用的HTTP版本格式为HTTP/<major>.<minor>
url <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

2.7.1.2. 请求头列表

Accept 指定客户端能够接收的内容类型 Accept: text/plain, text/html
Accept-Charset 浏览器可以接受的字符编码集 Accept-Charset: iso-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: user@email.com
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

2.7.1.3. 响应头列表

Accept-Ranges 表明服务器是否支持指定范围请求及哪种类型的分段请求 Accept-Ranges: bytes
Access-Control-Allow-Origin 配置有权限访问资源的域 Access-Control-Allow-Origin: <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: bytes 21010-47021/47022
Content-Type 返回内容的MIME类型 Content-Type: text/html; charset=utf-8
Date 原始服务器消息发出的时间 Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag 请求变量的实体标签的当前值 ETag: '737060cd8c284d8af7ad3082f209582d'
Expires 响应过期的日期和时间 Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified 请求资源的最后修改时间 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
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 设置Http Cookie Set-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.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning 警告实体可能存在的问题 Warning: 199 Miscellaneous warning
WWW-Authenticate 表明客户端请求实体应该使用的授权方案 WWW-Authenticate: Basic
X-Content-Type-Options 配置禁止MIME类型嗅探 X-Content-Type-Options: nosniff
X-Frame-Options 配置页面是否能出现在 <frame>, <iframe>, <embed>, <object> 等标签中，防止点击劫持 X-Frame-Options: deny
X-XSS-Protection 配置XSS防护机制 X-XSS-Protection: 1; mode=block

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7.2. HTTP 版本

2.7.2.1. HHTTP

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

2.7.2.2. HTTP 0.9

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

2.7.2.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版本的性能比较差。

2.7.2.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连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。如果有一个请求很慢，就会阻塞后面的请求。

2.7.2.5. SPDY

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

2.7.2.6. HTTP/2

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

2.7.3. HTTPS

2.7.3.1. 简介

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

2.7.3.2. 交互

2.7.3.2.1. 证书验证阶段

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

2.7.3.2.2. 数据传输阶段

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

2.7.3.3. CA

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

2.7.4. Cookie

2.7.4.1. 简介

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

2.7.4.2. 属性

2.7.4.2.1. name

cookie的名称。

2.7.4.2.2. value

cookie的值。

2.7.4.2.3. expires

当 Expires 属性缺省时，表示是会话性 Cookie，在用户关闭浏览器时失效。

2.7.4.2.4. max-age

max-age 可以为正数、负数、0。如果 max-age 属性为正数时，浏览器会将其持久化，当 max-age 属性为负数，则表示该 Cookie 只是一个会话性 Cookie。当 max-age 为 0 时，则会立即删除这个 Cookie。Expires 和 max-age 都存在的条件下，max-age 优先级更高。

2.7.4.2.5. domain

指定Cookie的域名，默认是当前域名。domain设置时可以设置为自身及其父域，子域可以访问父域的Cookie，反之不能。

2.7.4.2.6. path

指定一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送对应的 Cookie。

2.7.4.2.7. secure

只能通过 HTTPS 传输。

2.7.4.2.8. httponly

限制Cookie仅在HTTP传输过程中被读取，一定程度上防御XSS攻击。

2.7.4.2.9. SameSite

SameSite 支持 Strict / Lax / None 三种值。Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。Lax 允许部分第三方请求携带 Cookie，主要是链接、预加载、GET 表单三种情况。Cookie 的 SameSite 属性为 None ，且设置了 Secure 时，无论是否跨站都会发送 Cookie。

2.7.5. WebDAV

2.7.5.1. 简介

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 / UNLOCK

2.7.5.2. 相关CVE

CVE-2015-1833 Apache Jacrabbit WebDav XXE http://www.securityfocus.com/archive/1/535582
CVE-2015-7326 Milton WebDav XXE http://www.securityfocus.com/archive/1/536813

2.7.6. 参考链接

2.7.6.1. RFC

RFC 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
RFC 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
RFC 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
RFC 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
RFC 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
RFC 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH
RFC 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)

2.7.6.2. Blog

What should a hacker know about WebDav
Cookie 的 SameSite 属性
HTTP 协议入门

2.8. 邮件协议族

2.8.1. 简介

2.8.1.1. SMTP

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

2.8.1.2. POP3

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

2.8.1.3. IMAP

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

2.8.2. 防护策略

2.8.2.1. SPF

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

2.8.2.2. DKIM

域名密钥识别邮件 (DomainKeys Identified Mail, DKIM) 是一种检测电子邮件发件人地址伪造的方法。发送方会在邮件的头中插入DKIM-Signature，收件方通过查询DNS记录中的公钥来验证发件人的信息。

2.8.2.3. DMARC

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

2.8.3. 参考链接

2.8.3.1. RFC

RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
RFC 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)
RFC 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
RFC 8616 Email Authentication for Internationalized Mail
RFC 8611 Mail

2.8.3.2. 相关文档

Sender Policy Framework wikipedia
DomainKeys Identified Mail wikipedia
DMARC wikipedia

2.8.3.3. 研究文章

Composition Kills:A Case Study of Email Sender Authentication

2.9. SSL/TLS

2.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生成。在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

2.9.2. 协议

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

2.9.2.1. 记录协议

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

2.9.2.2. 警报协议

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

2.9.2.3. 握手协议

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

2.9.2.4. 变更密码规范协议

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

2.9.3. 交互过程

2.9.3.1. Client Hello

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

2.9.3.2. Server Hello

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

2.9.3.3. Certificate

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

2.9.3.4. Server Key Exchange

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

2.9.3.5. Server Hello Done

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

2.9.3.6. Client Key Exchange

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

2.9.3.7. Change Cipher Spec

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

2.9.3.8. Encrypted Handshake Message

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

2.9.3.9. New Session Ticket

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

2.9.3.10. Application Data

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

2.9.3.11. Encrypted Alert

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

2.9.4. 版本更新内容

2.9.4.1. TLS 1.3

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

2.9.5. 子协议

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

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

2.9.6. 参考链接

2.9.6.1. RFC

RFC 2246 The TLS Protocol Version 1.0
RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1
RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0
RFC 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0
RFC 7568 Deprecating Secure Sockets Layer Version 3.0
RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3

2.9.6.2. Document

Wikipedia Transport Layer Security

2.10. IPsec

2.10.1. 简介

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

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

2.10.2. 优点

IPsec具有以下优点：

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

2.10.3. 构成

IPsec由四部分内容构成：

负责密钥管理的Internet密钥交换协议IKE（Internet Key Exchange Protocol）
负责将安全服务与使用该服务的通信流相联系的安全关联SA（Security Associations）
直接操作数据包的认证头协议AH（IP Authentication Header）和安全载荷协议ESP（IP Encapsulating Security Payload）
若干用于加密和认证的算法

2.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将随机生成。

2.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）。

2.11. Wi-Fi

2.11.1. 简介

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

2.11.2. 攻击

2.11.2.1. 暴力破解

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

2.11.2.2. 伪造热点

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

2.11.2.3. 秘钥重装攻击

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

2.11.2.4. Dragonblood

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

2.11.3. 参考链接

Wi-Fi Alliance
Dragonblood : Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd
Improving Privacy through Fast Passive Wi-Fi Scanning
Practical Side-Channel Attacks against WPA-TKIP
Key Reinstallation Attacks: Breaking the WPA2 Protocol
RFC 7664 Dragonfly Key Exchange

禁欲28天！一宅男居然干出如此详细Web安全学习笔记（第二弹）