Internet安全協(xié)議體系課件

1、第07章 Internet安全協(xié)議體系主講人：郭松濤單 位：重慶大學(xué)計算機學(xué)院2007年11月第1頁，共150頁。目錄7.1 TCP/IP安全協(xié)議體系概述7.2 數(shù)據(jù)聯(lián)路層安全協(xié)議7.3 網(wǎng)絡(luò)層安全全協(xié)議7.4 傳輸層安全協(xié)議7.5 代理協(xié)議7.6 應(yīng)用層安全協(xié)議第2頁，共150頁。ISO/OSI參考模型TCP/IP層次模型TCP/IP體系應(yīng)用層（A）應(yīng)用層FTPTELNETHTTPSNMPNFS表示層（P）XDRSMTR會話層（S）RPC傳輸層（T）傳輸層TCP/UDP網(wǎng)絡(luò)層（N）IP層IPICMPARP、RARP數(shù)據(jù)鏈路層（DL）網(wǎng)絡(luò)接口層硬件協(xié)議（不指定）物理層（PH）7.1 TCP/I

2、P安全協(xié)議體系概述第3頁，共150頁。TCP/IP網(wǎng)絡(luò)安全體系的三維框架結(jié)構(gòu) 實體單元應(yīng) 用 層傳 輸 層網(wǎng) 絡(luò) 層鏈 路 層物 理 層分層安全管理理 管 全 安安全屬性（安全服務(wù)/安全機制）應(yīng)用系統(tǒng)安全計算機網(wǎng)絡(luò)安全0終端系統(tǒng)安全(計算機+OS)認證訪問控制數(shù)據(jù)完整性抗抵賴可用性、可控性可審計性安 全 管 理第4頁，共150頁。現(xiàn)有TCP/IP網(wǎng)絡(luò)安全技術(shù)框架 第5頁，共150頁。安 全 服 務(wù)TCP/IP 協(xié) 議 層網(wǎng)絡(luò)接口IP層傳輸層應(yīng)用層對等實體認證-YYY數(shù)據(jù)源認證-YYY訪問控制服務(wù)-YYY連接機密性YYYY無連接機密性YYYY選擇字段機密性-Y業(yè)務(wù)流機密性YY-YTCP/IP協(xié)議

3、安全模型中提供的安全服務(wù)第6頁，共150頁。可恢復(fù)連接完整性-YY不可恢復(fù)連接完整性-YYY選擇字段連接完整性-Y無連接完整性-YYY選擇字段非連接完整性-Y源發(fā)方不可抵賴-Y接收方不可抵賴-Y說明：Y：服務(wù)應(yīng)作為選項并入該層的標準之中-：不提供第7頁，共150頁。S/MIME PGP SOCKS等應(yīng)用層SSL TLS 等傳輸層IPv6 IPSec 等網(wǎng)際層PPTP L2F L2TP等網(wǎng)絡(luò)接入層TCP/IP中的安全協(xié)議體系（講課內(nèi)容）第8頁，共150頁。第9頁，共150頁。安全協(xié)議概述TCP/IP網(wǎng)絡(luò)安全協(xié)議按層次歸類如下： 1、網(wǎng)絡(luò)接口層安全協(xié)議 主要用于鏈路層連接的認證與保密,已有的安全協(xié)

4、議如下： （1）隧道協(xié)議PPTP、L2F、L2TP （2）口令認證協(xié)議（PAP） （3）挑戰(zhàn)握手認證協(xié)議（CHAP） （4） Shiva口令認證協(xié)議（SPAP） （5）擴展認證協(xié)議（EAP） （6）微軟的挑戰(zhàn)/響應(yīng)握手認證協(xié)議（MS-CHAP） （7）微軟的點對點加密協(xié)議（MS-MPPE） 第10頁，共150頁。2、網(wǎng)絡(luò)層安全協(xié)議 網(wǎng)絡(luò)層是實現(xiàn)全面安全的最低層次，網(wǎng)絡(luò)層安全協(xié)議可以提供ISO安全體系結(jié)構(gòu)中所定義的所有安全服務(wù)。（1） 前期安全協(xié)議 1）NSA/NIST的安全協(xié)議3（SP3） 2）ISO的網(wǎng)絡(luò)層安全協(xié)議（NLSP） 3）NIST的完整NLSP（I-NLSP） 4）swIPe（2）

5、 IETF的IPSec WG的IP安全協(xié)議（IPSec） 1）認證頭（AH） 2）封裝安全有效負載（ESP） 3）Internet密鑰交換協(xié)議（IKE）第11頁，共150頁。（3） IETF的IPSec WG的Internet密鑰管理協(xié)議（IKMP） 1）標準密鑰管理協(xié)議（MKNP） 2）IP協(xié)議的簡單密鑰管理（SKIP） 3）Photuris密鑰管理協(xié)議 4）安全密鑰交換機制（SKEME） 5）Internet安全關(guān)聯(lián)和密鑰管理協(xié)議（ISAKMP） 6）OAKLEY密鑰決定協(xié)議（4） 其它安全協(xié)議 1）機密IP封裝協(xié)議（CIPE） 2）通用路由封裝協(xié)議（GRE） 3）包過濾信息協(xié)議（PFIP

6、） 第12頁，共150頁。3、傳輸層安全協(xié)議 （1）前期協(xié)議 NSA/NIST的安全協(xié)議4（SP4） ISO的TLSP （2）安全SHELL（SSH） SSH傳輸層協(xié)議 SSH認證協(xié)議 （3）安全套接字層（SSL） SSL記錄協(xié)議 SSL握手協(xié)議 （4）私有通信技術(shù)（PCT） （5）IEIF TLS WG的傳輸層安全協(xié)議（TLSP） （6）SOCKSv5 第13頁，共150頁。4、應(yīng)用層安全協(xié)議 包括安全增強的應(yīng)用協(xié)議(已經(jīng)正式存在的或安全的新協(xié)議)和認證與密鑰分發(fā)系統(tǒng)。（1）安全增強的應(yīng)用協(xié)議 遠程終端訪問（STel） 安全RPC認證（SRA） NATAS第14頁，共150頁。（2） 電子郵

