第6章網絡安全協議網絡安全協議概述IPSec協議SSL協議Kerberos協議6.1網絡安全協議概述1.基本概念1.通信協議通信協議是指通信各方關于通信如何進行所達成的一致性規則，即由參與通信的各方按確定的步驟做出一系列通信動作，是定義通信實體之間交換信息的格式及意義的一組規則。2.安全協議安全協議是指通過信息的安全交換來實現某種安全目的所共同約定的邏輯操作規則。簡單來說，安全協議指實現某種安全目的的通信協議，又稱安全通信協議。因為安全協議通常涉及到密碼技術，又稱為密碼協議。1.基本概念3.網絡安全通信協議網絡安全通信協議屬于安全協議，是指在計算機網絡中使用的具有安全功能的通信協議。網絡安全通信協議的目標是提供數據的機密性、完整性及通信雙方的認證。所以，應具備以下基本要素：（1）保證信息交換的安全，其目的是完成某種安全任務。（2）使用密碼技術。密碼技術是安全協議保證通信安全所采用的核心技術，如信息交換的機密性、完整性、抗否認性等都依賴于密碼技術。（3）具有嚴密的公共約定的邏輯交換規則。協議的安全交換過程是否嚴密非常重要，安全協議的分析往往針對這一部分來進行。（4）使用訪問控制等安全機制。必要時應使用訪問控制機制等安全機制，IPSec協議在進行安全通信時就使用了訪問控制機制。2.TCP/IP安全架構由于TCP/IP協議簇在早期設計時是以面向應用為根本目的的，因此未能充分考慮到安全性及協議自身的脆弱性、不完備性，導致網絡中存在著許多可能遭受攻擊的漏洞。這些潛在的隱患使得攻擊者可以利用存在的漏洞來對攻擊目標進行惡意的連接、操作，從而可以達到獲取重要信息、提升控制權限等非授權目的。如SYNFlood攻擊、TCP序列號猜測、IP地址欺騙、TCP會話劫持、路由欺騙、DNS欺騙、ARP欺騙、UDPFlood攻擊以及PingofDeath攻擊，都是利用TCP/IP協議簇的安全漏洞來實施。2.TCP/IP安全架構2.TCP/IP安全架構由于TCP/IP各層協議提供的功能不同，面向各層提供的安全保證也不同，人們在協議的不同層次設計了相應的安全通信協議，用來保障網絡各個層次的安全。目前，在TCP/IP的安全體系結構中，從鏈路層、網絡層、傳輸層到應用層，已經出現了一系列相應的安全通信協議。安全協議是在原有網絡協議的各個層面增加安全機制，或在原有網絡層之間加入一個中間層安全協議。6.2IPSec協議1.IP協議的缺陷在TCP/IP協議棧中，網絡層最重要的協議就是IP協議，主要用來實現網絡中的多個計算機和網絡互聯設備正常通信。（1）IP數據包的源地址不可信。因為IP協議沒有為通信提供良好的數據源認證機制，只簡單的采用了IP地址。IP協議不能保障一個數據包的真正的源地址，IP地址假冒成為IP協議的主要安全問題。（2）IP協議沒有為數據提供強的完整性保護機制。只是提供了IP頭的校驗，且校驗和可偽造（3）IP協議沒有為數據提供任何形式的機密性保護。（4）入侵者可利用IP協議中的源路由選項進行攻擊。源路由指定了IP數據包必須經過的路徑，可以測試某一特定網絡路徑的吞吐量，或使IP數據包選擇一條更安全可靠的路由。源路由選項使得入侵者能繞開某些網絡安全措施而通過對方沒有防備的路徑攻擊目標主機。（5）IP協議還存在重組IP分片包的威脅。IP首部的長度字段限制了包長度最大為65535字節，但對于多個分片包組合起來的長度可能大于65535字節，IP協議并沒有相應的檢查機制，從而會造成溢出。典型的安全隱患有著名的Ping攻擊。2.IPSec協議概述為了改善現有IPv4協議在安全等方面的不足，IETF（InternetEngineeringTaskForce）的下一代網絡協議（IPng）工作組于1995年底確定了IPng協議規范，稱為IP版本6（IPv6）。IPsec（IPSecurity）產生于IPv6的制定之中，用于提供IP層的安全性。IETF的IPsec工作組于1998年制定了一組基于密碼學的安全的開放網絡安全協議，總稱IP安全體系結構，簡稱IPsec。IPv6利用新的網絡安全體系結構IPsec（InternetProtocolSecurity,Internet協議安全），通過：AH（AuthenticationHeader，驗證報頭）ESP（EncapsulatingSecurityPayload，封裝安全有效負載）2.IPSec協議概述兩個安全協議分別為IP協議提供數據完整性和數據保密性，加強了IP協議的安全，克服了原有IPv4協議安全的不足。IPsec在傳輸層之下，對應用和最終用戶透明。不必改變用戶或服務器系統上的軟件；不必培訓用戶。在防火墻或路由器中實現時，可以對所有跨越周界的流量實施強安全性。而公司內部或工作組內部不必招致與安全相關處理的負擔。同時，實際應用中IPSec可以提供個人安全性。鑒于IPv4的應用仍然很廣泛，所以后來在IPSec的制定中也增添了對IPv4的支持。IPSec提供既可用于IPv4也可用于IPv6的安全性機制，是IPv6的一個組成部分，也是IPv4的一個可選擴展協議。3.IPSec的體系結構IPSec是因特網工程任務組（IETF）定義的一種協議套件，由一系列協議組成，驗證頭（AH）、封裝安全載荷（ESP）、Internet安全關聯和密鑰管理協議ISAKMP的InternetIP安全解釋域（DOI）、ISAKMP、Internet密鑰交換（IKE）、IP安全文檔指南、OAKLEY密鑰確定協議等，它們分別發布在RFC2401～RFC2412的相關文檔中。圖6-3顯示了IPSec的體系結構、組件及各組件間的相互關系。3.IPSec的體系結構1.SA（安全關聯）一套專門將安全服務/密鑰和需要保護的通信數據聯系起來的方案。它保證了IPSec數據報封裝及提取的正確性，同時將遠程通信實體和要求交換密鑰的IPSec數據傳輸聯系起來。SA是兩個應用IPsec實體（主機、路由器）間的一個單向邏輯連接，決定保護什么、如何保護以及誰來保護通信數據。它規定了用來保護數據包安全的IPsec協議、轉換方式、密鑰以及密鑰的有效存在時間等等。SA是單向的，要么對數據包進行“進入”保護，要么進行“外出”保護。具體采用什么方式，要由三方面的因素決定：第一個是安全參數索引（SPI），該索引存在于IPSec協議頭內；第二個是IPSec協議值：AH或ESP；第三個是要向其應用SA的目標地址。通常，SA是以成對的形式存在的，每個朝一個方向。既可人工創建它，亦可采用動態創建方式。SA駐留在安全關聯數據庫（SAD）內。如果需要一個對等關系，即雙向安全交換，則需要兩個SA。3.IPSec的體系結構1.SA（安全關聯）SA與IPSec系統中實現的兩個數據庫有關：（1）安全策略數據庫（SPD）。該數據庫定義了對所有出入業務應采取的安全策略，它指明了為IP數據包提供什么服務以及以什么方式提供。對所有進入或離開IP協議棧的數據包都必須檢索SPD數據庫。對一個SPD條目來說，它對出入IP數據包處理定義了三種可能選擇：丟棄、繞過或應用。例如：可在一個安全網關上制定IPSec策略。對在本地保護的子網與遠程網關的子網間通信的所有數據，全部采用DES加密，并用HMAC-MD5進行鑒別；對于需要加密的、發送另一個服務器的所有Web通信均用3DES加密，同時用HMAC-SHA鑒別。每一個SPD條目通過一組IP和更高層協議字段值（稱為SA選擇器）來定義。選擇器確定的SPD條目有：目的IP地址、源地址、UserID（操作系統的用戶標識）、數據敏感級別、傳輸層協議、IPSec協議（AH,ESP,AH/ESP）、源/目的端口和服務類型（TOS）。3.IPSec的體系結構1.SA（安全關聯）SA與IPSec系統中實現的兩個數據庫有關：（2）安全關聯數據庫（SAD）。SAD為進入和外出包處理維持一個活動的SA列表。SAD定義了SA的參數，包括：序號計數器：一個32位值，用于生成AH或者ESP頭中的序號字段；計數器溢出位：一個標志位，表明該序數計數器是否溢出，如果是，將生成一個審計事件，并禁止本SA的分組繼續傳遞；反重放窗口：用于確定一個入站的AH或ESP包是否重放；AH信息：鑒別算法、密鑰、密鑰生存期及相關參數；ESP信息：加密和鑒別算法、密鑰、初始值、密鑰生存期及相關參數；SA生存期：一個時間間隔或字節計數，到時間后，一個SA必須用一個新的SA替換或終止，并指示哪個操作發生的指示；IPSec協議模式：隧道、傳輸；路徑MTU:不經分片可傳送的分組的最大長度。注：SA管理主要有創建和更新。創建時，先協商SA參數，再用SA更新SAD；更新時，IPSec本身沒提供更新密鑰的能力，必須先刪除現有的SA，再協商建立一個新的SA。3.IPSec的體系結構2.Internet安全關聯和密鑰管理協議（ISAKMP）ISAKMP是與IPSec密切相關的一個協議，為Inertnet環境下安全協議使用的安全關聯和密鑰的創建定義了一個標準通用框架，定義了密鑰管理表達語言通用規則及要求。3.IPSec的體系結構3.解釋域DOIDOI包括一些參數，批準的加密和鑒別算法標識以及運行參數等，是Internet編號分配機構IANA給出的一個命名空間。解釋域為使用ISAKMP進行安全關聯協商的協議統一分配標識符。使用相同DOI的協議對該DOI下的載荷數據內容做統一的解釋。為了通信兩端相互交互，IPSec載荷（AH載荷或ESP載荷）中各字段的取值應該對雙方都可理解，因此通信雙方必須保持對通信信息相同的解釋規則，即應持有相同的解釋域DOI。IPSec至少給出兩個解釋域：IPSecDOI、ISAKMPDOI。3.IPSec的體系結構4.IPSec的處理IPSec處理分兩類：外出處理和進入處理3.IPSec的體系結構4.IPSec的處理（1）外出處理在外出處理的過程中，數據包從傳輸層流進IP層。IP層首先取出IP頭的有關參數，檢索SPD數據庫，判斷應為這個包提供那些安全服務。輸入SPD的是傳送報頭中的源地址和目的地址的“選擇符”。SPD輸出的是根據“選擇符”查詢的策略結果，有可能出現以下幾種情況：丟棄這個包。此時包不會得以處理，只是簡單地丟掉。繞過安全服務。在這種情況下，這個IP包不作任何處理，按照一個普通的IP包發送出去。應用安全服務。在這種情況下，需要繼續進行下面的處理。如果SPD的策略輸出中指明該數據包需要安全保護，那么接著就是查詢SAD來驗證與該連接相關聯的SA是否已經建立，查詢的結果可能是下面的兩種情況之一：如果相應的SA已存在，對SAD的查詢就會返回指向該SA的指針；如果查詢不到相應的SA，說明該數據包所屬的安全通信連接尚未建立，就會調用IKE進行協商，將所需要的SA建立起來。如果所需要的SA已經存在，那么SPD結構中包含指向SA或SA集束的一個指針（具體由策略決定）。如果SPD的查詢輸出規定必須將IPSec應用于數據包，那么在SA成功創建完成之前，數據包是不被允許傳送出去的3.IPSec的體系結構4.IPSec的處理（1）外出處理對于從SAD中查詢得到的SA還必須進行處理，處理過程如下：如果SA的軟生存期已滿，就調用IKE建立一個新的SA。如果SA的硬生存期已滿，就將這個SA刪除。如果序列號溢出，就調用IKE來協商一個新的SA。SA處理完成后，IPSec的下一步處理是添加適當的AH或ESP報頭，開始對數據包進行處理。其中涉及到對負載數據的加密、計算校驗等在下面的內容中會給予詳細的介紹。SA中包含所有必要的信息，并已排好順序，使IPSec報頭能夠按正確的順序加以構建。在完成IPSec的報頭構建后，將生成的數據報傳送給原始IP層進行處理，然后進行數據報的發送。3.IPSec的體系結構4.IPSec的處理（2）進入處理進入處理中，在收到IP包后，假如包內根本沒有包含IPSec報頭，那么IPSec就會查閱SPD，并根據為之提供的安全服務判斷該如何對這個包進行處理。因為如果特定通信要求IPSec安全保護，任何不能與IPSec保護的那個通信的SPD定義相匹配的進入包就應該被丟棄。它會用“選擇符”字段來檢索SPD數據庫。策略的輸出可能是以下三種情況：丟棄、繞過或應用。如果IP包中包含了IPSec報頭，就會由IPSec層對這個包進行處理。IPSec從數據包中提取出SPI、源地址和目的地址組織成<SPI,目的地址，協議>三元組對SAD數據庫進行檢索（另外還可以加上源地址，具體由實施方案決定）。根據協議值，這個包的處理選擇相應的協議（AH協議或者ESP協議）來處理。在協議處理前，先對重放攻擊和SA的生存期進行檢查，把重放的報文或SA生存期已到的包簡單丟棄而不作任何處理。協議載荷處理完成之后，需要查詢SPD對載荷進行校驗，“選擇符”用來作為獲取策略的依據。驗證過程包括：檢查SA中的源和目的地址是否與策略相對應，以及SA保護的傳輸層協議是否和要求的相符合。IPSec完成了對策略的校驗后，會將IPSec報頭剝離下來，并將包傳遞到下一層。4.IPSec的組成1.AH協議AH協議提供無連接的完整性、數據源認證和反重播攻擊服務。然而，AH不提供任何保密性服務，不加密所保護的數據包。AH的作用是為IP數據流提供高強度的密碼認證，以確保被修改過的數據包可以被檢查出來。AH使用消息認證碼(MAC)對IP進行認證。由于生成IP數據包的消息摘要需要密鑰，所以IPSec的通信雙方需要共享一個同樣的認證密鑰。這個密鑰就是由雙方的SA信息來提供的(DH算法)。AH只用于保證收到的數據包在傳輸過程中不被修改，保證由要求發送它的當事人將它發送出去，以及保證它是一個新的非重播的數據包。4.IPSec的組成1.AH協議（1）下一個頭(8bit):指示下一個負載的協議類型。（2）載荷長度(8bit):AH的負載長度。（3）保留(8bit)：供將來使用。（4）安全參數索引SPI(32bit)。（5）序列號(32bit)。（6）認證數據。4.IPSec的組成2.ESP協議ESP為IP報文以無連接的方式（以包為單位）提供完整性校驗、認證和加密服務，同時還可能提供防重放攻擊保護。在建立SA時可選擇所期望得到的安全服務，建議遵守以下約定：完整性校驗和身份認證建議同時使用。使用防重放攻擊時建議同時使用完整性校驗和身份認證。防重放攻擊保護的使用建議由接收端選擇。加密獨立于其他的安全服務，但建議使用加密時同時使用完整性校驗和身份認證。4.IPSec的組成2.ESP協議（1）安全參數索引（SPI）。（2）序列號。（3）載荷數據。（4）填充項。（5）填充項長度。（6）下一個頭。（7）認證數據。5.IPSec的工作模式IPSec協議（包括AH和ESP）既可以用來保護一個完整的IP載荷，也可以用來保護某個IP載荷的上層協議。這兩個方面的保護分別由IPSec兩種不同的“模式”來提供：傳輸模式和隧道模式。1.傳輸模式在傳輸模式中，IP頭與上層協議頭之間需插入一個特殊的IPSec頭。傳輸模式保護的是IP包的有效載荷或者說保護的是上層協議（如TCP、UDP和ICMP）在通常情況下（如圖6-8），傳輸模式只用于兩臺主機之間的安全通信。5.IPSec的工作模式2.隧道模式隧道模式為整個IP包提供保護。要保護的整個IP包都需封裝到另一個IP數據報中，同時在外部與內部IP頭之間插入一個IPSec頭。所有原始的或內部包通過這個隧道從IP網的一端傳遞到另一端，沿途的路由器只檢查最外面的IP報頭，不檢查內部原來的IP報頭。由于增加了一個新的IP報頭，因此，新IP報文的目的地址可能與原來的不一致。5.IPSec的工作模式3.綜合使用ESP和AH單獨的SA可以實現AH或ESP協議，但不能同時實現兩者。有時候，特定的通信量要同時調用AH和ESP的服務。鑒別與機密性的組合，如圖所示。使用兩個捆綁的傳輸SA，內部是ESPSA（沒有帶認證），外部是AHSA。5.IPSec的工作模式3.綜合使用ESP和AH與簡單使用帶鑒別的ESP相比，優勢在于鑒別覆蓋了更多的字段，包括了源和目的IP地址；缺點在于使用了兩個SA的開支。顯示AH和ESP隧道模式下的應用，其中包含了內容的AH傳輸SA和外部的ESP隧道SA。采用這種加密之前進行認證的方式更可取。6.IPSec的應用目前IPsec最主要的應用就是構建安全的虛擬專用網。虛擬專用網(VirtualPrivateNetwork，VPN)是一條穿過公用網絡的安全、穩定的隧道。通過對網絡數據的封包和加密傳輸，在一個公用網絡（通常是因特網）建立一個臨時的、安全的連接，從而實現在公網上傳輸私有數據，達到私有網絡的安全級別。IPSecVPN的應用場景分為3種：（1）Site-to-Site（站點到站點或者網關到網關）：如彎曲評論的3個機構分布在互聯網的3個不同的地方，各使用一個商務領航網關相互建立VPN隧道，企業內網（若干PC）之間的數據通過這些網關建立的IPSec隧道實現安全互聯。（2）End-to-End（端到端或者PC到PC）：兩個PC之間的通信由兩個PC之間的IPSec會話保護，而不是網關。（3）End-to-Site（端到站點或者PC到網關）：兩個PC之間的通信由網關和異地PC之間的IPSec進行保護。VPN只是IPSec的一種應用方式，它的目的是為IP提供高安全性特性，VPN則是在實現這種安全特性的方式下產生的解決方案。6.IPSec的應用一個典型的基于IPSec隧道的VPN，如圖所示。目前，市場上有很多VPN產品，支持各種安全協議（如PPTP、L2TP、IPSec、SSL），尤其以IPSec協議為基礎的VPN產品應用成熟和廣泛。對于以IPSec技術實現的VPN產品，應具備以下功能：（1）VNP產品支持ESP和AH格式。（2）IKE提供與安全相關的管理。IKE鑒別IPSec通信事務中的每個對等實體，協商安全策略并處理會話密鑰的交換。（3）證書管理。VPN產品要支持用于設備認證的X.509v3的證書系統。6.3SSL協議1.基本概念SSL(SecureSocketLayer)最早是netscape公司設計的用于HTTP協議加密的安全傳輸協議，SSL工作于TCP協議的傳輸層(TCP層)和應用程序之間。瀏覽器與WEB服務器之間在SSL的基礎上建立應用層會話，通信協議為HTTPS。作為一個中間層，應用程序只要采用SSL提供的一套SSL套接字API來替換標準的Socket套接字，就可以把程序轉換為SSL化的安全網絡程序，在傳輸過程中將由SSL協議實現數據機密性和完整性的保證。SSL協議的當前版本為3.0，當SSL取得大規模成功后，IETF將SSL作了標準化，規范為RFC2246，并將其稱為TLS（TransportLayerSecurity）。從技術上講，TLS1.0與SSL3.0的差別非常微小，SSL由于其歷史應用的原因在當前的商業應用程序之中使用得更多一些。1.基本概念目標：SSL被設計用來使用TCP提供一個可靠的端到端安全服務，為兩個通訊實體(客戶和服務器)之間提供保密性和完整性(身份鑒別)。SSL/TLS的使用：（1）SSL/TLS可以作為基本協議族的一個部分提供，因而對于應用程序是透明的。（2）將SSL/TLS嵌入到專門的軟件包中。目前，幾乎所有操作平臺上的Web瀏覽器（IE、Netscape）以及流行的Web服務器（IIS、NetscapeEnterpriseServer等）都支持SSL協議。使用該協議便宜且開發成本小1.基本概念SSL/TLS的使用2.SSL的體系結構SSL是使用TCP提供一個可靠的端對端的安全服務。SSL并不是單一的協議，而是由二層協議組成。SSL協議具有兩層結構，其底層是SSL記錄協議層（SSLRecordProtocolLayer），簡稱記錄層。其高層是SSL握手協議層（SSLHandshakeProtocolLayer），簡稱握手層。握手層允許通信實體在應用SSL協議傳送數據前相互認證身份、協商加密算法、生成密鑰等。記錄層則封裝各種高層協議，具體實施壓縮與解壓縮、加密與解密、計算與驗證消息認證碼（MAC）等與安全有關的操作。2.SSL的體系結構SSL協議有兩個重要的概念是SSL連接和SSL會話。它們分別被定義如下：（1）SSL會話SSL會話建立客戶與服務器之間的一個關聯（Association）。每一組客戶端與服務器之間就是一個SSLsession。這些會話定義一組以密碼為基礎的安全性參數，這些參數能夠由多個連接來共同使用。SSL會話狀態參數：Sessionidentifier（會話標識符）：服務器選擇的一個任意字節序列，用以標識一個活動的或可激活的會話狀態。Peercertificate（對方認證）：客戶和服務器的X509.v3格式證書。Compressionmethod（壓縮算法）：加密前進行數據壓縮的算法。Mastersecret（主密鑰）：48位秘密，在client與server之間共享。Cipherspec（密碼規格）：指握手協議協商的一套加密參數，包括數據加密算法以及計算消息認證碼(MAC)所使用雜湊算法（如MD5或SHA-1）。Isresumable:一個標志，指明該會話是否能用于產生一個新連接。2.SSL的體系結構（2）SSL連接SSL連接是一個在傳輸層協議上的傳輸媒介，它提供一個適當的服務。連接建立在會話的基礎上，每個連接與一個會話相關聯，并對應到一個會話。多個連接可以共用一個會話，避免每次有新的連接時，都得重新協調安全性參數的過程，從而大大減少開銷。SSL連接狀態參數：Serverandclientrandom:server和client為每一個連接所選擇的字節序列。ServerwriteMACsecret:一個密鑰，用來對server送出的數據進行MAC操作。ClientwriteMACsecret:一個密鑰，用來對client送出的數據進行MAC操作。Serverwritekey:用于server進行數據加密，client進行數據解密的對稱保密密鑰。Clientwitekey:用于client進行數據加密，server進行數據解密的對稱保密密鑰。Initializationvectors:當數據加密采用CBC方式時，每一個密鑰保持一個IV。該字段首先由SSLHandshakeProtocol，以后保留每次最后的密文數據塊作為IV。Sequencenumber:每一方為每一個連接的數據發送與接收維護單獨的順序號。當一方發送或接收一個改變的cipherspecmessage時，序號置為0。3.SSL握手層SSL握手層包含SSL握手協議、SSL修改密文規約協議和SSL警告協議。1.修改密文規約協議（SSLChangeCipherSpecProtocol）修改密文規約協議由單個字節組成，告知記錄層按照當前密碼規范中所指定的方式進行加密和壓縮。SSL修改密文規約協議用來發送修改密文規約協議信息。任何時候客戶都能請求修改密碼參數，比如握手密鑰交換。在修改密文規約的通告發出以后，客戶方就發出一個握手密鑰交換信息（如果可得到的話），鑒定認證信息，服務器則在處理了密鑰交換信息之后發送一個修改密文規約信息。此后，新的雙方約定的密鑰就將一直使用到下次提出修改密鑰規約請求為止。3.SSL握手層2.告警協議（SSLAlertProtocol）告警協議將告警信息以及嚴重程度傳遞給TLS會話中的主體。每個消息由兩個字節組成。告警級別1為告警，告警級別2為致命的告警。若一方檢測到一個錯誤，就向另一方發送消息。若是致命的，雙方關閉連接。致命告警代碼：unexpected_message:收到意外消息bad_record_mac:收到不正確的mac.decomression_failure:解壓縮函數受到不適當的輸入（例如不能解壓縮或解壓縮成大于最多允許的長度）handshake_failure:指定的選項可用時，發送者不能協商可接受的安全參數集合。其余告警代碼：Close_notify:通知接收方不再通過該連接發送任何消息No_certificate:沒有適當的證書可用。Unsupported_certificate:收到證書類型不支持3.SSL握手層3.SSL握手協議Handshake協議用來讓客戶端及服務器確認彼此的身份。協助雙方選擇連接時所使用的加密算法、MAC算法、及相關密鑰。Handshake由一些客戶與服務器交換的消息所構成，每一個消息都含有以下三個字段：類型(Type)，1個字節：表示消息的類型，總共有十種。長度(Length)，3個字節：消息的位組長度。內容(Content)，大于或等于1個字節，與此消息有關的參數。3.SSL握手層3.SSL握手層客戶端與服務器產生一條新連接所要進行的初始交換過程包括四個階段，即建立安全能力、服務器認證與密鑰交換、客戶端認證與密鑰交換、完成。第一階段：建立起安全協商客戶發送一個client_hello消息，包括以下參數：版本、隨機數(32位時間戳+28字節隨機序列)、會話ID、客戶支持的密碼算法列表(CipherSuite)、客戶支持的壓縮方法列表客戶等待服務器的server_hello消息服務器發送server_hello消息，參數：客戶建議的低版本以及服務器支持的最高版本、服務器產生的隨機數、會話ID、服務器從客戶建議的密碼算法中挑出一套、服務器從客戶建議的壓縮方法中挑出一個3.SSL握手層第二階段：服務器認證和密鑰交換服務器發送自己的證書，消息包含一個X.509證書，或者一條證書鏈（除了匿名DH之外的密鑰交換方法都需要）服務器發送server_key_exchange消息可選的，有些情況下可以不需要。只有當服務器的證書沒有包含必需的數據的時候才發送此消息消息包含簽名，被簽名的內容包括兩個隨機數以及服務器參數服務器發送certificate_request消息非匿名server可以向客戶請求一個證書包含證書類型和Cas服務器發送server_hello_done,然后等待應答3.SSL握手層第三階段：客戶端認證和密鑰交換客戶收到server_done消息后，它根據需要檢查服務器提供的證書，并判斷server_hello的參數是否可以接受，如果都沒有問題的話，發送一個或多個消息給服務器如果服務器請求證書的話，則客戶首先發送一個certificate消息，若客戶沒有證書，則發送一個no_certificate警告然后客戶發送client_key_exchange消息，消息的內容取決于密鑰交換的類型最后，客戶發送一個certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值(用master_secret)進行簽名3.SSL握手層第四階段：結束客戶發送一個change_cipher_spec消息，并且把協商得到的CipherSuite拷貝到當前連接的狀態之中然后，客戶用新的算法、密鑰參數發送一個finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經成功。其中包括一個校驗值，對所有以來的消息進行校驗。服務器同樣發送change_cipher_spec消息和finished消息。握手過程完成，客戶和服務器可以交換應用層數據。4.SSL記錄層SSL記錄層為SSL連接提供兩種服務（1）保密性。握手協議定義一個共享的保密密鑰用于對SSL有效載荷加密。（2）消息完整性。握手協議定義一個共享的保密密鑰用于形成MAC。4.SSL記錄層SSL從應用層取得的數據需要重定格式（分片、可選的壓縮、應用MAC、加密等）后才能傳給傳輸層進行發送。同樣，當SSL協議從傳輸層接收到數據后需要對其進行解密等操作后才能交給上層的應用層。這個工作是由SSL記錄協議完成的。（1）fragmentation：上層消息的數據被分片成214(16384)字節大小的塊，或者更小（2）compression(可選)：必須是無損壓縮，如果數據增加的話，則增加部分的長度不超過1024字節（3）MAC計算：使用共享的密鑰MAC_write_secrethash(MAC_write_secret||pad_2||hash(MAC_write_secret||pad_1||seq_num||SSLCompressed.type||SSLCompressed.length||SSLCompressed.fragment))其中：MAC_write_secret:

共享的保密密鑰；hash:密碼散列函數（MD5或SHA-1）；pad_1:0x36重復48次(MD5)；或40次(SHA-1)；pad_2:0x5C重復48次(MD5)；或40次(SHA-1)；seq_num:

該消息的序列號；SSLCompressed.type:更高層協議用于處理本分段；SSLCompressed.length:壓縮分段的長度；SSLCompressed.fragment:壓縮的分段(無壓縮時為明文段)4.SSL記錄層SSL從應用層取得的數據需要重定格式（分片、可選的壓縮、應用MAC、加密等）后才能傳給傳輸層進行發送。同樣，當SSL協議從傳輸層接收到數據后需要對其進行解密等操作后才能交給上層的應用層。這個工作是由SSL記錄協議完成的。（1）fragmentation：上層消息的數據被分片成214(16384)字節大小的塊，或者更小（2）compression(可選)：必須是無損壓縮，如果數據增加的話，則增加部分的長度不超過1024字節（3）MAC計算：使用共享的密鑰MAC_write_secrethash(MAC_write_secret||pad_2||hash(MAC_write_secret||pad_1||seq_num||SSLCompressed.type||SSLCompressed.length||SSLCompressed.fragment))4.SSL記錄層（4）加密采用CBC，算法由cipherspec指定數據長度不超過214+2048字節，包括填充值IV，初始協商指定，以后，前后記錄連接起來說明：如果是流密碼算法，則不需要padding4.SSL記錄層（5）加SSL記錄協議頭SSL記錄協議最后的步驟是準備一個記錄協議報頭，包含以下字段：ContentType：8位；上層協議類型：Majorversion；Minnorversion：16位，主次版本；壓縮長度：16位；加密后數據的長度，不超過214+2048字節；EncryptedDatafragment：密文數據。5.SSL使用中的問題當IE通過點擊圖像或者在幀中連接到一個服務器時，IE只檢查SSL證書是否是由可信的根服務商提供的，而沒有驗證證書有效期以及其他內容。另外，在同一個IE會話中，一旦成功地建立了SSL連接，對于新的SSL連接，IE將不再對證書進行任何的檢查。對于當前這個頁面而言，其實不危險，問題在于IE會把這個證書緩存起來，并標記為可信任的，一直到瀏覽器的會話結束。這意味著，假如說，IE客戶在訪問一個HTTP頁面時，如果該頁面被插入一個包含指向有問題的SSLserver的HTTPS對象(比如說一個image)的話，IE不會警告遇到一個非法的證書，只要這個證書確實是被可信CA簽名的。一個惡意web站點可以使用一個偽造的證書冒充是另外的可信站點來與IE客戶端建立連接，欺騙用戶。6.4Kerberos協議1.Kerberos協議概述在一個開放的分布式網絡環境中，用戶通過工作站訪問服務器上提供的服務。服務器應能夠限制非授權用戶的訪問并能夠認證對服務的請求。工作站不能夠被網絡服務所信任其能夠正確地認定用戶，即工作站存在三種威脅。一個工作站上一個用戶可能冒充另一個用戶操作；一個用戶可能改變一個工作站的網絡地址，從而冒充另一臺工作站工作；一個用戶可能竊聽他人的信息交換，并用回放攻擊獲得對一個服務器的訪問權或中斷服務器的運行。所有上述問題可以歸結為一個非授權用戶能夠獲得其無權訪問的服務或數據。不是為每一個服務器構造一個身份認證協議，Kerberos提供一個中心認證服務器，提供用戶到服務器和服務器到用戶的認證服務。Kerberos是一種網絡認證協議。Kerberos是美國麻省理工學院（MIT）開發的一種身份鑒別服務。Kerberos提供了一個集中式的認證服務器結構。公開發布的Kerberos版本包括版本4和版本5。2.Kerberos設計思路Kerberos系統應滿足的要求：（1）安全。網絡竊聽者不能獲得必要信息以假冒其它用戶；Kerberos應足夠強壯以至于潛在的敵人無法找到它的弱點連接。（2）可靠。Kerberos應高度可靠，并且應借助于一個分布式服務器體系結構，使得一個系統能夠備份另一個系統。（3）透明。理想情況下，用戶除了要求輸入口令以外應感覺不到認證的發生。（4）可伸縮。系統應能夠支持大數量的客戶和服務器。2.Kerberos設計思路1.一個簡單鑒別對話(1)C→AS:IDC||PC||IDv(2)AS→C:Ticket(3)C→V:IDC||TicketTicket=EKv[IDC,ADC,IDv]IDC：用戶C的標識PC：用戶口令IDv：服務器標識ADC：用戶網絡地址2.Kerberos設計思路1.一個簡單鑒別對話上述協議的問題：（1）口令明文傳送（2）票據的有效性（多次使用）（3）訪問多個服務器則需多次申請票據（即口令多次使用）解決辦法：（1）票據重用（ticketreusable）。（2）引入票據許可服務器（TGS-ticket-grantingserver） 用于向用戶分發服務器的訪問票據； 認證服務器AS并不直接向客戶發放訪問應用服務器的票據，而是由TGS服務器來向客戶發放。2.Kerberos設計思路2.改進后的假想的會話上述協議的問題：(1)C→AS:IDC||IDtgs(2)AS→C:EKC[Tickettgs](3)C→TGS:IDC||IDv||Tickettgs(4)TGS→C:TicketV(5)C→V:IDC||TicketVTickettgs=EKtgs[IDC||ADC||IDtgs||TS1||Lifetime1]TicketV=EKV[IDC||ADC||IDV||TS2||Lifetime2]用戶先向AS請求一張票據許可票(Tickettgs),用戶工作站中的客戶模塊將保存這張票據。每當用戶需要訪問新的服務時，客戶便使用這張能鑒別自己的票據向TGS發出請求。TGS則發回一張針對請求的特定服務的許可票據。AS發回的票據是加密的，加密密鑰是由用戶口令導出的。當相應到達客戶端時，客戶端提示用戶輸入口令，產生密鑰，若口令正確，票據就能正確恢復。2.Kerberos設計思路2.改進后的假想的會話上述協議的問題：仍然存在的問題：（1）票據許可票據(Tickettgs)的生存期。若太短，用戶總被要求輸入口令。若太長，敵手就有更多重放的機會。可以竊聽網絡，獲得票據許可票據，等待合法用戶退出登錄，偽造合法用戶的地址。必須能證明使用票據的人就是申請票據的人。（2）需要服務器向客戶鑒別。敵手可能破壞系統配置，使發往服務器的報文轉送到另一個位置，假的服務器來接收來自用戶的任何消息。解決方案：使用會話密鑰。讓AS以安全的方式向客戶和TGS各自提供會話密鑰，然后客戶在與TGS交互過程中，用此會話密鑰處理，以證明自己的身份。2.Kerberos設計思路3.Kerberosv4認證認證服務交換：獲得TGT（1）C→AS:IDc||IDtgs||TS1（2）AS→C:E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])Tickettgs=E(Ktgs,[Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])Message(1)：Client請求ticket-grantingticketIDC：告訴AS本client端的用戶標識；

