2.1. 網(wǎng)絡基礎

2.1.1. 計算機通信網(wǎng)的組成

計算機網(wǎng)絡由通信子網(wǎng)和資源子網(wǎng)組成。其中通信子網(wǎng)負責數(shù)據(jù)的無差錯和有序傳遞，其處理功能包括差錯控制、流量控制、路由選擇、網(wǎng)絡互連等。

其中資源子網(wǎng)是計算機通信的本地系統(tǒng)環(huán)境，包括主機、終端和應用程序等， 資源子網(wǎng)的主要功能是用戶資源配置、數(shù)據(jù)的處理和管理、軟件和硬件共享以及負載 均衡等。

總的來說，計算機通信網(wǎng)就是一個由通信子網(wǎng)承載的、傳輸和共享資源子網(wǎng)的各類信息的系統(tǒng)。

2.1.2. 通信協(xié)議

為了完成計算機之間有序的信息交換，提出了通信協(xié)議的概念，其定義是相互通信的雙方（或多方）對如何進行信息交換所必須遵守的一整套規(guī)則。

協(xié)議涉及到三個要素，分別為：

• 語法：語法是用戶數(shù)據(jù)與控制信息的結構與格式，以及數(shù)據(jù)出現(xiàn)順序的意義

• 語義：用于解釋比特流的每一部分的意義

• 時序：事件實現(xiàn)順序的詳細說明

2.1.3. OSI七層模型

2.1.3.1. 簡介

OSI（Open System Interconnection）共分為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層、應用層七層，其具體的功能如下。

2.1.3.2. 物理層

• 提供建立、維護和釋放物理鏈路所需的機械、電氣功能和規(guī)程等特性

• 通過傳輸介質(zhì)進行數(shù)據(jù)流(比特流)的物理傳輸、故障監(jiān)測和物理層管理

• 從數(shù)據(jù)鏈路層接收幀，將比特流轉換成底層物理介質(zhì)上的信號

2.1.3.3. 數(shù)據(jù)鏈路層

• 在物理鏈路的兩端之間傳輸數(shù)據(jù)

• 在網(wǎng)絡層實體間提供數(shù)據(jù)傳輸功能和控制

• 提供數(shù)據(jù)的流量控制

• 檢測和糾正物理鏈路產(chǎn)生的差錯

• 格式化的消息稱為幀

2.1.3.4. 網(wǎng)絡層

• 負責端到端的數(shù)據(jù)的路由或交換，為透明地傳輸數(shù)據(jù)建立連接

• 尋址并解決與數(shù)據(jù)在異構網(wǎng)絡間傳輸相關的所有問題

• 使用上面的傳輸層和下面的數(shù)據(jù)鏈路層的功能

• 格式化的消息稱為分組

2.1.3.5. 傳輸層

• 提供無差錯的數(shù)據(jù)傳輸

• 接收來自會話層的數(shù)據(jù)，如果需要，將數(shù)據(jù)分割成更小的分組，向網(wǎng)絡層傳送分組并確保分組完整和正確到達它們的目的地

• 在系統(tǒng)之間提供可靠的透明的數(shù)據(jù)傳輸,提供端到端的錯誤恢復和流量控制

2.1.3.6. 會話層

• 提供節(jié)點之間通信過程的協(xié)調(diào)

• 負責執(zhí)行會話規(guī)則（如：連接是否允許半雙工或全雙工通信）、同步數(shù)據(jù)流以及當故障發(fā)生時重新建立連接

• 使用上面的表示層和下面的傳輸層的功能

2.1.3.7. 表示層

• 提供數(shù)據(jù)格式、變換和編碼轉換

• 涉及正在傳輸數(shù)據(jù)的語法和語義

• 將消息以合適電子傳輸?shù)母袷骄幋a

• 執(zhí)行該層的數(shù)據(jù)壓縮和加密

• 從應用層接收消息，轉換格式，并傳送到會話層，該層常合并在應用層中

2.1.3.8. 應用層

• 包括各種協(xié)議，它們定義了具體的面向用戶的應用：如電子郵件、文件傳輸?shù)?/p>

2.1.3.9. 總結

低三層模型屬于通信子網(wǎng)，涉及為用戶間提供透明連接，操作主要以每條鏈路（ hop-by-hop）為基礎，在節(jié)點間的各條數(shù)據(jù)鏈路上進行通信。由網(wǎng)絡層來控制各條鏈路上的通信，但要依賴于其他節(jié)點的協(xié)調(diào)操作。

高三層屬于資源子網(wǎng)，主要涉及保證信息以正確可理解形式傳送。

傳輸層是高三層和低三層之間的接口，它是第一個端到端的層次，保證透明的端到端連接，滿足用戶的服務質(zhì)量（QoS）要求，并向高三層提供合適的信息形式。

2.2. UDP協(xié)議

2.2.1. 主要特點

• 協(xié)議開銷小、效率高。

• UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

• UDP使用盡最大努力交付，即不保證可靠交付。

• UDP沒有擁塞控制。

• UDP支持一對一、一對多、多對一和多對多交互通信。

• UDP的首部開銷小，只有8個字節(jié)。

2.3. TCP協(xié)議

2.3.1. 簡介

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由RFC 793定義。

2.3.2. TCP狀態(tài)

2.3.2.1. 三次握手

三次握手（Three-Way Handshake）是指建立一個TCP連接時，需要客戶端和服務端總共發(fā)送3個包以確認連接的建立。