7、件（SMTP） 保密增強郵件（PEM） PGP 安全MIME（S/MIME） MIME對象安全服務(wù)（MOSS） 消息安全協(xié)議（MSP） APOPGnu保密防護（GnuPG）第15頁，共150頁。（3）WWW事務(wù)（HTTP） 使用SSL/TLS 安全HTTP（S-HTTP） GSS-API方法 PGP-CCI方法（4）域名系統(tǒng)（DNS） 安全DNS（Secure DNS） RFC2065域名系統(tǒng)安全擴展第16頁，共150頁。（5）文件傳輸（FTP） RFC2228 FTP安全擴展（6）其它應(yīng)用 網(wǎng)絡(luò)管理：簡單網(wǎng)絡(luò)管理協(xié)議（SNMPv2、SNMPv3） 機密文件系統(tǒng)（CFS）Andrew文件系統(tǒng)（

8、AFS）第17頁，共150頁。5、電子支付方案 （1）電子貨幣（Electronic Cash） Ecash（Digicash） CAFE（European R&D Project） NetCash（ISI/USC） Mondex（UK） CyberCash （2）電子支票（Electronic Checks）PayNow（CyberCash） NteCheque（ISI/USC）第18頁，共150頁。（3）信用卡支付（Credit Card Payment） iKP（i-Key-Protocol） 安全電子支付協(xié)議（SEPP） 安全交易技術(shù)（STT） 安全電子交易（SET）（4）微支付（Mi

9、cropayments） Millicent Pay Word and MicroMint CyberCoin NetBill 第19頁，共150頁。 6、認證和密鑰分配系統(tǒng) Kerberos 遠程認證撥入用戶服務(wù)（RADIUS） 網(wǎng)絡(luò)安全程序（NetSP） SPX（DEC） TESS（Univ. of Karlsruhe） SESAME DCE（Open Group）第20頁，共150頁。 7、其它安全協(xié)議 S/KEY 加密控制協(xié)議（ECP） TACACS/TACACS+ FWZ密鑰管理協(xié)議 X.509數(shù)字證書 證書登記協(xié)議（CeP） 在線證書狀態(tài)協(xié)議（OCSP） 內(nèi)容引向協(xié)議（UFP） U

10、RL過濾協(xié)議 可疑行為監(jiān)控協(xié)議（SAMP）第21頁，共150頁。7.2 數(shù)據(jù)鏈路層安全協(xié)議7.2.1 PPP協(xié)議7.2.2 隧道技術(shù)原理7.2.3 PPTP協(xié)議7.2.4 L2TP協(xié)議第22頁，共150頁。7.2.1 PPP協(xié)議1、SLIP協(xié)議簡介 ( Serial Line Internet Protocol) 通過標準的RS-232異步串行線(撥號電話線) 傳送IP包的方法,是在電話線上交換Internet業(yè)務(wù)的早期標準。不足： (1) 沒有錯誤檢測和糾錯功能 (2) SL IP 只支持IP (3) 不支持動態(tài)IP地址分配 雙方都必須預(yù)先知道對方的IP 地址,地址不能動態(tài)分配,這對于通過電

11、話線上網(wǎng)的用戶主機來說,就造成了IP 地址很大的浪費 (4) 沒有身份驗證功能 因此任何一方都不知道在與誰通第23頁，共150頁。2、PPP協(xié)議(point to point protocol) (1) 特點 實現(xiàn)關(guān)于廣域網(wǎng)絡(luò)環(huán)境下傳送Ip數(shù)據(jù)報的協(xié)議；是SLIP的改進。 1) 支持多協(xié)議傳輸機制 不僅支持IP,而且還支持IPX和Apple talk等多種通信協(xié)議 2) 支持協(xié)商配置 在開始連接時雙方可以協(xié)商配置參數(shù)(如IP 地址,頭壓縮等) 3) PPP 提供2種自動登錄方法 口令確認協(xié)議PAP(password authentication protocol) 應(yīng)答握手確認協(xié)議CHAP(c

12、hallenge handshake authentication protocol) 4）具有錯誤檢測手段, 比較可靠第24頁，共150頁。(2) 使用環(huán)境第25頁，共150頁。(3) PPP協(xié)議的構(gòu)成 PPP 主要包含3個方面的內(nèi)容: 1) 對多協(xié)議數(shù)據(jù)包的封裝; 2) 用于建立、設(shè)置、測試數(shù)據(jù)鏈路連接的鏈路控制協(xié)議LCP ( link con t ro l p ro toco l) ; 3) 用于建立、設(shè)置不同網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制協(xié)議NCP (netwo rk con t ro l p ro toco l) 本質(zhì)上，NCP是一簇協(xié)議的代名詞。若是用TCP/IP,對應(yīng)的協(xié)議名稱為IPCP第

13、26頁，共150頁。 1) 物理層:兼容常用硬件和廣域網(wǎng)網(wǎng)物理層協(xié)議 PPP 在設(shè)計時即考慮與常用的硬件兼容, 支持任何DTE-DCE 接口, 例如EIA RS-232C、EIA RS-242 和CC ITT V. 35 2) 數(shù)據(jù)鏈路層：基于HDLC協(xié)議 PPP 使用ISO 3309- 1979的HDLC (high level data link control) (用于同步環(huán)境) 和其修改版ISO 3390- 1984 PAAD1 (用于異步環(huán)境) 的原理、術(shù)語和幀結(jié)構(gòu),以HDLC 作為封裝的基礎(chǔ), 并使用HDLC 幀校驗序列進行錯誤檢測。PPP 封裝提供了在同一鏈路上不同網(wǎng)絡(luò)層協(xié)議的復(fù)

14、用, 因此很容易連接各種各樣的主機、網(wǎng)橋和路由器。第27頁，共150頁。3) 鏈路控制協(xié)議LCP（Link Control Protocol） 負責(zé)線路建立、測試和選項協(xié)商，鏈路釋放 使用多種物理層服務(wù)：modem、 HDLC bit-serial、 SDH/SONET等 提供協(xié)商機制 LCP用來在ESTABLISH狀態(tài)協(xié)商數(shù)據(jù)鏈路協(xié)議選項，并不關(guān)心選 項內(nèi)容，而是提供一種協(xié)商機制 鏈路質(zhì)量檢測辦法 11種幀類型 第28頁，共150頁。4) 網(wǎng)絡(luò)控制協(xié)議NCP(Network Control Protocol) 可支持多種網(wǎng)絡(luò)層協(xié)議 用于協(xié)商網(wǎng)絡(luò)層選項 對于所支持的每一個網(wǎng)絡(luò)層協(xié)議都有一個不同

