閱讀須知：筆記為閱讀《TCP IP 詳解卷1：協定》後摘抄的一些知識點，其間也有加入一些根據英文原版的自己翻譯和結合網上知識後的了解，是以有些段落之間并不能夠串聯上或者知識點與書上略有差别(基本差别不大，參考的資料屬 RFC官方文檔
)。
第十八章：安全：可擴充身份認證協定、IP安全協定、傳輸層安全、DNS安全、域名密鑰識别郵件
任何由使用者或以使用者賬号執行卻違背了使用者本身意願的軟體被稱為惡意軟體
網絡安全是一門十分廣泛及有深度的學識，而本書旨在了解TCP/IP協定族知識，是以書中隻介紹了一些TCP/IP所使用的部分安全方案。并且對安全這塊我也沒多少深入的研究，也就基于書本内容做些知識摘抄以供了解和學習。
資訊安全基礎
從資訊安全的角度看，無論是否在計算機網絡中，資訊都該具有一些屬性：
1. 機密性，資訊隻能為其指定的使用者知曉。
2. 完整性，資訊在傳輸完成之前不能夠通過未授權的方式修改。
3. 可用性，在需要的使用資訊是可用的。
4. 可認證性，一個經過身份認證的組織或個體是不能夠被其他個體假冒的。
5. 不可抵賴性，一個個體做出的任何行為都能夠在此之後得到證明。
6. 可審計性，一些可信的日志或說明能夠面試資訊使用的過程。
前三者是重要的核心屬性，又稱'CIA三元組'。
根據[VK83]，攻擊通常被分為被動和主動兩類。被動攻擊一般會監視或竊聽網絡流量的内容，如果不加以控制，它将會導緻資訊未經授權就釋出出去，這破壞了資訊的機密性。主動攻擊一般會篡改資訊或使其拒絕服務，這破壞了資訊的完整性和可用性。
被動攻擊：
竊聽(機密性)
流量分析(機密性)
主動攻擊：
消息流篡改(可認證性，完整性)
拒絕服務DoS(可用性)
僞造機構(可認證性)
通過加密機制，即可滿足以上兩種攻擊的防禦需求，通過加密後的資料不容易洩露資訊内容、不容易破壞其完整性、也更安全的保障了可認證性。
基礎的加密和相關知識
傳統的基礎加密主要用于保護資訊的機密性，但其他屬性如完整性和可認證性也能夠借助加密以及相關的數學技術達到。下面的圖說明了兩個重要的加密算法：對稱密鑰和公開(非對稱)密鑰是如何工作的。
在對稱密碼系統中，由于加解密的算法相同，它們的密鑰也是相同的。
在非對稱密碼系統中，每一個個體都擁有一對密鑰，包括一個公鑰和一個私鑰。公鑰是公開的，任何希望向這對私鑰所有者發送消息的人都能夠獲得。公鑰和私鑰有數學上的關聯，它們都是密鑰生成算法的輸出結果。如果不知道對稱密碼系統中的對稱密鑰或非對稱密碼系統中的私鑰，任何第三方截獲密文後都無法生成相應的明文。
對稱密碼算法通常被分為分組密碼(或稱塊密碼)與流密碼兩類。分組密碼每次隻對固定數目的比特塊進行操作，而流密碼将提供的大量比特作為輸入并且會持續的運作下去。多年來流行的對稱密碼算法是資料加密标準(DES，是一種分組密碼，使用64比特的資料塊與56位的密鑰)。該算法最終被認為不安全，後期采用3重DES利用兩個或三個不同密鑰對每一個資料塊進行三次DES加密。但無論DES還是3DES，現在都逐漸被進階加密标準(AES)所取代[FIPS197]。AES針對不同版本所提供的密鑰長度，如128位、192位、256位，于是就有了AES-128、AES-192、AES-256。
如上圖，非對稱密碼算法存在一個問題：發送者使用接收者的公鑰進行消息加密後發給接收者，那麼隻能擁有接收者私鑰才能夠對消息進行解密，然而這個消息不能保證是真實可靠的(因為任何人都能夠發送這條消息給接收者)。于是基于非對稱加密的公鑰-密鑰的關聯性，非對稱密碼系統提供了另一項功能：對發送者進行認證。
該功能由将公鑰加密和私鑰解密反向操作而實作，如下圖：
流行的公鑰密碼算法如RSA，在其初始化階段，需要生成兩個大素數p和q。這項工作首先需要随機地生成數值較大的奇數，後檢驗這些數是否為素數，直到找到兩個大素數為止。兩個素數的乘積 n = pq 被稱為模。n，p，q的長度一般用比特來衡量。推薦n采用2048比特的長度，但通常情況下n為1024比特，p和q的長度為512比特。
根據RSA算法，n的建構方法為：
Φ(n) = (q - 1)(p - 1) Φ(n)的值表示n的歐拉數，是那些比n小且與n互質的正整數的個數。
根據Φ(n)的定義，選擇RSA的公鑰指數(稱為e，表示加密)，并按照關系式d = e(^-1)(modΦ(n))得到私鑰指數(稱為d，表示解密)作為乘法逆元素。為擷取密文c，需要使用公式m = m(^e)(mod n)對明文m進行計算；反之則需要公式m = c(^d)(mod n)進行解密。一個RSA的公鑰包含公鑰指數e和模n，對應的私有則包含私鑰指數d和模n。如果為了對一條消息m進行RSA數字簽名，可以通過公式s = m(^d)(mod n)計算s的數值作為m的簽名。任何接收到s的人能夠使用公有元素e與公式m = s(^e)(mod n)進行檢驗，這樣就能夠驗證生成數值s的是RSA的私有值d。RSA的安全性是基于對大數分解因數的困難性。
Diffie-Hellman-Merkle 密鑰協商協定(DH)提供了一種解決"通信雙方如何在竊聽者不知情的情況下完成共同密鑰協商"的計算方法，DH技術已用于許多與網際網路相關的安全協定[RFC2631]。
DH的工作如下描述：
1. 假設所有人都有相同的特征，并且知道兩個證書p和q。p是一個(大)素數，g是模p的原根(g<p)。
2. 基于1，集合Z(_p) = {1,...,p-1}中的每一個整數都能夠通過不斷地增加g來生成，也就是說對于任意一個證書n，必定存在倍數k使式子g(^k) ≡ n(mod p)成立。在給定g、n與p的情況下尋找合适的k值被認為是一件困難的事(離散對數問題)，在給定g、k與p的情況下找出n是容易的。
建立一個共享的安全密鑰過程如下(A和B之間)：
1. A選擇一個秘密的随機數a，并按照公式 A = g(^a)(mod p)計算出A的值，然後将這個值發送給B；B選擇一個秘密的随機數b，并按照公式 B = g(^b)(mod p)計算出B的值，然後将這個值發送給A。
2. A将按照以下公式計算K值：K = B(^a)(mod p) = g(^ba)(mod p)；B将按照以下公式計算K值：K = A(^b)(mod p) = g(^ab)(mod p)。
由于g(^ab)和g(^ba)是相等的，是以A和B都能獲得協商密鑰K。第三方竊聽者隻能擷取g、p、A、B，是以在解決離散對數問題之前将無法擷取密鑰K。
在通信雙方需要交換多條消息的場景中，通常會建立一個短期的會話密鑰來進行對稱加密。會話密鑰一般由密鑰派生函數(KDF)根據一些輸入而生成的随機數，這些輸入可能是一個主密鑰或之前的會話密鑰。如果一個密鑰被破解，那麼由該密鑰加密的任何資料都會被破解，然而在一個持續的通信會話期間，往往會多次更改密鑰。如果一種方案能夠保證即使有一個會話密鑰被破解而由其他密鑰加密的後續通信過程仍然安全，那麼就稱該方案是完全正向保密(PFS)的。通常情況下能夠提供完全正向保密的方案需要額外的密鑰交換與認證過程，這樣就引入了新的開銷。
加密随機數是在密碼協定中隻使用一次的數值(又稱臨時密鑰)。常用于認證協定，選擇一個随機數或者僞随機數來保障時新性(時新性要求選取最新發生的消息或操作)。例如，在一個challenge-response協定中，伺服器會為請求的用戶端提供一個臨時密鑰，而用戶端需要在指定時間内發送認證資料與臨時密鑰的副本作為響應。由于重放到伺服器上的舊的認證交換資訊不會包含正确的臨時密鑰數值，是以這種方法能夠避免重播攻擊。
混淆值是一個用于加密文本中的随機數或者僞随機數，可用于防禦對密文的蠻力攻擊(反複地猜測密碼、密碼、密鑰或等效的秘密中并驗證其是否正确)。
加密散列函數，類似于部分加密算法，用于做傳輸資料完整性的保障及預防對消息的篡改攻擊。當一條消息M作為輸入時，加密散列函數的輸出H被稱為這條消息的摘要或指紋H(M)。它不僅易于計算，還具有以下特征：
1. 原像不可計算性，在給定摘要H(M)而未知消息M的情況下，難以得出消息M的值。
2. 原像不相同性，給定消息M1的摘要H(M1)，找出消息M2(M1 ≠ M2)使它的摘要與M1的摘要相等(H(M1) = H(M2))是十分困難的。
3. 抗碰撞性，找出一堆摘要相同(H(M1) = H(M2))而自身不同的消息M1、M2(M1 ≠ M2)是十分困難的。
目前最通用的兩個加密雜湊演算法是生成128位摘要的消息摘要算法(MD5)和生成160位摘要的安全雜湊演算法(SHA-1)。SHA-2基于一系列SHA函數，能夠生成長度224，256，384，512位的摘要。
消息認證碼(簡稱MAC或MIC)，一般基于有密鑰的加密散列函數，用于保障消息的完整性和防止各種僞造。這些函數類似于消息摘要算法，但需要一個私鑰來驗證消息的完整性，甚至也可能用于驗證消息的發送者。給定有密鑰的散列函數H(M,K)，M為輸入的消息，K是密鑰，抵禦"選擇性僞造"意味着地方在不知道密鑰K的情況下對指定的消息M生成散列值H(M,K)是非常困難的。消息認證碼由于不止有一方知道對應的密鑰，是以并不能為不可否認性提供堅實基礎。
一個标準的使用加密散列函數的消息認證碼被稱為基于有密鑰散列的消息認證碼(HMAC)，下面的公式定義了使用密鑰K對消息M用H進行散列的方法(HMAC-H)，它形成t位元組的HMAC：
HMAC-H(K,M)(^t) = Λ(_t)(H((K ⊕ opad) || H((K ⊕ ipad) || M))) opad(外填充)是一個将數值0x5C重複|K|次的數組，ipad(内填充)是講數值0x36重複|K|次的數組。⊕是向量的異或運算符，||是連接配接運算符，Λ(_t)表示取消息M最左邊的t位元組。其中的将一個散列函數作用于另一個散列函數的結構能夠抵禦所謂的擴充攻擊，内填充與外填充的數值并不重要，但生成的2次密鑰K1與K2需要有較大的差別。
随着消息認證碼多年以來的發展，一些其他形式的消息認證碼已經被标準化，比如基于密碼的消息認證碼CMAC、GMAC。這些新标準不使用HMAC的加密散列函數，而是使用分組密碼，如AES。根據[RFC4493]描述，CMAC使用的是AES-128算法。GMAC則采用了AES算發的一種特殊模式，稱為Galois/計數器模式，它仍然使用一個有密鑰的散列函數(GHASH，并不是一個加密散列函數)。
證書相關知識
一種被稱為"信任網絡"的模型：通過一些目前使用者(稱為代言人)來做代言的方式以證明一個證書(身份-公鑰對)的可靠性。一個代言人會對一個證書進行簽名，然後将其釋出出去，随着時間推移，如果一個證書有越來越多的代言人，那麼它就越可靠。該模型是分散的、沒有中心的權威機構，是以它具有一定的"草根"性。"信任網絡"的優缺點顯而易見，有點是其不存在中心的權威機構，模型不會因為單點失效而奔潰；缺點是新加入者需要經曆相當長的時間才能使自己的密鑰得到一定數量使用者的代言。
一種更常見的方法是依靠中心化的機構，其中包括對公鑰基礎設施(PKI)的使用，PKI負責提供建立、吊銷、分發以及更新密鑰對證書的服務。它需要一些證書頒發機構(CA)才能運作，CA是用于管理與認證一些個體與它們的公鑰間的綁定關系的實體。
ITU-T X.509 是公鑰證書的格式标準[RFC5280]，常見的的包括DER、PEM、PKCS#7、PKCS#12。
可用 openssl 指令來檢視網站證書資訊:
openssl x509 -in xxx.pem -text 給出結構大緻：
Certificate: 解碼後的證書資訊
Data: 中繼資料
Version: 版本，特定的證書類型
Serial Number: 特定證書的序列号
Signature Algorithm: 簽名算法
Issuer: 發行者，擁有以下特殊子域：C(國家)、L(地區或城市)、O(組織)、OU(組織單元)、ST(州或省)、CN(通用名稱)
Validity: 有效時間
Not Brfore: 起始時間
Not After: 結束時間
Subject: 主題，辨別與目前證書相關的實體
Subject Public Key Info: 主題公鑰資訊，辨別公鑰的擁有者
Public Key Algorithm: 公鑰算法
Public-Key: 公鑰
Modulus: 模
...
Exponent: 指數
Signature Algorithm: 簽名算法
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
# ... 根據字段決定值類型，代表密鑰/簽名等結果内容 在證書撤銷的過程中，需要考慮一些問題'如何撤銷證書？'、'如何讓依賴方知道他們所依賴的證書不再可信？'。
為了驗證某個證書，需要建立一條驗證(或認證)路徑，這條路徑應當是一個已被驗證過的證書集合，通常會包含依賴方已經的信任錨點(例如，根證書)。驗證過程的一個關鍵步驟在于确定證書鍊中的一個或多個證書是否已被撤銷。若是，則驗證路徑将失效。
網際網路中實作證書撤銷的兩種方法：證書撤銷清單(CRL)和線上證書狀态協定(OCSP)[RFC2560]。
CRL：一個被簽署的清單，它指定了一套證書釋出者認為無效的證書。除了普通CRL外，還定義了一些特殊的CRL類型用于覆寫特殊領域的CRL。
OCSP：一個應用層的請求/應答協定，通常運作在HTTP協定之上。當使用者試圖通路一個伺服器時，線上證書狀态協定發送一個對于證書狀态資訊的請求，伺服器回複一個"有效"、"過期"或"未知"的響應。
OCSP克服了CRL的缺陷：必須經常在用戶端下載下傳以確定清單的更新。
TCP/IP安全協定與分層
存在與OSI協定棧中各層次以及一些'中間'層的安全協定，如下：
層号 層名稱 執行個體
7 應用層 DNSEC/DKM/EAP/Diameter/RADIUS/SSH/Kerberos/IPsec(IKE)
4 傳輸層 TLS/DTLS/PANA
3 網絡層 IPsec(ESP)
2 鍊路層 802.1X(EAPoL)/802.1AE(MACSec)/802.11i/WPA2/EAP 網絡通路控制
網絡通路控制(NAC)是指對于特定系統或使用者而言用于授權或拒絕網絡通信的方法。
由IEEE定義的802.1X基于端口的網絡通路控制(PNAC)标準廣泛用于TCP/IP網絡，為企業區域網路提供安全，其中包括有線和無線網絡。PNAC的目的在于隻有當系統或使用者基于網絡接入點完成認證後，才會為其提供網絡通路服務。由于常與IETF标準的可擴充身份驗證協定(EAP)配合使用[RFC3748]，是以802.1X協定有時也稱為區域網路上的EAP協定(EAPoL)。2010年的版本[802.1X-2010]還包括了802.1AE(IEEE的區域網路加密标準，稱為MACSec)與802.1AR(面向安全裝置表示的X.509證書)，還包括了一個比較複雜的MACSec密鑰協商協定MKA。
EAP可與多種鍊路層技術一同使用，并提供多種方法來實作身份驗證、授權及計費(AAA)。然而EAP本身并不執行加密，是以它必須與其他一些加密功能矯情的協定一同才能保證安全。如下圖是EAP的一個執行個體設定：
上圖假設了一個包括有線和無線端點的企業網絡，這個受保護的網絡包括了AAA伺服器、特殊虛拟區域網路中的内網伺服器以及一個不需要認證的虛拟區域網路。認證者負責與未認證端點以及AAA伺服器進行互動以确定是否給予每個端點通路受保護網絡的權限。上圖認證者能夠以'直通模式'允運作，以幫助認證者免于執行大量的認證方法。
EAP資料包的格式非常簡單，如圖所示：
代碼字段包含了6中EAP資料包類型之一：請求(1)、響應(2)、成功(3)、失敗(4)、初始化(5)、結束(6)。
辨別符字段包含了一個由發送者選擇的序号，用于比對請求與響應。
長度字段給出了EAP消息的位元組數(含代碼、辨別符、長度)。
典型的EAP互動過程：
1. 從認證者發送一個請求消息給端點；
2. 端點以一條響應消息作為回應，兩條消息使用的格式相同。
請求與響應消息的主要目的在于交換實作成功認證所需要的資訊，如下圖：
EAP消息承載着端點與認證者之間的認證材料。
EAP是一個支援自身的多路複用與多路分解的分層體系結構，從概念上講，它包括四個層次：底層、EAP層、EAP端點/認證者層、EAP方法層。底層負責有序的傳輸EAP幀；EAP層實作可靠性和消除重複；EAP端點/認證者層負責實作端點與認證者協定的消息，基于對代碼字段的多路分解實作；EAP方法層包含了所有用于認證的特殊方法，包含任何用于處理大消息的協定操作。
網絡接入認證資訊承載協定(PANA)作為EAP的下次，扮演着EAP資訊承載者的角色，它使用UDP/IP協定(端口号716)，是以能夠用于多種類型的鍊路，并且不限于點對點的網絡模型。
PANA的架構包含了三個主要的功能性實體，PANA用戶端(PaC)、PANA認證代理(PAA)、PANA中繼原件(PRE)：
PANA的用途通常包含認證伺服器(AS)和執行點(EP)，AS是一個通過通路協定通路的正常AAA伺服器。
PAA負責将認證材料從PaC傳輸至AS，并且在網絡通路被準許或撤銷時對EP進行配置。
PaC與PAA之間的直接通信不能實作時，PRE可用于兩者之間的中繼通信。
PANA協定由一組請求/響應消息構成，包括一個有"屬性-值"對組成的擴充集合。PANA會話包含4個節點：認證/授權、通路、重新認證、終止。重新認證明際上是通路階段的一部分，是以重新認證後會話的生存期也得到相應的擴充。終止節點一般會以明确的方式進入，也會因為會話逾時而進入。
PANA是一個弱傳輸協定，它按照"stop-and-wait"模式工作，沒有使用自适應的重傳計時器，不能夠對資料包進行重新分組。當出現多個資料包丢失的情況時，它的重傳計時器會以指數的方式進行回退。
IP安全(IPsec)
IPsec的操作可分為建立階段和資料交換階段。建立階段負載交換密鑰材料并建立安全管理(SA)；資料交換階段會使用不同類型的封裝架構，稱為認證頭部(AH)與封裝安全負載(ESP)。
一個完整的IPsec包含了SA建立協定、AH(可選)、ESP以及一些合适的加密套件、配置資訊與設定工具。[RFC6071]總結了所有IPsec元件的發展過程與目前規範。
IPsec會有選擇地針對某些資料包進行操作，這些操作基于管理者所設定的政策。所有的政策都包含在一個安全政策資料庫(SPD)中，邏輯上與每一個IPsec的實作相伴。IPsec還需要兩個額外的資料庫，稱為安全關聯資料庫(SAD)和端點認證資料包(PAD)。下圖簡單的描述了需要如何使用這些資料庫及如何處理資料包：
SA
IPsec的第一步就是建立SA，SA是在兩個通信方之間建立的單工(單向)認證關聯。常見的情況是雙方之間的雙向通信，是以需要一對SA才能有效地使用IPsec，特殊協定Internet密鑰交換(IKE)自動完成這項工作。IKE開始于一個簡單的請求/響應消息對，該消息對包括一個建立以下參數的請求：加密請求、完整性保護算法、Diffie-Hellman組，以及根據任何輸入的比特串随機生成輸出的PRF(PRF用于生成會話密鑰)。
IKE的前兩次交換稱為IKE_SA_INIT和IKE_AUTH，建立一個IKE_SA和CHILD_SA。随後出現兩個交換，其中CREATE_CHILD_SA交換用于建立其他的CHILD_SA，INFORMATIONAL交換則用于初始化SA中的變化或收集SA的狀态資訊。IKE消息封裝在UDP中通過端口500或4500發送，而IKE的接收者則應該準備接收來自任何端口的流量。
IKE消息格式如下：
SPI，安全參數索引，一個64位的号碼，用于辨別一個特定的IKE_SA，發起者和響應者都會有一個屬于自己的SA，是以它們能提供正在使用的SPI，這一對SPI值能夠與通信兩端的IP位址結合起來用于形成一個有效的連接配接辨別符。
下一個負載字段指出了後面負載的類型。
主要版本字和次要版本字段應分别設定為2和0，當無法維持版本直接的互操作性時，主要版本号就會被修改。
交換類型字段給出了消息的交換類型，包含：IKE_SA_INIT(34)，IKE_AUTH(35)，CREATE_CHILD_SA(36)，INFORMATIONAL(37)，IKE_SESSION_RESUME(38)，其他數值被保留，240~255範圍被留作私人用途。
标志位字段定義了一個3比特位的字段：I(發起者，第3位)，V(版本，第4位)，R(響應者，第5位)。I由原始發起者設定，接收者會在傳回消息中将其清除；V指出一個版本号，高于發送者目前使用的協定的主要版本号；R指出目前消息是之前某一消息的響應，與其使用相同的消息辨別符。
消息辨別符字段是于TCP序列号類似的功能，辨別包含該辨別符的資料流的第一個位元組。不同的是發起者消息辨別符從0開始，而響應者從1開始。無論是在發送還是接收時，消息辨別符都會被記錄下，這樣做可以幫助每一個通信端檢測重播攻擊。
長度字段統計了IKE消息頭部和所有負載的合計大小。
IKEv2負載類型表，數值0表示沒有下一個負載：
"通用"的IKEv2負載頭部如下圖所示：
通用的負載頭部固定為32位，下一個負載與負載長度字段提供了一個大小可變的負載"鍊"(最多位65535位元組，包括負載頭部的4位元組)。C位指出目前負載對于一個成功的IKE交換而言被認為是"關鍵"的。
IKE_SA_INIT與IKE_AUTH交換過程：
HDR IKE 頭部(非有效載荷)；SAi1/SAr1(SAi2/SAr2)分别表示發起者和響應者可支援的密碼算法套件，數值表示階段；KEi/KEr表示雙方的 Diffie–Hellman密鑰交換内容和一次性随機數。
CREATE_CHILD_SA交換用于建立或更新一個CHILD_SA，或用于更新一個IKE_SA。交換過程如下：
INFORMATIONAL交換用于傳輸狀态與錯誤資訊，通常使用N(通知)負載。交換過程如下：
AH
IP認證頭部(AH)[RFC4302]是IPsec協定套件的可選部分，提供了一種源認證與保護IP資料報完整性的方法。
看下IPsec AH處理後的IP頭部(IPsec頭部)：
IPsec AH處理後的隧道模式IP頭部：
AH結構：
下一個頭部字段指出下一個類型值。
負載長度字段指出AH的長度。
保留字段作為保留。
安全參數索引字段包含一個32位的位于接收者端的SA辨別符，指出AH屬于哪個SA，随着每一個SA資料包的發送而增1。
序列号字段，如果開啟，則用于重放保護。
完整性校驗值字段是可變的，且依賴于使用的密碼套件，該字段在長度上保持為32比特的整數倍。
ESP
IPsec的封裝安全負載(ESP)[RFC4303]，也稱作ESP(v3)(注意，其本身并不提供正式的版本号)，提供了一個可選的組合，包括機密性、完整性、原始認證以及對IP資料報的反重放保護。
看下IPsec ESP處理後的IP頭部(IPsec頭部)：
IPsec ESP處理後的隧道模式IP頭部：
ESP結構：
安全參數索引字段包含一個32位的位于接收者端的SA辨別符，指出ESP屬于哪個SA，随着每一個SA資料包的發送而增1。
負載資料以32位(IPv6中64位)為邊界終止，并且最後兩個8位字段能夠識别填充長度與下一個頭部字段值，填充、填充長度、下一個頭部字段共同構成了ESP尾部。
完整性校驗值字段是一個長度可變的尾部，用于啟用完整性支援以及滿足完整性檢驗算法的需要。它會對ESP頭部、負載以及ESP尾部進行計算。ICV的長度取決于所選擇的特定完整性檢驗方法，是以它會在相關的SA建立之後才建立起來，并且要求SA在其生存期中不發生改變。
傳輸層安全(TLS和DTLS)
傳輸層安全(TLS)用于保證Web通信以及其他流行協定的安全，其面向資料報的版本成為資料報傳輸層安全(DTLS)。
TLS協定本身分為兩層：記錄層和上層。如圖所示：
TLS是一個用戶端/伺服器協定，設計用于為兩個應用程式的連接配接提供安全。記錄協定提供分片、壓縮、完整性保護及用戶端與伺服器之間所交換資料的加密服務。資訊交換協定(即上層協定)負責建立身份、進行認證、提示警報、以及為用于每一條連接配接的記錄協定提供唯一的密鑰材料，其包含4個特殊的協定：握手協定、警告協定、密碼變更協定、應用資料協定。
記錄協定
記錄協定使用一個可擴充的記錄"内容類型"值集合來識别可多路複用的消息類型。
在任何給定的時間點時，記錄協定有一個活躍的目前連接配接狀态和一組被稱為挂起連接配接狀态的狀态參數；每一個連接配接狀态又進一步被劃分為讀狀态和寫狀态；每個狀态又指定一個壓縮算法、加密算法和用于通信的MAC算法，同時還包括必需的密鑰與參數。
TLS記錄過程：
壓縮算法可以為NULL壓縮協定，即不提供任何壓縮，且壓縮算法應該是無損的，産出的輸出結果不能大于輸入記錄的1KB。為了防止負載被披露或修改，加密與完整性保護算法會将TLS壓縮結構轉換為能夠在底層傳輸層連接配接上發送的TLS密文結構。
消息交換協定
TLS的三個子協定是通過數字分辨的，這些數字被記錄層用于多路複用和多路分解，比如握手協定(22)、警告協定(21)、密碼變更協定(20)。
密碼變更協定包括一個單位元組的消息，該位元組的數值為1，該消息的目的在于指出通信一方希望将目前狀态修改為挂起狀态。如果收到這條消息，就将讀挂起狀态作為目前狀态并訓示記錄層盡快轉換至挂起寫狀态。
警告協定用于從TLS臉頰的一端向另一端傳遞狀态資訊，它可以包括一些終止條件或非緻命的錯誤條件。
握手協定建立了與連接配接相關的運作參數。它允許TLS端點完成6個主要目标：協商加密算法并交換形成對稱密鑰時使用的随機值；建立算法運作參數；交換證書并執行互相認證；生成特定的會話密鑰；為記錄層提供安全參數；驗證所有的操作都已正确執行。
握手協定過程：
1. 用戶端向服務端發送第一條ClientHello消息，該消息包含：會話辨別符、建議的加密套件變化(CS)、一套可接受的壓縮算法、TLS版本号、一個稱為ClientHello.random的随機數。
2. 服務端接收到ClientHello消息，檢查其中的會話辨別是否存在其緩存中。如果存在，則服務端通過一個簡化的握手過程繼續之前已有的連接配接(稱為重新開始)。服務端通過ServerHello消息将服務端的随機數ServerHello.random傳遞至用戶端，完成了交換的第一部分。這條消息也包含一個會話辨別符，如果它的數值與用戶端的數值相同，則表明服務端願意重新開始；否則其數值為0表示需要開啟一個完整的握手過程。如果服務端需要通過身份驗證，會要求它在證書(Certificate)消息中提供自己的證書鍊。如果證書的簽名是無效的，那麼伺服器可能還需要發送一個伺服器密鑰交換消息，使其在沒有證書的情況下通過一個暫時或短暫的密鑰生成會話密鑰。
3. 用戶端收到服務端傳回資訊并确認後，以一個握手協定已完成消息(Finished)結束。
如下圖：
在缺乏可靠傳輸層的情況下提供類似TLS服務的主要挑戰在于資料報可能會丢失、重新排序或重複。這些問題會影響到加密與握手協定，這兩者都依賴于TLS協定。為了處理這些問題，DTLS為記錄層承載的每一條記錄添加了一個明确的序列号，在每一條ChangeCipherSpec消息發送之後這些序列号被重置為0。
在DTLS中的MAC計算修改了對應的TLS版本，包含了一個由兩個新字段組成的64位塊，以允許單獨處理每一條記錄。注意：在TLS中一個錯誤的MAC會導緻連接配接終止；而在DTLS中，終止一個完整的連接配接是沒有必要的，接收者會選擇簡單地丢棄包含錯誤MAC的記錄，或是發送一條警告消息。
重複的消息會被簡單地丢棄，或者被視為一個潛在的重播攻擊。如果支援重放檢測，那麼将會在接收端設定一個目前序列号視窗。要求該視窗隻是容納32條消息，建議至少64條。以下列出接收到消息後的行為：
1. 如果到達記錄的序列号小于視窗左邊沿對應的數值，那麼會将它視為舊的或重複的記錄而默默地丢棄；
2. 那些在視窗之内的記錄也會被檢查，看是否出現重複；
3. 如果一條消息在視窗之内并且擁有正确的序列号，即便出現順序錯亂的情況也會将其保留下來；
4. 而那些擁有錯誤MAC的消息會被丢棄；
5. 有正确MAC卻超出視窗右邊沿的消息會使得右邊沿增加。
是以，右邊沿代表已驗證消息的最高序列号。
為了處理消息丢失的問題，DTLS具有簡單的逾時和重傳功能。重傳功能是以消息組的形式運作的，也被稱為"班次"。
上圖初始的完整交換(左)包含6個班次的資訊，每個班次都能夠持續傳輸。DTLS簡化交換(右上)隻使用3個班次，且與TLS略不同。DTLS在處理協定時報錯一個擁有三個狀态的有限狀态機(右下)。
狀态機的三個狀态分别為：準備、發送、等待。狀态機由一個重傳計時器驅動，它的預設建議值為1秒。如果在逾時期限内接收不到某一班次的響應，就會使用相同的握手協定序列号重新傳輸這一班次。然而需要注意的是，記錄層序列号仍然會向前增加。後續重傳如何沒有獲得響應将會使RTX的逾時值加倍，至少高達60s。在一次成功傳輸或一個長的空閑期後會重置該數值。
在DTLS中，當一台伺服器接受到一條ClientHello消息，它會生成一條心的包含32位cookie的HelloVerifyRequest消息。後續的ClientHello消息必須包含之前的cookie，否則伺服器會拒絕交換。這被DTLS用于防禦DoS攻擊。
DNS安全(DNSEC)
DNS的安全不僅指DNS中的資料(資源記錄，RR)安全，還包含在同步或更新DNS伺服器内容時的傳輸安全。針對其部署的安全機制稱為域名系統安全擴充(DNSSEC)[RFC4033][RFC4034][RFC4035]。DNSSEC提供了DNS資料的源認證與完整性保護，以及(有限的)密鑰分發設施。DNSSEC還能夠進行不存在性驗證，DNS響應能夠指出某一受保護的特定域名是不存在的并對此提供保護。DNSSEC不能為DNS資訊提供保密性、DoS攻擊保護以及通路控制。
當執行一個帶有DNSSEC的DNS查詢時，一個已知安全的解析器就會使用DNS擴充機制(EDNS0)，并且将請求中一個OPT元資源記錄的DO位置位(表示DNSSEC OK)。該位指出用戶端不僅有興趣而且有能力來處理DNSSEC相關的資訊并支援EDNS0。DO位在EDNS0元資源記錄的"擴充的RCODE與标志"部分，是其中第2個16位字段的第1位。接收到那些DO位未置位(或不存在)請求時，會禁止伺服器傳回大多數資源記錄，除非這些記錄是在請求中明确要求的。
當伺服器處理來自一個DNSSEC可用解析器的請求時，它會檢測DNS請求的CD(Checking Disabled)位，如果該位置位，那麼表明用戶端願意接收包含未驗證資料的響應。在準備一個響應時，伺服器通常會利用密碼方法驗證要傳回的資料，成功的驗證結果會使得響應中的AD(Authentic Data)位置位[RFC4035]。如果擁有一條到達伺服器的安全路徑，那麼一個安全已知但未驗證的解析器在原則上是能夠信任這條資訊的。然而，最好的情況是使用驗證存根解析器，它能夠進行加密驗證，進而将查詢的CD位置位。這樣不僅提供了端到端的DNS安全(即中間解析器不需要是可信的)，還減少了中間伺服器的計算負擔;否則，這些中間伺服器不得不進行密碼驗證。
DNSSEC 資源記錄
DNSKEY，用以維護公鑰。密鑰隻能與DNSSEC一起使用；其他的資源記錄可能用于維護針對其他用途的密鑰或證書。
DNSKEY資源記錄格式如下圖：
DNSKEY資源記錄的RDATA部分包含一個隻用于DNSSEC的公鑰，标志字段包含了一個區域密鑰訓示符(第7位)，如果置位，那麼DNSKEY資源記錄擁有者的名稱必須為區域的名稱，并且所包含的密鑰也被稱為區域簽名密鑰(ZSK)或密鑰簽名密鑰(KSK)，如果未置位，那麼記錄将會維護另一種不能用于驗證區域簽名的DNS密鑰；一個安全入口點訓示符(第15位)作為調試或簽名軟體時的一條提示，能夠根據密鑰的用途做出明智的猜測，簽名驗證不會解釋SEP位，但該位置位的密鑰通常為KSK，并通過驗證子區域的密鑰來確定DNS層次結構的安全；一個撤銷訓示符(第8位)，如果置位，則表示密鑰不能用于驗證。算法字段指出了簽名算法，根據[RFC4034]，隻有DSA與具有SHA-1的RSA(值分别為3和5)才被定義用于DNSKEY資源記錄。公鑰字段維護了一個公鑰，它的格式依賴于算法字段。
DS，授權簽名者資源記錄用于指定一條DNSKEY資源記錄，通常從一個父區域到一個子區域。
DS資源記錄格式如圖：
密鑰标簽字段包含了對一條DNSKEY資源記錄的非唯一參考。
算法字段使用了DNSKEY資源記錄的算法字段相同的數值。
摘要類型字段指出了所用的簽名類型[RFC4034]中隻定義了數值1(SHA-1)，SHA-256是通過[RFC4509]指定的。
摘要字段包含了将要引用的DNSKEY資源記錄的摘要，該摘要計算方法如下：
摘要 = 摘要算法(DNSKEY所有者名|DNSKEY RDATA) 此處的"|"是連接配接運算符，而DNSKEY RDATA的數值是根據引用的DNSKEY資源記錄來計算的，計算方法如下：
DNSKEY RDATA = 标志 | 協定 | 算法 | 公鑰 在SHA-1情況下，摘要長度為20位元組；在SHA-256情況下，長度為32位元組。
NSEC/NSEC3，NextSECure，下一個安全資源記錄用于規範有序的名稱或一個NS類型的RRset(資源記錄集)授權點中維護"下一個"RRset所有者的域名，它還維護位于NSEC資源記錄的所有者名稱中的RR類型清單，這樣能夠為區域結構提供認證與完整性驗證。
NSEC資源記錄格式如圖：
下一個域名字段維護一個區域的規範有序的域名鍊中的下一個條目。
類型位圖字段維護了一張關于RR類型的位圖，這些RR類型記錄在NSEC資源記錄所有者的域名中。
NSEC3是對NSEC結構做的優化，旨在消除"任何人能夠通過周遊NSEC鍊而列舉出一個區域中的權威記錄"這個問題(也被稱為區域列舉)。
NSEC3資源記錄格式如圖：
雜湊演算法字段辨別了應用于下一個所有者名稱的散列函數，以産生下一個散列的所有者字段。
标志字段的低比特位包含了一個opt-out标志，如果置位，它将指出NSEC3記錄可能包含未簽名的授權。
疊代次數字段指出散列函數使用了多少次，較大的疊代次數有助于防止找到與NSEC3記錄中的散列數值相關的所有者名稱(字典攻擊)。
混淆值長度字段給出了混淆值字段的位元組長度，包含了一個在計算散列函數之前附加于原所有者名稱的數值，目的在于幫助抵禦字典攻擊。
為了獲得下一個散列所有者字段的散列值，需要進行以下計算：
IH(0) = H(所有者名稱 | 混淆值)
IH(k) = H(IH(k - 1) | 混淆值)， 若 k > 0
下一個散列所有者 = H(IH(疊代次數) | 混淆值) 其中H是雜湊演算法字段指定的散列函數，所有者名稱必須按照标準的格式。疊代次數與混淆值取自NSEC3資源記錄的相關字段。
為了避免混淆NSEC與NSEC3資源記錄類型，[RFC5155]在NSEC3資源記錄的區域中配置設定并要求使用特殊的安全算法編号6和7，作為辨別符3(DSA)和5(SHA-1)的别名。
RRSIG，資源記錄簽名的資源記錄用于簽署并驗證RRset中的簽名。區域中每一條授權的資源記錄都必須簽名，一條RRSIG資源記錄包含了某一特定RRset的數字簽名以及使用哪一個公鑰來驗證簽名的資訊。
RRSIG資源記錄格式如圖：
覆寫類型字段指出了簽名适用的RRset類型，它的數值來自标準的RR類型集合。
算法字段指出了簽名算法。
标簽字段給出了在RRSIG資源記錄的原所有者名稱中的标簽數目。
源TTL字段維護了一份TTL副本，這份副本是當RRset出現于授權區域時保留下來的。
簽名到期與簽名成立字段指出了一個簽名有效期的開始和結束時間。
密鑰标簽字段辨別那些用于獲得某種特殊公鑰的DNSKEY資源記錄。
DNSSEC運作
對于一個特殊的資源記錄而言，需要有一個定義良好的規範形式：
1. 每一個域名都是一個完全限定域名并被完全展開(無壓縮标簽)。
2. 在所有者名稱中的所有大寫的US-ASCII碼字元都需要被它們的小寫版本代替。
3. 對于任何類型号為2~9、12、14、15、17、18、21、24、26、33、35、36、39以及38的記錄，在它們的RDATA部分出現的域名中，所有大寫的US-ASCII碼字元都需要被它們的小寫版本代替。
4. 任何通配符都不會被取代。
5. 當出現在源權威區域或覆寫RRSIG資源記錄的源TTL字段，TTL将會設定為原始值。
DNSSEC依賴于簽名區域。這樣的區域包括RRSIG、DNSKEY以及NSEC(或NSEC3)資源記錄，而且如果有一個簽名授權點，它還可能包含DS資源記錄。簽名使用公鑰加密，公鑰的存儲于分發通過DNS來完成。
如下圖展示了位于父子區域之間的抽象授權點：
父區域包含了自己的DNSKEY資源記錄，它能夠提供與使用RRSIG資源記錄來簽名一個區域中的所有授權RRset的私鑰相關的公鑰。父區域中的一條DS資源記錄提供子頂點的一條DNSKEY資源記錄的散列值，這樣就能見了起一條從父區域到子區域的信任鍊。一個信任父區域的DS資源記錄的驗證解析器也能驗證子區域的DNSKEY資源記錄，以及最終的RRSIG和子區域中簽名的RRset(該情況隻有在驗證者擁有一個與父區域DSNKEY資源記錄相連的信任根節點時才會發生)。
事務認證(TSIG,TKEY,SIG(0))
DNSSEC提供了資料的源認證與區域資料的完整性保護，而事務認證為用戶端與伺服器之間不檢查交換内容正确性的特殊事務提供了完整性保護與認證。DNS中的事務(如區域傳輸、動态更新)安全并不直接保護DNS的内容，是以它和DNSSEC是互補的，需要能夠被一同部署。
主要有兩種方法來認證DNS的事務：TSIG和SIG(0)。SIG使用共享密鑰而SIG(0)使用公鑰/私鑰對，為了緩解部署的負擔，可以使用TKEY資源記錄類型來幫助形成TSIG或SIG(0)的密鑰。
針對DNS或事務簽名的密鑰事務認證(TSIG)[RFC2845]5]使用基于共享密鑰的簽名為DNS交換添加事務認證，TSIG使用一個按需計算并且隻用于保障一次事務的TSIG僞資源記錄。
TSIG僞資源記錄格式如圖：
上面的資源記錄是包含在DNS請求與響應的附加資料部分發送的。
算法名稱字段指出使用什麼算法。
簽名時間字段是按照UNIX系統的時間格式組織的，并且給出了消息内容被簽署的時間，此字段隐藏在數字簽名中，被設計用于檢測并抵禦重播攻擊，此處使用一個絕對時間的結果是，使用TSIG的端點必須在更新字段指定秒數内對時間達成一緻。
MAC大小字段給出了MAC字段中包含的MAC與其依賴的特殊MAC算法所需的位元組數。
源ID字段是該消息的一個辨別，與DNS的事務ID比對。
錯誤字段用以承載錯誤資訊。
其他長度字段給出了其他資料字段的位元組數，一般用來運送錯誤的消息。
SIG(0)[RFC2931]沒有覆寫DNS中靜态的記錄，而是為交換動态地生成，SIG(0)的0部分指一條被簽署資源記錄中資料的長度。SIG(0)記錄原則上能夠替代TSIG資源記錄，并達到相同的結果，但他們是以不同的方法實作的。更重要的是，SIG(0)将信任基礎放置于公鑰中來代替共享密鑰。
TKEY元資源記錄類型旨在簡化DNS交換安全的部署，為了完成這項工作，它會動态建立TKEY資源記錄并添加到DNS請求與響應的附加資訊部分發送出去，它們能夠包含密鑰或者用于形成密鑰的資料，比如DH公共數值。
域名密鑰識别郵件
域名密鑰識别郵件(DKIM)[RFC5585]提供了一個實體與一個域名之間的關聯，進而決定哪一方發送初始消息，特别是以電子郵件形式。域名密鑰識别郵件的工作是通過在基本的Internet消息格式中添加一個DKIM簽名實作的[RFC5322]，該字段包含了對消息頭部和消息體的數字簽名。DKIM取代了早期稱為域名密鑰的标準，該标準使用域名密鑰簽名字段。
為生成一條消息的數字簽名，簽名域表示符(SDID)會使用RSA/SHA-1或者RSA/SHA-256算法及相關的私鑰。SDID來自DNS的域名，并用于檢索以TXT資源記錄存儲的公鑰。一個DKIM簽名會通過Base64被編碼為一個消息頭部字段，該簽名能夠簽署一個明确列出的消息字段與消息體集合。
當接收到一封電子郵件時，郵件傳輸代理會使用SDID來實作一個DNS查詢，進而找出相關的公鑰。該公鑰會在之後用于驗證簽名，這樣就避免了請求一個PKI的工作。所擁有的域名是由域本身和選擇器(公鑰選擇器)一起構成的。例如，在域example.com中的選擇器key35的公鑰是一條由key35._domainkey.example.com擁有的TXT資源記錄。