安全協(xié)議傳輸層安全和演示

（優(yōu)選）安全協(xié)議傳輸層安全和ppt講解現(xiàn)在是1頁\一共有45頁\編輯于星期三作業(yè)課本p.147思考題2、6、7、8現(xiàn)在是2頁\一共有45頁\編輯于星期三4.1引言SSL（安全套接層，SecureSocketLayer）和TSL（傳輸層安全，TransportLayerSecurity）為傳輸層提供安全性。在傳輸層部署安全性的優(yōu)點IP層安全是點對點的，傳輸層是端對端的（網(wǎng)絡(luò)通信中的點到點和端到端概念示意請看P.20圖1.11）傳輸層提高了可靠性，使得高層服務(wù)不必關(guān)注可靠性問題。應(yīng)用層協(xié)議直接構(gòu)建于傳輸層之上，在傳輸層上構(gòu)架安全協(xié)議，可以把高層應(yīng)用從安全性中解放出來?，F(xiàn)在是3頁\一共有45頁\編輯于星期三SSL/TCL發(fā)展歷史1994年Netscape開發(fā)了SSL(SecureSocketLayer)協(xié)議，專門用于保護Web通訊版本和歷史（各版本譜系圖見P.108圖4.1）1.0，不成熟2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity,也被稱為SSL3.1)，1997年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)現(xiàn)在是4頁\一共有45頁\編輯于星期三SSL/TCL設(shè)計目標協(xié)議的設(shè)計目標為兩個通訊個體之間提供機密性、完整性，服務(wù)器認證以及可選的客戶端認證（比較：IPSec的認證是雙向的）。互操作性、可擴展性、相對效率現(xiàn)在是5頁\一共有45頁\編輯于星期三4.2SSLv3協(xié)議流程SSL使用過程使用SSL保護的高層報文需要封裝在SSL報文中投遞所有SSL報文最終封裝在傳輸層報文中投遞協(xié)議分為兩層底層：記錄協(xié)議，是數(shù)據(jù)承載層，數(shù)據(jù)傳輸單位是記錄，高層協(xié)議封裝在SSL記錄中進行投遞。上層：握手協(xié)議、更改密鑰規(guī)范協(xié)議、警告協(xié)議現(xiàn)在是6頁\一共有45頁\編輯于星期三4.2SSLv3協(xié)議流程SSLv3協(xié)議關(guān)系圖，中文版見p.109圖4.2現(xiàn)在是7頁\一共有45頁\編輯于星期三4.2SSLv3協(xié)議流程握手協(xié)議功能必選的服務(wù)器認證可選的客戶端認證算法協(xié)商，包括壓縮算法、加密算法和消息驗證碼算法密鑰生成，即生成客戶端與服務(wù)器共享的會話密鑰。使用4個密鑰用于加密和認證，4個密鑰由共享密鑰生成。共享密鑰的生成方式：基于RSA的密鑰傳輸基于D-H的密鑰協(xié)商現(xiàn)在是8頁\一共有45頁\編輯于星期三4.2SSLv3協(xié)議流程警告協(xié)議功能報錯機制安全斷連機制，即可認證的方式關(guān)閉連接，防止截斷攻擊。記錄協(xié)議的功能是SSLv3的數(shù)據(jù)承載協(xié)議，規(guī)定了SSLv3的報文格式，以及對報文的處理過程。握手報文和應(yīng)用數(shù)據(jù)都要封裝成“記錄”的形式投遞?，F(xiàn)在是9頁\一共有45頁\編輯于星期三4.2.1基本協(xié)議流程典型的SSLv3通信過程（見p.110圖4.3）三次握手建立TCP連接SSL協(xié)議過程算法、密鑰協(xié)商由共享密鑰和隨機數(shù)計算4個密鑰用協(xié)商好的安全參數(shù)交互應(yīng)用數(shù)據(jù)以可認證的方式斷開連接斷開TCP連接現(xiàn)在是10頁\一共有45頁\編輯于星期三現(xiàn)在是11頁\一共有45頁\編輯于星期三現(xiàn)在是12頁\一共有45頁\編輯于星期三4.2.2更改密碼規(guī)范協(xié)議ChangeCipherSpec消息屬于更改密碼規(guī)范協(xié)議，功能互相通告將啟用新的密碼規(guī)范協(xié)調(diào)客戶端和服務(wù)器的狀態(tài)，使得雙方實現(xiàn)同步。連接：通信雙方的一次通信過程，由一組參數(shù)描述。會話：利用握手協(xié)議獲取的一系列安全參數(shù)，包括算法、預(yù)主密鑰等。一個會話可有多個連接共享，每個會話都有唯一的標識。(對應(yīng)于LT2P的隧道和會話)會話的狀態(tài)：當(dāng)前操作狀態(tài)：表示正在使用的密碼參數(shù)，分為讀狀態(tài)（接受）和寫狀態(tài)（發(fā)送）掛起狀態(tài)：表示將要使用的密碼參數(shù)，分為讀狀態(tài)和寫狀態(tài)每個狀態(tài)用一組密碼參數(shù)表示，SSL握手協(xié)議作用之一為協(xié)調(diào)通信雙方的狀態(tài)同步?，F(xiàn)在是13頁\一共有45頁\編輯于星期三4.2.3Finished消息Finished消息的功能包含了之前所有握手消息的MAC，這樣可防止通過修改握手消息實現(xiàn)的降級攻擊。降級攻擊：攻擊者修改發(fā)送的消息，降低使用算法的安全級別。如：攻擊者截獲發(fā)送的ClientHello消息，以較弱的算法代替后再發(fā)送出去，從而降低了協(xié)議的安全性。Finished消息可發(fā)現(xiàn)消息被修改?，F(xiàn)在是14頁\一共有45頁\編輯于星期三服務(wù)器端身份認證原理：服務(wù)器擁有證書公鑰對應(yīng)的私鑰才能正確解密預(yù)主密鑰才能計算正確的密鑰才能生成正確的Finish*消息?，F(xiàn)在是15頁\一共有45頁\編輯于星期三4.2.4警告協(xié)議警告協(xié)議的功能報告差錯，分為警告(warning)級和致命（fatal）級應(yīng)用數(shù)據(jù)傳輸完后，通知對方斷開連接，斷連消息為Close_notify，使用了消息驗證碼認證發(fā)送端的身份。現(xiàn)在是16頁\一共有45頁\編輯于星期三4.2.5其它應(yīng)用SSL支持多種使用方式例：會話恢復(fù)：使用已有的會話保護某個連接，不必再重新協(xié)商新的會話狀態(tài)參數(shù)。會話狀態(tài)參數(shù)：會話ID、通信對等端證書、壓縮算法、加密算法、哈希算法、預(yù)主密鑰、可恢復(fù)標記連接狀態(tài)參數(shù)：客戶端和服務(wù)器端的隨機數(shù)、服務(wù)器MAC密鑰和加密密鑰、客戶端MAC和加密密鑰、初始化向量IV以及序號現(xiàn)在是17頁\一共有45頁\編輯于星期三P114圖4.4SSL會話恢復(fù)流程現(xiàn)在是18頁\一共有45頁\編輯于星期三