15、的網(wǎng) 絡(luò)控制協(xié)議（NCP），用來建立和配置不同的網(wǎng)絡(luò)層協(xié)議 PPP被設(shè)計成允許同時使用多個網(wǎng)絡(luò)層協(xié)議 第29頁，共150頁。PPP協(xié)議應(yīng)用實例：家庭用戶撥號上網(wǎng) 1) 物理鏈路建立 撥號：PC-MODEM-路由器Modem(ISP) 響應(yīng)：路由器Modem-Modem-PC 2) 數(shù)據(jù)鏈路建立 PC路由器:LCP幀 3) 網(wǎng)絡(luò)層協(xié)議協(xié)商 PC路由器：NCP分組 如：PC要運行TCP/IP，則其需要IP。 ISP采用DHCP機制分配IP第30頁，共150頁。(3) PPP協(xié)議的幀格式F 凈荷CAF校驗和1 字節(jié)2/4 0 -最大長度111協(xié)議1/2F：首尾標志7Eh，透明傳輸采用字符填充A：地址

16、字段，永遠為FFh，表示所有站點都可以接收C：控制字段，默認為03h，表示無編號幀協(xié)議：指明凈荷字段的包類型,支持LCP、PAP、CHAP、IP、IPX、AppleTalk.PPP 幀中的協(xié)議字段是0 xc021 ,則表明它的有效載荷是一個LCP 包PPP 幀中的協(xié)議字段是0 x8021 ,則表明它的有效載荷是IPCP 包(NCP)PPP 幀中的協(xié)議字段是0 xc223 ,則表明它的有效載荷是一個CHAP包PPP 幀中的協(xié)議字段是0 xc023 ,則表明它的有效載荷是一個PAP 包PPP 幀中的協(xié)議字段是0 x0021 ,則表明它的有效載荷是IP 包第31頁，共150頁。(4) LCP包的格式

17、代碼域：LCP包的類型(1個字節(jié))標識域：LCP包的序號(1個字節(jié))長度域：LCP包的長度(2個字節(jié))數(shù)據(jù)域：選項或重要參數(shù),格式如下第32頁，共150頁。LCP 包的代碼域第33頁，共150頁。LCP的選項域第34頁，共150頁。(5) IPCP包的格式 格式完全同LCP, 代碼域使用LCP定義的前面7個 選項含義如下：第35頁，共150頁。(6) IP數(shù)據(jù)報的封裝 協(xié)議：0X0021 第36頁，共150頁。(7) 協(xié)議執(zhí)行過程建立結(jié)束：LCP報文身分認證：CHAP報文網(wǎng)絡(luò)工作：NCP報文第37頁，共150頁。第38頁，共150頁。7.2.2 隧道技術(shù)原理 1、 基本思想 隧道技術(shù)是一種通過

18、使用互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)設(shè)施在網(wǎng)絡(luò)之間傳遞數(shù)據(jù)的方式。使用隧道傳遞的數(shù)據(jù)（或負載）可以是不同協(xié)議的數(shù)據(jù)幀或包。 隧道協(xié)議將這些其它協(xié)議的數(shù)據(jù)幀或包重新封裝在新的包頭中發(fā)送。新的包頭提供了路由信息，從而使該新的報文能夠在互聯(lián)網(wǎng)絡(luò)中被傳遞，被封裝的數(shù)據(jù)包一旦到達網(wǎng)絡(luò)終點，數(shù)據(jù)將被解包并轉(zhuǎn)發(fā)到最終目的地。 2、 隧道的定義 被封裝的數(shù)據(jù)包在公共互聯(lián)網(wǎng)絡(luò)上傳遞時所經(jīng)過的邏輯路徑稱為隧道。 隧道技術(shù)是指包括數(shù)據(jù)封裝，傳輸和解包在內(nèi)的全過程第39頁，共150頁。3、隧道所使用的傳輸網(wǎng)絡(luò) 可是任何類型的公共互聯(lián)網(wǎng)絡(luò)。 目前普遍使用的是基于Internet(IP網(wǎng)絡(luò))隧道技術(shù)4、隧道技術(shù)類別 (1)2層的隧道協(xié)議

19、2層隧道協(xié)議對應(yīng)OSI模型的數(shù)據(jù)鏈路層,以幀為數(shù)據(jù)交換單位。 PPTP，L2TP和L2F(第2層轉(zhuǎn)發(fā))都屬于第2層隧道協(xié)議，都是將數(shù)據(jù)封裝在點對點協(xié)議(PPP)幀中通過互聯(lián)網(wǎng)絡(luò)發(fā)送 (2)3層的隧道協(xié)議 3層隧道協(xié)議對應(yīng)OSI模型的網(wǎng)絡(luò)層，以包為數(shù)據(jù)交換單位。 IP over IP以及IPSec隧道模式都屬于第3層隧道協(xié)議，都是將IP包封裝在附加的IP包頭中通過IP網(wǎng)絡(luò)傳送第40頁，共150頁。不同隧道協(xié)議的本質(zhì)區(qū)別在于用戶的數(shù)據(jù)包是被封裝在哪種數(shù)據(jù)包中在隧道中傳輸?shù)牡?1頁，共150頁。 5、隧道協(xié)議的構(gòu)成 無論哪種隧道協(xié)議都是由 傳輸?shù)妮d體 不同的封裝格式 被傳輸數(shù)據(jù)包 三部分組成的乘客協(xié)

20、議封裝協(xié)議傳輸協(xié)議傳輸協(xié)議：IP是一種常見的傳輸協(xié)議；幀中繼、ATM 也是很好的傳輸協(xié)議封裝協(xié)議：被用來建立、保持和拆卸隧道。 包括L2F、L2TP、GRE 協(xié)議。乘客協(xié)議：是被封裝的協(xié)議，可以是PPP、SLIP、IPX、IP等不同隧道協(xié)議的本質(zhì)區(qū)別在于： 用戶的數(shù)據(jù)包是被封裝在哪種數(shù)據(jù)包中在隧道中傳輸?shù)牡?2頁，共150頁。7.2.3 PPTP協(xié)議1、基于PPP的傳統(tǒng)網(wǎng)絡(luò)接入服務(wù)器NAS的功能 NAS負責(zé)管理對所有網(wǎng)絡(luò)設(shè)備和資源的訪問,一般具有以下幾種功能： (1)提供到PSTN或ISDN的物理接口,控制外部調(diào)制解調(diào)器和終端適配器。 (2)提供點對點協(xié)議(PPP)鏈路控制協(xié)議(LCP)會話的