IDtgs：告訴AS用戶請求訪問TGS；

TS1：讓AS驗證client端的時鐘是與AS的時鐘同步的；2.Kerberos設計思路3.Kerberosv4認證Message(2)：AS返回ticket-grantingticketEKC：基于用戶口令的加密，使得AS和client可以驗證口令，并保護該信息。

Kc,tgs：sessionkey的副本，由AS產生，client可用于在AS與client之間信息的安全交換，而不必共用一個永久的key。

IDtgs：確認這個ticket是為TGS制作的。

TS2：告訴client該ticket簽發的時間。

Lifetime2: 告訴client該ticket的有效期；

Tickettgs: client用來訪問TGS的ticket。2.Kerberos設計思路3.Kerberosv4認證Message(2)：AS返回ticket-grantingticket票據許可服務交換：獲得服務許可票據（3）C→TGS:IDv||Tickettgs||Authenticatorc（4）TGS→C:E(Kc,tgs,[Kc,v||IDv||TS4||Ticketv])Tickettgs=E(Ktgs,[Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])Ticketv=E(Kv,[Kc,v||IDC||ADC||IDv||TS4||Lifetime4])Authenticatorc=E(Kc,tgs,[IDC||ADC||TS3])2.Kerberos設計思路3.Kerberosv4認證Message(3)：client請求service-grantingticketIDv:告訴TGS用戶要訪問服務器