客戶端認證客戶端認證：服務(wù)器認證客戶端，和一般流程不同的是增加了以下流程，在圖中用紅色框表示：服務(wù)器發(fā)送CertificateRequest消息，以通告客戶端需驗證其身份。客戶端響應(yīng)：客戶端發(fā)送Certificate消息，將自己的證書發(fā)送給服務(wù)器?？蛻舳税l(fā)送CertificateVerify消息，其中包含了客戶端利用與證書對應(yīng)的私鑰對之前的握手消息所作的簽名。客戶端認證和服務(wù)端認證的不同服務(wù)器驗證客戶端發(fā)送的CertificateVerify消息來驗證其身份。使用證書+簽名?？头藫碛姓_的私鑰才能生成合法的簽名?？蛻舳送ㄟ^驗證服務(wù)器發(fā)送的Finished消息驗證其身份。使用證書+公鑰加密+消息認證碼。服務(wù)器只有擁有正確的私鑰才能正確解密客戶端發(fā)送的預(yù)主密鑰，才可生成正確的會話密鑰，才能用正確的會話密鑰生成Finished消息?，F(xiàn)在是19頁\一共有45頁\編輯于星期三P116圖4.5使用客戶端認證的SSL現(xiàn)在是20頁\一共有45頁\編輯于星期三