第一次握手客戶端將標志位 SYN 置為1，隨機產(chǎn)生一個值 seq=s ，并將該數(shù)據(jù)包發(fā)送給服務端，客戶端進入 SYN_SENT 狀態(tài)，等待服務端確認。

第二次握手服務端收到數(shù)據(jù)包后由標志位 SYN=1 知道客戶端請求建立連接，服務端將標志位 SYN 和 ACK 都置為1，ack=s+1，隨機產(chǎn)生一個值 seq=k ，并將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求，服務端進入 SYN_RCVD 狀態(tài)。

第三次握手客戶端收到確認后，檢查ack值是否為s+1，ACK標志位是否為1，如果正確則將標志位 ACK 置為1，ack=k+1，并將該數(shù)據(jù)包發(fā)送給服務端，服務端檢查ack值是否為k+1，ACK標志位是否為1，如果正確則連接建立成功，客戶端和服務端進入 ESTABLISHED 狀態(tài)，完成三次握手。

2.3.2.2. 四次揮手

四次揮手（Four-Way Wavehand）指斷開一個TCP連接時，需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開。

第一次揮手客戶端發(fā)送一個 FIN ，用來關閉客戶端到服務端的數(shù)據(jù)傳送，客戶端進入 FIN_WAIT_1 狀態(tài)。

第二次揮手服務端收到 FIN 后，發(fā)送一個 ACK 給客戶端，確認序號為收到序號+1，服務端進入 CLOSE_WAIT 狀態(tài)。

第三次揮手服務端發(fā)送一個 FIN ，用來關閉服務端到客戶端的數(shù)據(jù)傳送，服務端進入 LAST_ACK 狀態(tài)。

第四次揮手客戶端收到 FIN 后，客戶端進入 TIME_WAIT 狀態(tài)，接著發(fā)送一個 ACK 給服務端，確認序號為收到序號+1，服務端進入 CLOSED 狀態(tài)，完成四次揮手。

2.3.3. 擁塞控制

擁塞是指網(wǎng)絡中報文數(shù)量過多，使得服務端來不及處理，以致引起這部分乃至整個網(wǎng)絡性能下降的現(xiàn)象，嚴重時甚至會導致網(wǎng)絡通信業(yè)務陷入停頓即出現(xiàn)死鎖現(xiàn)象。

TCP采用擁塞控制算法來減少或者避免擁塞現(xiàn)象的發(fā)生，TCP的擁塞算法有過多種實現(xiàn)，包括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協(xié)議

2.4.1. 簡介

動態(tài)主機配置協(xié)議 (Dynamic Host Configuration Protocol，DHCP) 是一個用于局域網(wǎng)的網(wǎng)絡協(xié)議，位于OSI模型的應用層，使用UDP協(xié)議工作，主要用于自動分配IP地址給用戶，方便管理員進行統(tǒng)一管理。

DHCP服務器端使用67/udp，客戶端使用68/udp。DHCP運行分為四個基本過程，分別為請求IP租約、提供IP租約、選擇IP租約和確認IP租約?？蛻舳嗽讷@得了一個IP地址以后，就可以發(fā)送一個ARP請求來避免由于DHCP服務器地址池重疊而引發(fā)的IP沖突。

2.4.2. DCHP 報文格式

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. 簡介

路由算法是用于找到一條從源路由器到目的路由器的最佳路徑的算法。存在著多種路由算法，每種算法對網(wǎng)絡和路由器資源的影響都不同；由于路由算法使用多種度量標準 (metric)，所以不同路由算法的最佳路徑選擇也有所不同。

2.5.2. 路由選擇算法的功能

源/宿對之間的路徑選擇，以及選定路由之后將報文傳送到它們的目的地。

路由選擇算法的要求：

• 正確性：確保分組從源節(jié)點傳送到目的節(jié)點

• 簡單性：實現(xiàn)方便，軟硬件開銷小

• 自適應性：也稱健壯性，算法能夠適應業(yè)務量和網(wǎng)絡拓撲的變化

• 穩(wěn)定性：能長時間無故障運行

• 公平性：每個節(jié)點都有機會傳送信息

• 最優(yōu)性：盡量選取好的路由

2.5.3. 自治系統(tǒng) AS (Autonomous System)

經(jīng)典定義：

• 由一個組織管理的一整套路由器和網(wǎng)絡。

• 使用一種AS 內(nèi)部的路由選擇協(xié)議和共同的度量以確定分組在該 AS 內(nèi)的路由。

• 使用一種 AS 之間的路由選擇協(xié)議用以確定分組在AS之間的路由。

盡管一個 AS 使用了多種內(nèi)部路由選擇協(xié)議和度量，但對其他 AS 表現(xiàn)出的是一個單一的和一致的路由選擇策略。

2.5.4. 兩大類路由選擇協(xié)議

因特網(wǎng)的中，路由協(xié)議可以分為內(nèi)部網(wǎng)關協(xié)議 IGP (Interior Gateway Protocol)和外部網(wǎng)關協(xié)議 EGP (External Gateway Protocol)。

IGP是在一個AS內(nèi)部使用的路由選擇協(xié)議，如RIP和OSPF協(xié)議，是域內(nèi)路由選擇 (interdomain routing)。當源主機和目的主機處在不同的AS中，在數(shù)據(jù)報到達AS的邊界時，使用外部網(wǎng)關協(xié)議 EGP 將路由選擇信息傳遞到另一個自治系統(tǒng)中，如BGP-4，是域間路由選擇 (intradomain routing)。

2.5.5. RIP