21、邏輯終止。 (3)參與到PPP認證協(xié)議中。 (4)執(zhí)行各種PPP網(wǎng)絡(luò)控制協(xié)議（NPC）的邏輯終止 (5)為PPP多鏈路協(xié)議提供信道聚集和捆綁管理。 (6)執(zhí)行NAS接口之間的多協(xié)議路由和橋接。第43頁，共150頁。2、基于PPP的傳統(tǒng)網(wǎng)絡(luò)接入服務(wù)器的不足 (1)PPP主要通過撥號或?qū)＞€方式建立點對點連接發(fā)送數(shù)據(jù) (2)若用戶與NAS相距遙遠，需要遠程撥號或遠程專線，這將使系統(tǒng)的使用效率低，成本高 (3)能否借助Internet這種便利資源來建立與遠程主機的連接？這就是PPTP的出發(fā)點。 第44頁，共150頁。3、PPTP協(xié)議的基本模型 (1) NAS的任務(wù)在PPTP協(xié)議中被分配給兩個主要的組件

22、 PPTP訪問集中器PAC(PPTP Access Concentrator) PPTP網(wǎng)絡(luò)服務(wù)器PNS(PPTP Network Server) (2) PPTP訪問集中器（PAC） PAC與一條或多條PSTN或ISDN線路相連。它完成PPP操作并處理PPTP協(xié)議。PAC負責(zé)為PSTN或ISDN網(wǎng)絡(luò)提供物理接口，并為PPP鏈路控制協(xié)議會話提供邏輯終止。具有NAS的第(1)、(2）、(3)種功能。 (3) PPTP網(wǎng)絡(luò)服務(wù)器(PNS) PNS負責(zé)處理服務(wù)器端的PPTP協(xié)議。PNS為NAS的不同的接口之間提供多協(xié)議路由和橋接，負責(zé)PPP網(wǎng)絡(luò)控制協(xié)議的邏輯終止 具有NAS的第(3)、(4)、(5)

23、、(6)種功能第45頁，共150頁?？蛻魴CPPPPACPNSPPTP隧道位于ISP處專用網(wǎng)絡(luò)PPTP協(xié)議模型 PAC把PPP數(shù)據(jù)幀封裝后在因特網(wǎng)上傳輸。這些IP數(shù)據(jù)包在因特網(wǎng)上按特定的路由傳送，直到到達PNS。 PNS把IP數(shù)據(jù)包分解為PPP數(shù)據(jù)包，并從這些PPP數(shù)據(jù)包中提取出必要的信息，然后把數(shù)據(jù)包通過專用網(wǎng)絡(luò)發(fā)送到目的計算機 第46頁，共150頁。4、PPTP協(xié)議過程 PPTP有兩個過程：控制連接過程和數(shù)據(jù)傳輸過程 (1) 控制連接 在PNSPAC間進行傳輸數(shù)據(jù)前，必須建立一個控制連接?？刂七B接是一個標準的TCP會話(服務(wù)端TCP端口為1723)，通過該連接傳遞的報文稱為控制報文。 控制連

24、接負責(zé)建立，管理、釋放和拆卸PPTP隧道 控制報文用來通知PAC有來自PNS的出網(wǎng)呼叫， 或是通知PNS有 來自PAC的入網(wǎng)呼叫 第47頁，共150頁?？刂茍笪母袷絀P首部TCP首部PPTP控制報文第48頁，共150頁。start_control_connection_request:啟動PPTP會話請求PPTP Message Type:控制連接，該位為1Control Message Type:start_Control_Connection_Request,為1Framing Capabilities:異步/同步幀模式(1/2)Bearer Capabilities:模擬/數(shù)字信道（1/

25、2）第49頁，共150頁。start_control_connection_Reply:對啟動PPTP會話請求的響應(yīng)PPTP Message Type:控制連接，該位為1Control Message Type:start_Control_Connection_Reply,為2Framing Capabilities:異步/同步幀模式(1/2)Bearer Capabilities:模擬/數(shù)字信道（1/2）第50頁，共150頁。(2) 數(shù)據(jù)傳輸連接 在PPTP隧道建立后，就可以在客戶機和PPTP服務(wù)器之間傳輸數(shù)據(jù)了。 PPTP隧道上傳輸?shù)氖荘PP數(shù)據(jù)包。PPP數(shù)據(jù)包是封裝在GRE(通用路由封裝

26、)包中的，而GER包是在IP層上傳送的 報文格式IP首部GRE首部PPP數(shù)據(jù)包第51頁，共150頁。撥號建立PPP連接到VPNStart_control_connection_request Start_control_connection_reply Incoming_call_request Incoming_call_reply Incoming_call_connected Outcoming_call_request Outcoming_call_reply Call_clear_request Call_clear_reply Stop_control_connection_req

27、uest Stop_control_connection_reply PPP數(shù)據(jù)包 第52頁，共150頁。撥號建立PPP連接到VPNStart_control_connection_request Start_control_connection_reply Incoming_call_request Incoming_call_reply Incoming_call_connected PPP數(shù)據(jù)包 流入呼叫 流出呼叫 Outcoming_call_request Outcoming_call_reply PPP數(shù)據(jù)包 Call_clear_request Call_clear_reply

28、清除呼叫 停止會話 關(guān)閉PPP連接Stop_control_connection_request Stop_control_connection_reply 開始會話 客戶機PACPNS第53頁，共150頁。7.2.4 L2TP協(xié)議1、第二層隧道協(xié)議-L2TP L2TP是一個國際標準隧道協(xié)議，它結(jié)合了PPTP協(xié)議以及第二層轉(zhuǎn)發(fā)L2F協(xié)議的優(yōu)點。 L2TP與PPTP的最大不同在于L2TP將控制報文和數(shù)據(jù)報文合二為一，并運行在UDP上，而不是TCP上。UDP省去了TCP中同步、檢錯、重傳等機制，因此L2TP速度很快。L2TP協(xié)議封裝格式如下：與PPTP類似，L2TP也可支持多種協(xié)議。L2TP協(xié)議本

29、身并沒有提供任何加密功能第54頁，共150頁。UDP2、L2TP的典型工作模型第55頁，共150頁。UDP第56頁，共150頁。3、L2TP協(xié)議及報文格式PPP幀L2TP數(shù)據(jù)報文L2TP數(shù)據(jù)通道（不可靠）L2TP控制報文L2TP控制通道（可靠）報文傳輸(UDP、FR、ATM)第57頁，共150頁。T:報文類型 0-數(shù)據(jù)報文，1-控制報文L:長度域指示符 1：有長度域,對控制報文必須置其為1S:序號Ns、Nr域指示符 1：有Ns、Nr域,對控制報文必須置其為1O:offset size域指示符 1：有offset size域,對控制報文必須置其為0P:優(yōu)先級域 1：則數(shù)據(jù)消息報文需要優(yōu)先被處理,