其它應(yīng)用方式SSL的預(yù)主密鑰生成方式密鑰傳輸，RSA同時作為簽名和加密算法。如普通握手流程、客服端認證。客戶端選擇預(yù)主密鑰，使用服務(wù)器的公鑰加密后發(fā)送給服務(wù)器。密鑰協(xié)商方式生成共享密鑰。D-H（見p.117圖4.6）：雙方提供密鑰素材來生成共享密鑰。圖中紅方框部分是有別于典型流程的地方。FORTEZZA現(xiàn)在是21頁\一共有45頁\編輯于星期三p.117圖4.6用D-H交換生成預(yù)共享密鑰的SSL流程現(xiàn)在是22頁\一共有45頁\編輯于星期三4.3密鑰導(dǎo)出預(yù)主密鑰不直接用于保護數(shù)據(jù)，而是生成4個用于數(shù)據(jù)保護的會話密鑰：服務(wù)器寫加密密鑰(Esc)、服務(wù)器寫MAC密鑰(Msc)：分別用于服務(wù)器發(fā)出數(shù)據(jù)的加密和消息驗證碼計算?？蛻舳藢懠用苊荑€(Ecs)、客戶端寫MAC密鑰(Mcs)：分別用于客戶端發(fā)出數(shù)據(jù)的加密和消息驗證碼計算。現(xiàn)在是23頁\一共有45頁\編輯于星期三4.3密鑰導(dǎo)出密鑰導(dǎo)出圖示見P.118圖4.7，各參數(shù)的計算公式見，計算過程步驟如下：由預(yù)主密鑰、客戶端隨機數(shù)和服務(wù)器端隨機數(shù)共同生成主密鑰。由主密鑰、客戶端隨機數(shù)和服務(wù)器端隨機數(shù)共同生成密鑰分組。把密鑰分組分成6塊，按照所需的密鑰長度依次截取得到Mcs、Msc、Ecs、Esc、IVcs（客戶端初始向量）、和IVsc（服務(wù)器初始向量）?，F(xiàn)在是24頁\一共有45頁\編輯于星期三4.4SSLv3記錄記錄層是SSL的數(shù)據(jù)承載層，記錄是它的數(shù)據(jù)傳輸單位。握手、警告、更改密碼規(guī)范和高層協(xié)議數(shù)據(jù)都要封裝到SSL記錄中投遞。SSL標準以規(guī)范語言描述記錄格式及處理過程。雜項：/*…*/表示注釋數(shù)字：unit8,unit16,unit24,unit32,unit64向量：元素序列，定長向量：TT’[n]，變長向量：TT’<floor..ceiling>枚舉：enum{e1(v1),e2(v2),..,en(vn)[[,(n)]]}Te;結(jié)構(gòu)：struct{T1f1;T2f2;…;Tnfn;}[[T]]；變體：根據(jù)實際選擇符不同可以選擇不同的數(shù)據(jù)常量：賦值即給一個變量賦予常量值?，F(xiàn)在是25頁\一共有45頁\編輯于星期三4.4SSLv3記錄變體格式：struct{T1f1;T2f2;…Tnfn;Select(E){casee1:Te1;casee2:Te2;…caseen:Ten;}[[fv]]}[[Tv]];現(xiàn)在是26頁\一共有45頁\編輯于星期三4.2SSLv3記錄記錄層對數(shù)據(jù)處理過程：分片：將高層協(xié)議數(shù)據(jù)分段，在每個分片添加一個記錄頭。壓縮：提供數(shù)據(jù)傳輸效率，把SSLPlaintext轉(zhuǎn)化為SSLCompressed結(jié)構(gòu)。計算MAC加密接收方對數(shù)據(jù)處理的過程（發(fā)送方的逆過程）：解密驗證MAC解壓分片重組現(xiàn)在是27頁\一共有45頁\編輯于星期三4.2SSLv3記錄