路由信息協(xié)議 (Routing Information Protocol, RIP) 是一種基于距離 向量的路由選擇協(xié)議。RIP 協(xié)議要求網(wǎng)絡中的每一個路由器都要維護從它自己到自治系統(tǒng)內(nèi)其他每一個目的網(wǎng)絡的距離和下一跳路由器地址。

2.5.6. OSPF

開放最短路徑優(yōu)先(Open Shortest Path First，OSPF)，這個算法名為“最短路徑優(yōu)先”是因為使用了 Dijkstra 提出的最短路徑算法SPF，只是一個協(xié)議的名字，它并不表示其他的路由選擇協(xié)議不是“最短路徑優(yōu)先”。

2.6. 域名系統(tǒng)

2.6.1. 簡介

DNS是一個簡單的請求-響應協(xié)議，是將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便地訪問互聯(lián)網(wǎng)。DNS使用TCP和UDP協(xié)議的53端口。

2.6.2. 術語

2.6.2.1. mDNS

Multicast DNS (mDNS)，多播DNS，使用5353端口，組播地址為 224.0.0.251 或 [FF02::FB] 。在一個沒有常規(guī)DNS服務器的小型網(wǎng)絡內(nèi)可以使用mDNS來實現(xiàn)類似DNS的編程接口、包格式和操作語義。mDNS協(xié)議的報文與DNS的報文結構相同，但有些字段對于mDNS來說有新的含義。

啟動mDNS的主機會在進入局域網(wǎng)后向所有主機組播消息，包含主機名、IP等信息，其他擁有相應服務的主機也會響應含有主機名和IP的信息。

mDNS的域名是用 .local 和普通域名區(qū)分開的。

2.6.2.2. FQDN

FQDN (Fully-Qualified Domain Name) 是域名的完全形態(tài)，主要是包含零長度的根標簽，例如 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，無符號整數(shù)，記錄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

• SERVFAIL

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

• NXDOMAIN

• NOTIMP

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

• REFUSED

• 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. 域名系統(tǒng)工作原理

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服務器可以分為主服務器、備份服務器和緩存服務器。域傳送是指備份服務器從主服務器拷貝數(shù)據(jù)，并使用得到的數(shù)據(jù)更新自身數(shù)據(jù)庫。域傳送是在主備服務器之間同步數(shù)據(jù)庫的機制。

2.6.5. 服務器類型

2.6.5.1. 根服務器

根服務器是DNS的核心，負責互聯(lián)網(wǎng)頂級域名的解析，用于維護域的權威信息，并將DNS查詢引導到相應的域名服務器。

根服務器在域名樹中代表最頂級的 . 域， 一般省略。

13臺IPv4根服務器的域名標號為a到m，即a.root-servers.org到m.root-servers.org，所有服務器存儲的數(shù)據(jù)相同，僅包含ICANN批準的TLD域名權威信息。

2.6.5.2. 權威服務器

權威服務器上存儲域名Zone文件，維護域內(nèi)域名的權威信息，遞歸服務器可以從權威服務器獲得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算法，生成相同的備選域名列表，當需要發(fā)動攻擊的時候，選擇其中少量進行注冊，便可以建立通信，并且可以對注冊的域名應用速變IP技術，快速變換IP，從而域名和IP都可以進行快速變化。

DGA域名有多種生成方式，根據(jù)種子類型可以分為確定性和不確定性的生成。不確定性的種子可能會選用當天的一些即時數(shù)據(jù)，如匯率信息等。

2.6.6.2. DNS隧道

DNS隧道工具將進入隧道的其他協(xié)議流量封裝到DNS協(xié)議內(nèi)，在隧道上傳輸。這些數(shù)據(jù)包出隧道時進行解封裝，還原數(shù)據(jù)。

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年發(fā)表于RFC7858，使用853端口。主要思想是Client和Server通過TCP協(xié)議建立TLS會話后再進行DNS傳輸，Client通過SSL證書驗證服務器身份。

2.6.7.2. DNS-over-DTLS

DNS-over-DTLS和DoT類似，區(qū)別在于使用UDP協(xié)議而不是TCP協(xié)議。

2.6.7.3. DoH

DoH方案在發(fā)表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類似，但是性能更高，目前沒有合適的軟件實現(xiàn)。

2.6.7.5. DNSCrypt

DNSCrypt使用X25519-XSalsa20Poly1305而非標準的TLS，且DNSCrypt的Client需要額外的軟件，Server需要的專門的證書。

2.6.8. 相關漏洞

2.6.8.1. DNS劫持

DNS劫持有多種方式，比較早期的攻擊方式是通過攻擊域名解析服務器，或是偽造DNS響應的方法，來將域名解析到惡意的IP地址。

隨著互聯(lián)網(wǎng)應用的不斷發(fā)展，出現(xiàn)了基于廢棄記錄的劫持方式。這種方式發(fā)生的場景是次級域名的解析記錄指向第三方資源，而第三方資源被釋放后，解析記錄并沒有取消，在這種場景下，可以對應申請第三方資源，以獲取控制解析記錄的能力。

2.6.8.2. 拒絕服務

DNS服務通常會開啟UDP端口，當DNS服務器擁有大量二級域NS記錄時，通過DNS的UDP反射攻擊可以實現(xiàn)高倍的拒絕服務。

看到這里的大佬，動動發(fā)財?shù)男∈?點贊 + 回復 + 收藏，能【 關注 】一波就更好了

我是一名滲透測試工程師，為了感謝讀者們，我想把我收藏的一些網(wǎng)絡安全/滲透測試學習干貨貢獻給大家，回饋每一個讀者，希望能幫到你們。

干貨主要有：