30、對控制報文 必須置其為0X:保留比特L2TP報文頭結(jié)構(gòu)(數(shù)據(jù)與控制報文共用)第58頁，共150頁。Tunnel ID：隧道ID 控制連接的標識符；L2TP在LAC和LNS間建立的隧道在每一端都有一個標識符號。 該處的隧道標識符是隧道另一端(接收端)相應(yīng)的標識符Session ID 在一個隧道內(nèi)的會話IDOffset size 用于指明數(shù)據(jù)開始的位置第59頁，共150頁。控制報文類型第60頁，共150頁。4、PPTP和L2TP的差別 1) PPTP要求傳輸網(wǎng)絡(luò)為IP網(wǎng)絡(luò) L2TP只要求隧道媒介提供面向數(shù)據(jù)包的點對點的連接。 L2TP可以在IP(使用UDP)，F(xiàn)R永久虛擬電路(PVCs),X.25

31、虛擬電路(VCs)或ATM VCs網(wǎng)絡(luò)上使用。 2) PPTP只能在兩端點間建立單一隧道 L2TP支持在兩端點間使用多隧道。使用L2TP，用戶可以針對不同的服務(wù)質(zhì)量創(chuàng)建不同的隧道 3) L2TP可以提供包頭壓縮。 4) L2TP可以提供隧道驗證，而PPTP則不支持隧道驗證 但是當(dāng)L2TP或PPTP與IPSEC共同使用時，可以由IPSEC提供隧道驗證，不需要在第2層協(xié)議上驗證隧道第61頁，共150頁。7.3 網(wǎng)絡(luò)層安全協(xié)議-IPSec1、為什么需要在IP層提供安全性？ (1) IP數(shù)據(jù)報文沒有任何安全機制，可被 1）竊聽 2）篡改 3）假冒 。 (2) 在IP層提供安全性，對應(yīng)用、用戶是透明的第

32、62頁，共150頁。2、IP層需要什么樣的安全性 (1) 保密性：防止竊聽 利用加密技術(shù)實現(xiàn) (2) 完整性：防止篡改 利用消息鑒別技術(shù)實現(xiàn) (3) 鑒 別：防止假冒 確保通信雙方的真實性IPSec的主要特征是可以支持IP級所有流量的加密和/或認證第63頁，共150頁。3、IPSec的主要目標 期望安全的用戶能夠使用基于密碼學(xué)的安全機制應(yīng)能同時適用與IPv4和IPv6算法獨立有利于實現(xiàn)不同安全策略對沒有采用該機制的的用戶不會有副面影響 對上述特征的支持在IPv6中是強制的，在IPv4中是可選的。 這兩種情況下都是采用在主IP報頭后面接續(xù)擴展報頭的方法實現(xiàn)的。 認證的擴展報頭稱為AH (Auth

33、entication Header) 加密的擴展報頭稱為ESP header (Encapsulating Security Payload)第64頁，共150頁。4、IPSec在IP層提供安全服務(wù) 訪問控制 連接完整性 數(shù)據(jù)源認證 拒絕重放數(shù)據(jù)包 保密性（加密） 有限信息流保密性第65頁，共150頁。AH(認證)ESP(僅加密)ESP(加密+認證)訪問控制連接完整性數(shù)據(jù)源認證拒絕重放報文保密性有限信息流保密性第66頁，共150頁。5、IPSec的主要組成部分 (1)首部鑒別AH協(xié)議 AH協(xié)議提供數(shù)據(jù)源鑒別和數(shù)據(jù)完整性鑒別,這可以確保數(shù)據(jù)的完整性和真實性(含用戶和數(shù)據(jù)) (2)安全凈荷封裝ES

34、P協(xié)議 ESP協(xié)議提供數(shù)據(jù)的保密性,還提供可選的鑒別服務(wù),可抵抗重放攻擊 (3)因特網(wǎng)密鑰管理IKE協(xié)議 AH和ESP提供的安全保證依賴于它們使用的加密算法及其密鑰。 IKE定義了通信雙方間進行身份鑒別、協(xié)商加密算法、生成或分配共享的會話密鑰以及創(chuàng)建安全關(guān)聯(lián)SA的方法 第67頁，共150頁。1）IPSec 體系 體系文檔是RFC2401,它定義了IPSec的基本結(jié)構(gòu),指定IP 包的機密性(加密) 和身份認證使用傳輸安全協(xié)議ESP 或AH實現(xiàn)第68頁，共150頁。1) IPSec 體系 體系文檔是RFC2401,它定義了IPSec的基本結(jié)構(gòu),包括總體概念、安全需求、安全定義，以及定義IPSec技

35、術(shù)機制2) ESP( Encapsulating security payload ,封裝安全載荷) 協(xié)議文檔是RFC2406 ,定義了載荷頭( ESP 頭) 格式和服務(wù)類型以及包處理規(guī)則3) AH (Authentication Header , 認證報頭) 協(xié)議文檔RFC2402定義了AH頭格式、服務(wù)類型及包處理規(guī)則第69頁，共150頁。4) 加密算法 協(xié)議文檔是RFC2405 ,定義了DES - CBC作為ESP的加密算法以及如何實現(xiàn)DES - CBC 算法和初始化矢量( IV)的生成5) 認證算法 協(xié)議文檔是RFC2403 和RFC2404。 RFC2403定義了對ESP的認證算法為散

36、列函數(shù)MD5 或SHA的HMAC版本 RFC2404定義了默認情況下AH的認證算法是MD5或SHA的HMAC版本第70頁，共150頁。 6) IKE ( Internet key Exchange ,因特網(wǎng)密鑰交換) 協(xié)議文檔是RFC2409 ,定義了IPSec通信雙方如何動態(tài)建立共享安全參數(shù) (即建立安全聯(lián)盟)和經(jīng)認證過的密鑰 IKE的功能包括:加密算法和密鑰的協(xié)商、密鑰生成、交換及管理。 IKE是ISAKMP(RFC2408)、Oakley(RFC2412)和SKEME(RFC2408)三個協(xié)議揉合而成的一個協(xié)議。 ISAKMP只規(guī)定了一個認證和密鑰交換的框架,Oakley 給出了密鑰交換