SSL發(fā)送方數(shù)據(jù)處理過程，中文圖見p.122圖4.8現(xiàn)在是28頁\一共有45頁\編輯于星期三4.2SSLv3記錄記錄頭結(jié)構(gòu)定義：分片：SSLPlaintext(定義見節(jié))壓縮：SSLCompressed(定義見節(jié))加密：SSLCiphertext(定義見節(jié))SSL記錄格式見右圖，也可見p.124圖4.9現(xiàn)在是29頁\一共有45頁\編輯于星期三4.2SSLv3記錄SSL的各個消息格式見4.4.3節(jié)（略）現(xiàn)在是30頁\一共有45頁\編輯于星期三4.5TLS與SSLv3比較版本號不同：SSLv3版本號為3.0，TLSv1為3.1。MAC計算方法不同密鑰導(dǎo)出方法不同算法支持不同：SSL支持Fortezza，但TLS不支持SSLv3為臨時D-H和Fortezza機制提供了附加的證書類型，但TLS沒有提供。TLS針對Kerbero協(xié)議、AES等定義了專門的加密套件，SSLv3沒有。警告類型不同：SSLv3定義了2種警告類型，TLS則定義了12種。散列函數(shù)的輸入不同。填充長度的規(guī)定不同。現(xiàn)在是31頁\一共有45頁\編輯于星期三4.6SSLv2簡介SSLv2與SSLv3的差異版本值定義不同協(xié)議組成不同：SSLv2僅包括握手和記錄兩個協(xié)議，無更改密碼規(guī)范和警告協(xié)議。SSLv2沒有定義關(guān)閉連接的警告，因此無法防止截斷攻擊SSLv2的錯誤以錯誤碼形式給出，沒有定義專門的協(xié)議或消息。密碼套件不同。使用密鑰不同：SSLv3使用4個密鑰保護數(shù)據(jù)，SSLv2只使用2個密鑰(不區(qū)分MAC和加密密鑰)。現(xiàn)在是32頁\一共有45頁\編輯于星期三4.6.2SSLv2握手流程SSLv2給出了三種典型的握手流程1、沒有會話ID的情況現(xiàn)在是33頁\一共有45頁\編輯于星期三現(xiàn)在是34頁\一共有45頁\編輯于星期三4.6.2SSLv2握手流程2、客戶端和服務(wù)器都發(fā)現(xiàn)會話ID的情況：類似于SSLv3的會話恢復(fù)，使用已有會話的預(yù)主密鑰生成新的會話密鑰?，F(xiàn)在是35頁\一共有45頁\編輯于星期三現(xiàn)在是36頁\一共有45頁\編輯于星期三4.6.2SSLv2握手流程3、使用會話ID和客戶端認證使用會話恢復(fù)客戶端認證：增加request_certificate和client_certificate兩條消息來認證客戶端身份?，F(xiàn)在是37頁\一共有45頁\編輯于星期三現(xiàn)在是38頁\一共有45頁\編輯于星期三4.6SSLv2簡介記錄格式：見p.140圖4.13所示握手消息SSLv2的安全缺陷未定義證書鏈，因此客戶端和服務(wù)器交換的證書必須由根CA頒發(fā)，使用不便。加密和計算MAC使用同一密鑰，安全性較低。沒有驗證握手消息完整性的措施，攻擊者可能篡改握手消息，降低安全度。沒有安全斷連的機制，無法防止截斷攻擊?？赡軙媾R一種“認證傳輸攻擊”。現(xiàn)在是39頁\一共有45頁\編輯于星期三4.7SSL應(yīng)用SSL的常見應(yīng)用是構(gòu)建VPN，和IPSec相比具有以下優(yōu)點：操作透明，而IPSec的部署需要安裝復(fù)雜的軟硬件。用戶可選，而IPSec除了管理員，其它人幾乎沒有選擇權(quán)利。有大量二次開發(fā)軟件，而IPSec沒有公開的二次開發(fā)軟