①　2000多本網(wǎng)安必看電子書（主流和經(jīng)典的書籍應該都有了）

②　PHP標準庫資料（最全中文版）

③　項目源碼（四五十個有趣且經(jīng)典的練手項目及源碼）

④ 網(wǎng)絡安全基礎入門、Linux運維，web安全、滲透測試方面的視頻（適合小白學習）

⑤ 網(wǎng)絡安全學習路線圖（告別不入流的學習）

⑥ 滲透測試工具大全

⑦ 2021網(wǎng)絡安全/Web安全/滲透測試工程師面試手冊大全

各位朋友們可以關注+評論一波 然后私信【W(wǎng)eb】 即可免費獲取全部資料

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域名的今生前世：緣起、檢測、與發(fā)展

• 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協(xié)議簇

內(nèi)容索引:

• 2.7.1. HTTP標準

• 2.7.1.1. 報文格式

• 2.7.1.2. 請求頭列表

• 2.7.1.3. 響應頭列表

• 2.7.1.4. HTTP狀態(tài)返回代碼 1xx（臨時響應）

• 2.7.1.5. HTTP狀態(tài)返回代碼 2xx （成功）

• 2.7.1.6. HTTP狀態(tài)返回代碼 3xx （重定向）

• 2.7.1.7. HTTP狀態(tài)返回代碼 4xx（請求錯誤）

• 2.7.1.8. HTTP狀態(tài)返回代碼 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. 請求報文格式

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 指定客戶端能夠接收的內(nèi)容類型 Accept: text/plain, text/html

• Accept-Charset 瀏覽器可以接受的字符編碼集 Accept-Charset: iso-8859-5

• Accept-Encoding 指定瀏覽器可以支持的web服務器返回內(nèi)容壓縮編碼類型 Accept-Encoding: compress, gzip

• Accept-Language 瀏覽器可接受的語言 Accept-Language: en,zh

• Accept-Ranges 可以請求網(wǎng)頁實體的一個或者多個子范圍字段 Accept-Ranges: bytes

• Authorization HTTP授權的授權證書 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Cache-Control 指定請求和響應遵循的緩存機制 Cache-Control: no-cache

• Connection 表示是否需要持久連接 // HTTP 1.1默認進行持久連接 Connection: close

• Cookie HTTP請求發(fā)送時，會把保存在該請求域名下的所有cookie值一起發(fā)送給web服務器 Cookie: role=admin;ssid=1

• Content-Length 請求的內(nèi)容長度 Content-Length: 348

• Content-Type 請求的與實體對應的MIME信息 Content-Type: application/x-www-form-urlencoded

• Date 請求發(fā)送的日期和時間 Date: Tue, 15 Nov 2010 08:12:31 GMT

• Expect 請求的特定的服務器行為 Expect: 100-continue

• From 發(fā)出請求的用戶的Email From: user@email.com

• Host 指定請求的服務器的域名和端口號 Host: www.github.com

• If-Match 只有請求內(nèi)容與實體相匹配才有效 If-Match: '737060cd8c284d8af7ad3082f209582d'

• If-Modified-Since 如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼 If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

• If-None-Match 如果內(nèi)容未改變返回304代碼，參數(shù)為服務器先前發(fā)送的Etag，與服務器回應的Etag比較判斷是否改變 If-None-Match: '737060cd8c284d8af7ad3082f209582d'

• If-Range 如果實體未改變，服務器發(fā)送客戶端丟失的部分，否則發(fā)送整個實體。參數(shù)也為Etag If-Range: '737060cd8c284d8af7ad3082f209582d'

• If-Unmodified-Since 只在實體在指定時間之后未被修改才請求成功 If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

• Max-Forwards 限制信息通過代理和網(wǎng)關傳送的時間 Max-Forwards: 10

• Pragma 用來包含實現(xiàn)特定的指令 Pragma: no-cache

• Proxy-Authorization 連接到代理的授權證書 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Range 只請求實體的一部分，指定范圍 Range: bytes=500-999

• Referer 先前網(wǎng)頁的地址，當前請求網(wǎng)頁緊隨其后,即來路 Referer: http://www.zcmhi.com/archives/71.html

• TE 客戶端愿意接受的傳輸編碼，并通知服務器接受接受尾加頭信息 TE: trailers,deflate;q=0.5

• Upgrade 向服務器指定某種傳輸協(xié)議以便服務器進行轉換（如果支持） Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

• User-Agent User-Agent的內(nèi)容包含發(fā)出請求的用戶信息 User-Agent: Mozilla/5.0 (Linux; X11)

• Via 通知中間網(wǎng)關或代理服務器地址，通信協(xié)議 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 對某網(wǎng)絡資源的有效的請求行為，不允許則返回405 Allow: GET, HEAD

• Cache-Control 告訴所有的緩存機制是否可以緩存及哪種類型 Cache-Control: no-cache

• Content-Encoding web服務器支持的返回內(nèi)容壓縮編碼類型。 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 在整個返回體中本部分的字節(jié)位置 Content-Range: bytes 21010-47021/47022

• Content-Type 返回內(nèi)容的MIME類型 Content-Type: text/html; charset=utf-8

• Date 原始服務器消息發(fā)出的時間 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 包括實現(xiàn)特定的指令，它可應用到響應鏈上的任何接收方 Pragma: no-cache

• Proxy-Authenticate 它指出認證方案和可應用到代理的該URL上的參數(shù) Proxy-Authenticate: Basic