37、的步驟,而SKEME 則提供了一種通用的密鑰交換技術(shù)。 IKE 結(jié)合三者的功能組成了一個密鑰交換協(xié)議第71頁，共150頁。7) IPSec DOI (Domain of Interpretation ,解釋域) 協(xié)議文檔是RFC2407，定義了IPSec DOI文檔規(guī)范。 IKE 定義了安全參數(shù)如何協(xié)商,以及共享密鑰如何建立,但沒有定義協(xié)商內(nèi)容(參數(shù)) ,協(xié)商內(nèi)容與IKE 協(xié)議本身分開實現(xiàn)。協(xié)商的內(nèi)容(參數(shù)) 被歸于一個單獨的文檔內(nèi),名為IPSec DOI。8) 策略 策略是兩個實體間通信的規(guī)則,它決定采用什么協(xié)議、什么加密算法和認證算法來通信。 策略不當(dāng)可能造成不能正常工作。目前策略還沒有統(tǒng)

38、一標準第72頁，共150頁。6、安全關(guān)聯(lián)SA(Security Association ) (1) SA概述 IPSec 系統(tǒng)需要 具體完成二方面工作: 設(shè)置安全機制及參數(shù) 由IKE (因特網(wǎng)密鑰交換)、策略和解釋域(DO I) 三組件完成 對IP包進行加密、認證和傳輸 由ESP、AH 傳輸協(xié)議完成 (包括加密、認證算法) 完成 SA是兩個通信實體經(jīng)過協(xié)商建立起來的一種單向的邏輯“連接”，規(guī)定用來保護數(shù)據(jù)的IPSec協(xié)議類型、加密算法、認證方式、加密和認證密鑰、密鑰的生存時間以及抗重播攻擊的序列號等，為所承載的流量提供安全服務(wù) SA可以手工建立也可以自動建立(采用IKE協(xié)議) 第73頁，共15

39、0頁。 SA是單向的 如果兩臺主機A、B正在利用ESP通信，那么主機A需要一個用來處理外出數(shù)據(jù)包的SA(out)，還需要一個處理進入數(shù)據(jù)包的SA(in)。 主機A的SA(out)和主機B的SA(in)共享相同的加密參數(shù)，主機B的SA(out)和主機A的SA(in)共享相同的加密參數(shù)。 SA可以為AH或者ESP提供安全服務(wù)，但不能同時提供。如果一個流量同時使用了AH 和ESP，那就必須為該流量建立兩個(或更多個)SA。 為了保證兩臺主機或安全網(wǎng)關(guān)之間典型的雙向通信，至少需要建立兩個SA(每個方向一個)第74頁，共150頁。(2)安全關(guān)聯(lián)SA的表示：三元組 （安全參數(shù)索引，目的IP地址，安全協(xié)議標

40、識符） 1) 安全參數(shù)索引（SPI） SPI是一個32位長的數(shù)據(jù)，發(fā)送方在每個數(shù)據(jù)包上加載一個SPI，接受方使用這個值在安全關(guān)聯(lián)數(shù)據(jù)庫SAD中進行檢索查詢，提取所需要的SA，以便處理接收的分組 2) 目的IP地址 可以是終端主機的IP地址，也可以是前端設(shè)備（如防火墻或路由器）的IP地址 3) 安全協(xié)議標識符 標明該SA是用于AH還是ESP第75頁，共150頁。(3) SAD：安全關(guān)聯(lián)數(shù)據(jù)庫 SAD中的參數(shù) 1) AH信息 AH使用的鑒別算法、密鑰、密鑰生存期和相關(guān)參數(shù) 2) ESP信息 ESP使用的加密算法、鑒別算法、密鑰及其同步初始化向量、密鑰生存期和相關(guān)的參數(shù) 3) SA的生存期 一旦到期

41、，必須棄用參數(shù)安全參數(shù)索引(SPI)第76頁，共150頁。4) IPSec協(xié)議方式 定義該SA參數(shù)是被隧道模式或傳輸模式使用，若為通培符，則隧道、傳輸模式均可用5) 序列號 序列號是一個32 位的字段，用來產(chǎn)生AH或ESP頭中的序列號字段。SA 建立初始時，該字段的值設(shè)為0。每次用SA 來保護一個數(shù)據(jù)包，序列號的值便會遞增1。通常在這個字段溢出之前，SA會重新進行協(xié)商。目標主機利用這個字段來偵測“重播”攻擊6) 序列號溢出 該字段在序列號溢出時加以設(shè)置，用于外出包處理。如溢出，則產(chǎn)生一個審計事件，并禁止用SA 繼續(xù)發(fā)送數(shù)據(jù)包第77頁，共150頁。7) 抗重播窗口： 一個32 位的計數(shù)器,判斷進

42、入的AH或ESP包是否是重播的數(shù)據(jù)包。僅用于進入數(shù)據(jù)包，如接收方不選擇抗重播服務(wù)(如手工設(shè)置SA 時)，則抗重播窗口未被使用8) PMTU 參數(shù) 在隧道模式下使用IPSec 時，必須維持正確的PMTU 信息，以便對數(shù)據(jù)包進行相應(yīng)的分段。 第78頁，共150頁。(4)安全策略數(shù)據(jù)庫SPD(Security Policy Database) SPD定義了對所有進出業(yè)務(wù)應(yīng)該采取的安全策略，決定了為特定的數(shù)據(jù)包提供特定的安全服務(wù)。 IP數(shù)據(jù)包的收發(fā)都以安全策略為依據(jù)。對出入的IP包的處理有三種可能的選擇： 1) 丟棄 不允許該IP包在此主機上存在，不允許通過此安全網(wǎng)關(guān)或是根本就不能傳送給上層應(yīng)用程序的

43、業(yè)務(wù)流 2) 繞過IPSec 不需要進行IPSec安全保護處理，可直接通過 3) 采用IPSec 需要進行IPSec安全保護處理。對于這種業(yè)務(wù)流，SPD還必須指明所需提供的安全服務(wù)，采用的協(xié)議類型以及使用何種算法等第79頁，共150頁。 以下參數(shù)可用來確定SPD入口(又稱為選擇符)：目的IP地址：可以是單地址或多地址源地址：單地址或多地址UserID: 操作系統(tǒng)中的用戶標識。數(shù)據(jù)敏感級別：傳輸層協(xié)議：IPSec協(xié)議（AH, ESP, AH/ESP)源/目的端口服務(wù)類型(TOS)策略策略入口SPD的結(jié)構(gòu)若策略為采用IPSec，則有指向SAD數(shù)據(jù)庫某條SA的指針第80頁，共150頁。(5) 報文與