• Refresh 應用于重定向或一個新的資源被創(chuàng)造，在5秒之后重定向（由網(wǎng)景提出，被大部分瀏覽器支持） 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秒的時間內(nèi) 訪問對應域名都使用HTTPS請求 includeSubDomains: 網(wǎng)站的子域名也啟用規(guī)則 Strict-Transport-Security: max-age=1000; includeSubDomains

• Trailer 指出頭域在分塊傳輸編碼的尾部存在 Trailer: Max-Forwards

• Transfer-Encoding 文件傳輸編碼 Transfer-Encoding:chunked

• Vary 告訴下游代理是使用緩存響應還是從原始服務器請求 Vary: *

• Via 告知代理客戶端響應是通過哪里發(fā)送的 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 配置頁面是否能出現(xiàn)在 <frame>, <iframe>, <embed>, <object> 等標簽中，防止點擊劫持 X-Frame-Options: deny

• X-XSS-Protection 配置XSS防護機制 X-XSS-Protection: 1; mode=block

2.7.1.4. HTTP狀態(tài)返回代碼 1xx（臨時響應）

表示臨時響應并需要請求者繼續(xù)執(zhí)行操作的狀態(tài)代碼。

2.7.1.5. HTTP狀態(tài)返回代碼 2xx （成功）

表示成功處理了請求的狀態(tài)代碼。

2.7.1.6. HTTP狀態(tài)返回代碼 3xx （重定向）

表示要完成請求，需要進一步操作。 通常，這些狀態(tài)代碼用來重定向。

2.7.1.7. HTTP狀態(tài)返回代碼 4xx（請求錯誤）

這些狀態(tài)代碼表示請求可能出錯，妨礙了服務器的處理。

2.7.1.8. HTTP狀態(tài)返回代碼 5xx（服務器錯誤）

這些狀態(tài)代碼表示服務器在嘗試處理請求時發(fā)生內(nèi)部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。

2.7.2. HTTP 版本

2.7.2.1. HHTTP

HTTP 是基于 TCP/IP 協(xié)議的應用層協(xié)議，主要規(guī)定了客戶端和服務器之間的通信格式，默認使用80端口。

2.7.2.2. HTTP 0.9

HTTP 0.9最早在1991年發(fā)布，僅支持GET命令，請求格式只有簡單的 GET /url ，服務端僅響應HTML，響應完畢后關閉TCP連接。

2.7.2.3. HTTP 1.0

1996年5月，HTTP/1.0 版本發(fā)布，豐富了傳輸?shù)母袷胶蛢?nèi)容，還引入了POST、HEAD兩個動詞。從1.0開始，必須在尾部添加協(xié)議版本。在1.0中，也引入了狀態(tài)碼(status code)、多字符集支持、多部分發(fā)送(multi-part type)、權限(authorization)、緩存(cache)、內(nèi)容編碼(content encoding)等內(nèi)容。

HTTP 1.0 版的主要缺點是，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。

TCP連接的新建成本很高，因為需要客戶端和服務器三次握手，并且開始時發(fā)送速率較慢(slow start)，所以，HTTP 1.0版本的性能比較差。

2.7.2.4. HTTP 1.1

1997年1月，HTTP/1.1 版本發(fā)布，進一步完善了 HTTP 協(xié)議。1.1版本主要是引入了持久連接、管道機制、Content-Length、分塊傳輸編碼等內(nèi)容。管道機制即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求，這樣就改進了HTTP協(xié)議的效率。PUT、PATCH、HEAD、 OPTIONS、DELETE等動詞方法也是在HTTP 1.1版本引入的。另外1.1版本新增了Host字段，用于指定服務器的域名，這也是后來虛擬主機得以發(fā)展的基礎。

雖然1.1版允許復用TCP連接，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進行的。服務器只有處理完一個回應，才會進行下一個回應。如果有一個請求很慢，就會阻塞后面的請求。

2.7.2.5. SPDY

2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，用于解決 HTTP/1.1 效率不高的問題，而后被當做 HTTP/2 的基礎。

2.7.2.6. HTTP/2

2015年，HTTP/2 發(fā)布，HTTP/2是一個二進制協(xié)議，頭信息和數(shù)據(jù)體都是二進制，統(tǒng)稱為幀(frame)，幀分為頭信息幀和數(shù)據(jù)幀。HTTP/2 復用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應，而且不用按照順序回應。

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. 證書驗證階段

• 瀏覽器發(fā)起 HTTPS 請求

• 服務端返回 HTTPS 證書 其中證書包含： 頒發(fā)機構信息 公鑰 公司信息 域名 有效期 指紋

• 客戶端驗證證書是否合法，如果不合法則提示告警

2.7.3.2.2. 數(shù)據(jù)傳輸階段

• 當證書驗證合法后，在本地生成隨機數(shù)

• 通過公鑰加密隨機數(shù)，并把加密后的隨機數(shù)傳輸?shù)椒斩?/p>

• 服務端通過私鑰對隨機數(shù)進行解密

• 服務端通過客戶端傳入的隨機數(shù)構造對稱加密算法，對返回結果內(nèi)容進行加密后傳輸

2.7.3.3. CA

CA (Certificate Authority) 是頒發(fā)數(shù)字證書的機構。是負責發(fā)放和管理數(shù)字證書的權威機構，并作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。

2.7.4. Cookie

2.7.4.1. 簡介

Cookie（復數(shù)形態(tài)Cookies），類型為「小型文本文件」，指某些網(wǎng)站為了辨別用戶身份而儲存在用戶本地終端上的數(shù)據(jù)。

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 可以為正數(shù)、負數(shù)、0。如果 max-age 屬性為正數(shù)時，瀏覽器會將其持久化，當 max-age 屬性為負數(shù)，則表示該 Cookie 只是一個會話性 Cookie。當 max-age 為 0 時，則會立即刪除這個 Cookie。Expires 和 max-age 都存在的條件下，max-age 優(yōu)先級更高。

2.7.4.2.5. domain

指定Cookie的域名，默認是當前域名。domain設置時可以設置為自身及其父域，子域可以訪問父域的Cookie，反之不能。

2.7.4.2.6. path

指定一個 URL 路徑，這個路徑必須出現(xiàn)在要請求的資源的路徑中才可以發(fā)送對應的 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，跨站點時，任何情況下都不會發(fā)送 Cookie。Lax 允許部分第三方請求攜帶 Cookie，主要是鏈接、預加載、GET 表單三種情況。Cookie 的 SameSite 屬性為 None ，且設置了 Secure 時，無論是否跨站都會發(fā)送 Cookie。

2.7.5. WebDAV

2.7.5.1. 簡介

WebDAV （Web-based Distributed Authoring and Versioning） 一種基于 HTTP 1.1協(xié)議的通信協(xié)議。它擴展了HTTP 1.1，在GET、POST、HEAD等幾個HTTP標準方法以外添加了一些新的方法，使應用程序可對Web Server直接讀寫，并支持寫文件鎖定、解鎖，以及版本控制等功能。

支持的方法具體為：

• OPTIONS 獲取服務器的支持

• GET / PUT / POST / DELETE 資源操作

• TRACE 跟蹤服務器

• HEAD

• MKCOL 創(chuàng)建集合

• 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 協(xié)議入門

2.8. 郵件協(xié)議族

2.8.1. 簡介

2.8.1.1. SMTP

SMTP (Simple Mail Transfer Protocol) 是一種電子郵件傳輸?shù)膮f(xié)議，是一組用于從源地址到目的地址傳輸郵件的規(guī)范。不啟用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)，即交互式郵件存取協(xié)議，它是跟POP3類似郵件訪問標準協(xié)議之一。不同的是，開啟了IMAP后，您在電子郵件客戶端收取的郵件仍然保留在服務器上，同時在客戶端上的操作都會反饋到服務器上，如：刪除郵件，標記已讀等，服務器上的郵件也會做相應的動作。不啟用SSL時端口號為143，啟用SSL時端口號多為993。

2.8.2. 防護策略

2.8.2.1. SPF

發(fā)件人策略框架 (Sender Policy Framework, SPF) 是一套電子郵件認證機制，用于確認電子郵件是否由網(wǎng)域授權的郵件服務器寄出，防止有人偽冒身份網(wǎng)絡釣魚或寄出垃圾郵件。SPF允許管理員設定一個DNS TXT記錄或SPF記錄設定發(fā)送郵件服務器的IP范圍，如有任何郵件并非從上述指明授權的IP地址寄出，則很可能該郵件并非確實由真正的寄件者寄出。

2.8.2.2. DKIM

域名密鑰識別郵件 (DomainKeys Identified Mail, DKIM) 是一種檢測電子郵件發(fā)件人地址偽造的方法。發(fā)送方會在郵件的頭中插入DKIM-Signature，收件方通過查詢DNS記錄中的公鑰來驗證發(fā)件人的信息。

2.8.2.3. DMARC

基于網(wǎng)域的消息認證、報告和一致性 (Domain-based Message Authentication, Reporting and Conformance, DMARC) 是電子郵件身份驗證協(xié)議，用于解決在郵件欄中顯示的域名和驗證的域名不一致的問題。要通過 DMARC 檢查，必須通過 SPF 或/和 DKIM 的身份驗證，且需要標頭地址中的域名必須與經(jīng)過身份驗證的域名一致。

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，安全套接字層，它是由網(wǎng)景公司(Netscape)在1994年時設計，主要用于Web的安全傳輸協(xié)議，目的是為網(wǎng)絡通信提供機密性、認證性及數(shù)據(jù)完整性保障。如今，SSL已經(jīng)成為互聯(lián)網(wǎng)保密通信的工業(yè)標準。

SSL最初的幾個版本(SSL 1.0、SSL2.0、SSL 3.0)由網(wǎng)景公司設計和維護，從3.1版本開始，SSL協(xié)議由因特網(wǎng)工程任務小組(IETF)正式接管，并更名為TLS(Transport Layer Security)，發(fā)展至今已有TLS 1.0、TLS1.1、TLS1.2、TLS1.3這幾個版本。

如TLS名字所說，SSL/TLS協(xié)議僅保障傳輸層安全。同時，由于協(xié)議自身特性(數(shù)字證書機制)，SSL/TLS不能被用于保護多跳(multi-hop)端到端通信，而只能保護點到點通信。

SSL/TLS協(xié)議能夠提供的安全目標主要包括如下幾個：

• 認證性 借助數(shù)字證書認證服務端端和客戶端身份，防止身份偽造

• 機密性 借助加密防止第三方竊聽

• 完整性 借助消息認證碼(MAC)保障數(shù)據(jù)完整性，防止消息篡改

• 重放保護 通過使用隱式序列號防止重放攻擊

為了實現(xiàn)這些安全目標，SSL/TLS協(xié)議被設計為一個兩階段協(xié)議，分為握手階段和應用階段：