44、SA的關(guān)系 1) 對輸出報文 對于輸出數(shù)據(jù)報文，IPSec 協(xié)議要先查詢SPD，確定為數(shù)據(jù)報文應(yīng)使用的安全策略。如果檢索到的數(shù)據(jù)策略是應(yīng)用IPSec，再查詢SAD，確定是否存在有效地SA 若存在有效的SA，則取出相應(yīng)的參數(shù)，將數(shù)據(jù)包封裝(包括加密、驗證，添加IPSec頭和IP頭等),然后發(fā)送 若尚未建立SA，則啟動或觸發(fā)IKE 協(xié)商，協(xié)商成功后按前一步驟處理，不成功則應(yīng)將數(shù)據(jù)包丟棄，并記錄出錯信息 存在SA但無效，將此信息向IKE 通告，請求協(xié)商新的SA，協(xié)商成功后按1）中的步驟處理，不成功則應(yīng)將數(shù)據(jù)包丟棄，并記錄出錯信息第81頁，共150頁。2) 對輸入報文 IPSec協(xié)議先查詢SAD。如得

45、到有效的SA，則對數(shù)據(jù)包進行解封(還原) 再查詢SPD，驗證為該數(shù)據(jù)包提供的安全保護是否與策略配置的相符。 如相符，則將還原后的數(shù)據(jù)包交給TCP 層或轉(zhuǎn)發(fā)。 如不相符，或要求應(yīng)用IPSec 但未建立SA，或SA無效，則將數(shù)據(jù)包丟棄，并記錄出錯信息第82頁，共150頁。SA_IDsourcedestprotocolspiSA記錄01AH11MD5, K1,05-06AH13DES, K3,A()B()A的 SADBIDsourcedestprotocolportActionpolicy05TCP80IPSEC_PASS-06TCP25IPSEC-USEAHA的SPD第83頁，共150頁。7、傳輸

46、和隧道模式 (1) 傳輸模式下 IPSec僅對IP層以上的數(shù)據(jù)（TCP/UDP數(shù)據(jù)）進行加密和鑒別。傳輸模式通常用于兩個主機之間的端對端通信 (2)隧道模式下 將原IP包封裝在一個新的包中，原IP包將作為新包的有效凈荷，并且添加了新的適用于網(wǎng)關(guān)間的IP首部。 在傳輸過程中，由于原目的IP地址被封裝，中間的路由器只檢查新的IP首部，所以隧道方式可用來對抗通信量分析。隧道模式主要用于安全網(wǎng)關(guān)之間，可以在公共網(wǎng)上構(gòu)建虛擬專用網(wǎng)(VPN) 第84頁，共150頁。第85頁，共150頁。第86頁，共150頁。8、鑒別AH協(xié)議 AH首部格式 第87頁，共150頁。下一個首部（8bit） 標識該AH首部后下一

47、有效載荷的類型安全參數(shù)索引（32 bit） 標識用于此數(shù)據(jù)項的SA序列號（32 bit） 一個單調(diào)遞增的記數(shù)值，用于防止重放攻擊鑒別數(shù)據(jù)（可變長） 長度可變，但必須為32 bit的整數(shù)倍，包含了這個包的完整性檢查值第88頁，共150頁。AH的兩種模式 (1) 傳輸模式 鑒別覆蓋了整個分組（除可變字段） (2) 隧道模式 AH被插在原IP首部和新IP首部之間,目的IP地址被掩藏起來,提供了通信量上的安全性。第89頁，共150頁。Ext. headers(if present)Ext. headers(if present)AH-傳輸模式第90頁，共150頁。AH-隧道模式第91頁，共150頁。9

48、、ESP協(xié)議ESP首部格式 ESP HeaderESP TrailerESP Auth. DataPayload Data第92頁，共150頁。ESP-傳輸模式Ext. headers(if present)Ext. hrs第93頁，共150頁。ESP-隧道模式第94頁，共150頁。10、IKE （1）IPSec的5個階段 1) 過程啟動 2) IKE的第一階段 3) IKE的第二階段 4) 數(shù)據(jù)傳送 5) 隧道終止第95頁，共150頁。（2）IKE的第一階段 在IKE的第一階段中，在IPSec的兩個端點間協(xié)商IKE的SA，以保護IKE交換的安全 用Diffie-Hellman算法進行密鑰交換

49、 （3） IKE的第二階段 當(dāng)IKE SA建立后，進入IKE的第二階段，協(xié)商和建立IPSec的SA 第96頁，共150頁。7.4 傳輸層安全協(xié)議1、傳輸層安全協(xié)議 (1) SSL (2) TLS：基于SSL協(xié)議 RFC 2246: The TLS Protocol Version 1.0 RFC 2818: HTTP Over TLS2、SSL協(xié)議的起源 由于Web上有時要傳輸重要或敏感的數(shù)據(jù)，為了提供Web應(yīng)用的安全性，1994年Netscape公司提出了安全通信協(xié)議SSL(Secure Socket Layer)。 把HTTP和SSL相結(jié)合，就可以實現(xiàn)安全通信 。 SSL作為目前保護Web

50、安全和基于HTTP的電子商務(wù)交易安全的事實上的標準，被世界知名廠家廣泛支持第97頁，共150頁。3、SSL提供的安全服務(wù) 為客戶-服務(wù)器通訊提供安全性 （1）保密性 SSL客戶機和服務(wù)器之間通過密碼算法和密鑰的協(xié)商，建立起一個安全通道。 （2）完整性 SSL利用密碼算法和Hash函數(shù)，通過對傳輸信息特征值的提取來保證信息的完整性(消息摘要) （3）認證性 利用證書技術(shù)和可信的第三方CA，可以讓客戶機和服務(wù)器相互識別對方的身份第98頁，共150頁。4、SSL協(xié)議的體系結(jié)構(gòu)SSL是一個兩層協(xié)議 （1）記錄層協(xié)議 （2）握手層協(xié)議：3個TCPSSL記錄協(xié)議SSL握手協(xié)議SSL密鑰更改協(xié)議SSL告警協(xié)

51、議握手層協(xié)議第99頁，共150頁。(1) 記錄協(xié)議 提供分塊、壓縮、加密、完整性服務(wù)(2) 握手協(xié)議 SSL握手協(xié)議是用來在客戶端和服務(wù)器端傳輸應(yīng)用數(shù)據(jù)之前建立安全通信機制。 首次通信時，雙方通過握手協(xié)議協(xié)商密鑰加密算法、數(shù)據(jù)加密算法和報文摘要算法；然后互相驗證對方身份，最后使用協(xié)商好的密鑰交換算法產(chǎn)生一個只有雙方知道的秘密信息，客戶端和服務(wù)器各自根據(jù)這個秘密信息確定數(shù)據(jù)加密算法的參數(shù)(一般是密鑰)(3) 密鑰更改協(xié)議 用于會話間的密鑰修改(4) 告警協(xié)議 用于傳輸警告信息第100頁，共150頁。5、記錄協(xié)議 SSL記錄協(xié)議提供數(shù)據(jù)加密以及數(shù)據(jù)完整性服務(wù) MAC第101頁，共150頁。記錄報文

52、的結(jié)構(gòu)第102頁，共150頁。記錄頭可以是2個或3個字節(jié)的編碼記錄頭包含的信息： 記錄頭的長度 記錄數(shù)據(jù)的長度 記錄數(shù)據(jù)中是否有填充數(shù)據(jù)(使用塊加密時填充的數(shù)據(jù)) 第103頁，共150頁。6、SSL握手協(xié)議 (1) 作用 SSL 握手協(xié)議旨在創(chuàng)建和保持通信雙方進行安全通信所需的安全參數(shù)及狀態(tài)信息。 它使得服務(wù)器和客戶機能夠進行雙向的身份認證，并協(xié)商加密算法、MAC算法以及SSL記錄中所用的加密密鑰 (2)過程 分為四個階段第104頁，共150頁。 1) 第一階段：建立安全能力 協(xié)商壓縮算法、報文摘要算法、加密算法等； SSL版本、會話標識符 2) 第二階段：服務(wù)器鑒別和密鑰交換 服務(wù)器向客戶發(fā)

53、送其數(shù)字證書，利用該證書對服務(wù)器進行鑒別 3) 第三階段：客戶鑒別和密鑰交換(可選) 客戶向服務(wù)器發(fā)送其數(shù)字證書，利用該證書對客戶進行鑒別。 4) 第四階段：握手結(jié)束階段 前面各階段完成第105頁，共150頁?？蛻舳朔?wù)端第一階段第二階段Client_hello Server_hello Server_certificate Server_key_exchange Certificate_request Server_hello_done 客戶端服務(wù)端第三階段第四階段Client_certificate Client_key_exchange Certificate_Verify Change

54、_cipher_spec Finished Change_cipher_spec Finished 第106頁，共150頁。握手協(xié)議定義的消息類型(1)消息類型說明參數(shù)hello_request握手請求，服務(wù)器可在任何時候向客戶端發(fā)送該消息。若客戶端正在進行握手過程就可忽略該消息。否則客戶端發(fā)送cleint_hello消息，啟動握手過程無client_hello客戶啟動握手請求，該消息時當(dāng)客戶第一次連接服務(wù)器時向服務(wù)器發(fā)送的第一條消息。該消息中包括了客戶端支持的各種算法。若服務(wù)器端不能支持，則本次會話可能失敗。版本、隨機數(shù)、會話ID、密文族、壓縮方法server_hello 其結(jié)構(gòu)與clien

55、t_hello消息，該消息是服務(wù)器對客戶端client_hello消息的恢復(fù)。版本、隨機數(shù)、會話ID、密文族、壓縮方法server_certificate服務(wù)器提供的證書。如果客戶要求對服務(wù)器進行認證，則服務(wù)器在發(fā)送server_hello消息后，向客戶端發(fā)送該消息。證書的類型一般是X.509v3。X509v3證書鏈server_key_exchange 服務(wù)器密鑰交換。當(dāng)服務(wù)器不使用證書，或其證書中僅提供簽名而不提供密鑰時，需要使用本消息來交換密鑰。參數(shù)、簽名第107頁，共150頁。握手協(xié)議定義的消息類型(2)消息類型說明參數(shù)certificate_request用于服務(wù)器向客戶端要求一個客

56、戶證書。類型、授權(quán)server_hello_done 該消息表明服務(wù)器端的握手請求報文已經(jīng)發(fā)送完畢，正在等待客戶端的響應(yīng)。客戶端在收到該消息時，將檢查服務(wù)器提供的證書及其他參數(shù)是否是有效、可以接受的。無client_certificate客戶端對服務(wù)器certificate_request消息的響應(yīng)，只有在服務(wù)器端要求客戶證書的時候使用。一般該消息是客戶端收到server_hello_done消息后所發(fā)送的第一條消息。若客戶端沒有合適的證書，則向服務(wù)器端發(fā)送no_certificate的告警消息（無證書可能導(dǎo)致握手失?。509v3證書鏈client_key_exchange客戶密鑰交換。當(dāng)客

57、戶不使用證書，或其證書中僅提供簽名而不提供密鑰時，需要使用本消息來交換密鑰。參數(shù)、簽名certificate_verify該消息用于向服務(wù)器提供對客戶證書的驗證。簽名finished 該消息在“加密規(guī)約修改”（Change Cipher Spec）消息之后發(fā)送，以證實握手過程已經(jīng)成功完成。本消息發(fā)送后，發(fā)送方開始使用協(xié)商的新參數(shù)來執(zhí)行操作。該消息需要在兩個方向上傳送。散列值第108頁，共150頁。消息名方向內(nèi)容不需要新密鑰CLIENTHELLOCSchallenge, session_id, cipher_specsSERVERHELLOSCconnection-id, session_id_

58、hitCLIENTFINISHCSEclient_write_keyconnection-idSERVER-VERIFYSCEserver_write_keychallengeSERVERFINISHSCEserver_write_keysession_id其他流程第109頁，共150頁。需要新密鑰CLIENTHELLOCSchallenge, cipher_specsSERVERHELLOSCconnection-id,server_certificate,cipher_specsCLIENTMASTERKEYCSEserver_public_keymaster_keyCLIENTFINIS

59、HCSEclient_write_keyconnection-idSERVERVERIFYSCEserver_write_keychallengeSERVERFINISHSCEserver_write_keynew_session_id第110頁，共150頁。需要客戶認證CLIENTHELLOCSchallenge, session_id, cipher_specsSERVERHELLOSCconnection-id, session_id_hitCLIENTFINISHCSEclient_write_keyconnection-idSERVER-VERIFYSCEserver_write_k

60、eychallengeREQUESTCERTIFICATESCEserver_write_keyauth_type,challengeCLIENTCERTIFICATECSEclient_write_keycert_type,client_cert,response_dataSERVERFINISHSCEserver_write_keysession_id第111頁，共150頁。7.5 代理協(xié)議-SOCKs 1、代理協(xié)議 根據(jù)代理服務(wù)器的工作層次，可分為應(yīng)用層代理、傳輸層代理和SOCKS代理。 應(yīng)用層代理工作在TCP/ IP 模型的應(yīng)用層之上，對不同的代理提供不同的處理方法，只能用于支持應(yīng)用層