握手階段也稱協(xié)商階段，在這一階段，客戶端和服務端端會認證對方身份(依賴于PKI體系，利用數(shù)字證書進行身份認證)，并協(xié)商通信中使用的安全參數(shù)、密碼套件以及MasterSecret。后續(xù)通信使用的所有密鑰都是通過MasterSecret生成。 在握手階段完成后，進入應用階段。在應用階段通信雙方使用握手階段協(xié)商好的密鑰進行安全通信。

2.9.2. 協(xié)議

TLS 包含幾個子協(xié)議，比較常用的有記錄協(xié)議、警報協(xié)議、握手協(xié)議、變更密碼規(guī)范協(xié)議等。

2.9.2.1. 記錄協(xié)議

記錄協(xié)議(Record Protocol)規(guī)定了 TLS 收發(fā)數(shù)據(jù)的基本單位記錄(record)。

2.9.2.2. 警報協(xié)議

警報協(xié)議(Alert Protocol)用于提示協(xié)議交互過程出現(xiàn)錯誤。

2.9.2.3. 握手協(xié)議

握手協(xié)議(Handshake Protocol)是 TLS 里最復雜的子協(xié)議，在握手過程中協(xié)商 TLS 版本號、隨機數(shù)、密碼套件等信息，然后交換證書和密鑰參數(shù)，最終雙方協(xié)商得到會話密鑰，用于后續(xù)的混合加密系統(tǒng)。

2.9.2.4. 變更密碼規(guī)范協(xié)議

變更密碼規(guī)范協(xié)議(Change Cipher Spec Protocol)是一個“通知”，告訴對方，后續(xù)的數(shù)據(jù)都將使用加密保護。

2.9.3. 交互過程

2.9.3.1. Client Hello

Client Hello 由客戶端發(fā)送，內(nèi)容包括客戶端的一個Unix時間戳(GMT Unix Time)、一些隨機的字節(jié)(Random Bytes)，還包括了客戶端接受的算法類型(Cipher Suites)。

2.9.3.2. Server Hello

Server Hello 由服務端發(fā)送，內(nèi)容包括服務端支持的算法類型、GMT Unix Time以及Random Bytes。

2.9.3.3. Certificate

由服務端或者客戶端發(fā)送，發(fā)送方會會將自己的數(shù)字證書發(fā)送給接收方，由接收方進行證書驗證，如果不通過的話，接收方會中斷握手的過程。一般跟在Client / Server Hello報文之后。

2.9.3.4. Server Key Exchange

由服務端發(fā)送，將自己的公鑰參數(shù)傳輸給了客戶端，一般也和Server Hello與Certificate在一個TCP報文中。

2.9.3.5. Server Hello Done

服務端發(fā)送，一般也和Server Hello、Certificate和Server Key Exchange在一個TCP報文中。

2.9.3.6. Client Key Exchange

客戶端發(fā)送，向服務端發(fā)送自己的公鑰參數(shù)，與服務端協(xié)商密鑰。

2.9.3.7. Change Cipher Spec

客戶端或者服務端發(fā)送，緊跟著Key Exchange發(fā)送，代表自己生成了新的密鑰，通知對方以后將更換密鑰，使用新的密鑰進行通信。

2.9.3.8. Encrypted Handshake Message

客戶端或者服務端發(fā)送，緊跟著Key Exchange發(fā)送。進行測試，一方用自己的剛剛生成的密鑰加密一段固定的消息發(fā)送給對方，如果密鑰協(xié)商正確無誤的話，對方可以正確解密。

2.9.3.9. New Session Ticket

服務端發(fā)送，表示發(fā)起會話，在一段時間之內(nèi)(超時時間到來之前)，雙方都以剛剛交換的密鑰進行通信。從這以后，加密通信正式開始。

2.9.3.10. Application Data

使用密鑰交換協(xié)議協(xié)商出來的密鑰加密的應用層的數(shù)據(jù)。

2.9.3.11. Encrypted Alert

客戶端或服務端發(fā)送，意味著加密通信因為某些原因需要中斷，警告對方不要再發(fā)送敏感的數(shù)據(jù)。

2.9.4. 版本更新內(nèi)容

2.9.4.1. TLS 1.3

• 引入了PSK作為新的密鑰協(xié)商機制

• 支持 0-RTT 模式，以安全性降低為代價，在建立連接時節(jié)省了往返時間

• ServerHello 之后的所有握手消息采取了加密操作，可見明文減少

• 不再允許對加密報文進行壓縮、不再允許雙方發(fā)起重協(xié)商

• DSA 證書不再允許在 TLS 1.3 中使用

• 刪除不安全的密碼算法 RSA 密鑰傳輸 - 不支持前向安全性 CBC 模式密碼 - 易受 BEAST 和 Lucky 13 攻擊 RC4 流密碼 - 在 HTTPS 中使用并不安全 SHA-1 哈希函數(shù) - 建議以 SHA-2 取而代之 任意 Diffie-Hellman 組- CVE-2016-0701 漏洞 輸出密碼 - 易受 FREAK 和 LogJam 攻擊

2.9.5. 子協(xié)議

SSL/TLS協(xié)議有一個高度模塊化的架構，分為很多子協(xié)議，主要是：

• Handshake 協(xié)議 包括協(xié)商安全參數(shù)和密碼套件、服務端身份認證(客戶端身份認證可選)、密鑰交換

• ChangeCipherSpec 協(xié)議 一條消息表明握手協(xié)議已經(jīng)完成

• Alert 協(xié)議 對握手協(xié)議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續(xù)，只是會給出錯誤警告

• Record 協(xié)議 包括對消息的分段、壓縮、消息認證和完整性保護、加密等

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制定的三層隧道加密協(xié)議，它為Internet上傳輸?shù)臄?shù)據(jù)提供了高質(zhì)量的、可互操作的、基于密碼學的安全保證。特定的通信方之間在IP層通過加密與數(shù)據(jù)源認證等方式，提供了以下的安全服務：

• 數(shù)據(jù)機密性（Confidentiality） IPsec發(fā)送方在通過網(wǎng)絡傳輸包前對包進行加密。

• 數(shù)據(jù)完整性（Data Integrity） IPsec接收方對發(fā)送方發(fā)送來的包進行認證，以確保數(shù)據(jù)在傳輸過程中沒有被篡改。

• 數(shù)據(jù)來源認證（Data Authentication） IPsec在接收端可以認證發(fā)送IPsec報文的發(fā)送端是否合法。

• 防重放（Anti-Replay） IPsec接收方可檢測并拒絕接收過時或重復的報文。

2.10.2. 優(yōu)點

IPsec具有以下優(yōu)點：

• 支持IKE（Internet Key Exchange，因特網(wǎng)密鑰交換），可實現(xiàn)密鑰的自動協(xié)商功能，減少了密鑰協(xié)商的開銷。可以通過IKE建立和維護SA的服務，簡化了IPsec的使用和管理。

• 所有使用IP協(xié)議進行數(shù)據(jù)傳輸?shù)膽孟到y(tǒng)和服務都可以使用IPsec，而不必對這些應用系統(tǒng)和服務本身做任何修改。

• 對數(shù)據(jù)的加密是以數(shù)據(jù)包為單位的，而不是以整個數(shù)據(jù)流為單位，這不僅靈活而且有助于進一步提高IP數(shù)據(jù)包的安全性，可以有效防范網(wǎng)絡攻擊。

2.10.3. 構成

IPsec由四部分內(nèi)容構成：

• 負責密鑰管理的Internet密鑰交換協(xié)議IKE（Internet Key Exchange Protocol）

• 負責將安全服務與使用該服務的通信流相聯(lián)系的安全關聯(lián)SA（Security Associations）

• 直接操作數(shù)據(jù)包的認證頭協(xié)議AH（IP Authentication Header）和安全載荷協(xié)議ESP（IP Encapsulating Security Payload）

• 若干用于加密和認證的算法

2.10.4. 安全聯(lián)盟（Security Association，SA）

IPsec在兩個端點之間提供安全通信，端點被稱為IPsec對等體。

SA是IPsec的基礎，也是IPsec的本質(zhì)。SA是通信對等體間對某些要素的約定，例如，使用哪種協(xié)議（AH、ESP還是兩者結合使用）、協(xié)議的封裝模式（傳輸模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保護數(shù)據(jù)的共享密鑰以及密鑰的生存周期等。建立SA的方式有手工配置和IKE自動協(xié)商兩種。

SA是單向的，在兩個對等體之間的雙向通信，最少需要兩個SA來分別對兩個方向的數(shù)據(jù)流進行安全保護。同時，如果兩個對等體希望同時使用AH和ESP來進行安全通信，則每個對等體都會針對每一種協(xié)議來構建一個獨立的SA。

SA由一個三元組來唯一標識，這個三元組包括SPI（Security Parameter Index，安全參數(shù)索引）、目的IP地址、安全協(xié)議號（AH或ESP）。

SPI是用于唯一標識SA的一個32比特數(shù)值，它在AH和ESP頭中傳輸。在手工配置SA時，需要手工指定SPI的取值。使用IKE協(xié)商產(chǎn)生SA時，SPI將隨機生成。

2.10.5. IKE

IKE（RFC2407，RFC2408、RFC2409）屬于一種混合型協(xié)議，由Internet安全關聯(lián)和密鑰管理協(xié)議（ISAKMP）和兩種密鑰交換協(xié)議OAKLEY與SKEME組成。IKE創(chuàng)建在由ISAKMP定義的框架上，沿用了OAKLEY的密鑰交換模式以及SKEME的共享和密鑰更新技術，還定義了它自己的兩種密鑰交換方式。

IKE使用了兩個階段的ISAKMP：

第一階段，協(xié)商創(chuàng)建一個通信信道（IKE SA），并對該信道進行驗證，為雙方進一步的IKE通信提供機密性、消息完整性以及消息源驗證服務； 第二階段，使用已建立的IKE SA建立IPsec SA（V2中叫Child SA）。

2.11. Wi-Fi

2.11.1. 簡介

Wi-Fi又稱“無線熱點”或“無線網(wǎng)絡”，是Wi-Fi聯(lián)盟的商標，一個基于IEEE 802.11標準的無線局域網(wǎng)技術。

2.11.2. 攻擊

2.11.2.1. 暴力破解

WiFi密碼是基于預置的秘鑰，可以通過抓取報文的方式在本地快速的批量進行密碼爆破嘗試。

2.11.2.2. 偽造熱點

AP可以動態(tài)的廣播自己，客戶也可以主動發(fā)送探針請求?？梢詡卧霢P發(fā)送對探針請求的響應包，來讓客戶端錯誤的識別。

2.11.2.3. 秘鑰重裝攻擊

該漏洞由Vanhoef發(fā)現(xiàn)。Wi-Fi在握手時雙方會更新秘鑰，該攻擊通過重放握手信息，令客戶端重新安裝相同的秘鑰。

2.11.2.4. Dragonblood

最新版的WPA3標準在實現(xiàn)上存在一些問題，同樣由Vanhoef發(fā)現(xiàn)。包含拒絕服務攻擊、降級攻擊、側信道泄露等。

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