SSL/TLS協(xié)議運(yùn)行機(jī)制的概述
圖解SSL/TLS協(xié)議
HTTPS背后的加密算法
TLS協(xié)議分析 與 現(xiàn)代加密通信協(xié)議設(shè)計(jì)
概述
互聯(lián)網(wǎng)是一個(gè)開放的環(huán)境,通信雙方都是未知的身份。為了防止在通信時(shí),有第三方可以獲取通信的內(nèi)容,修改通信的內(nèi)容,或冒充他人進(jìn)行通信。此時(shí)就需要有一個(gè)安全協(xié)議,可以使得通信內(nèi)容被加密傳輸,并且還具有內(nèi)容校驗(yàn)和身份驗(yàn)證機(jī)制。
SSL (Secure Sockets Layer 安全套接層)及其繼任者 TLS (Transport Layer Security,傳輸層安全)就是這樣一種安全協(xié)議,為網(wǎng)絡(luò)通信提供基于進(jìn)程對進(jìn)程的鑒別,保密和數(shù)據(jù)完整性的服務(wù)。SSL 位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間,應(yīng)用層數(shù)據(jù)不再直接傳遞給傳輸層,而是傳遞給 SSL 層,SSL 層對從應(yīng)用層收到的數(shù)據(jù)進(jìn)行加密,并增加自己的 SSL 頭。SSL 協(xié)議分為兩層,由多個(gè)子協(xié)議組成,分別是:
- 記錄協(xié)議:建立在可靠的傳輸協(xié)議(如TCP)之上。
- 握手協(xié)議、警報(bào)協(xié)議、修改密碼規(guī)范協(xié)議:建立在記錄協(xié)議之上。
基本原理
由于用非對稱加密算法加密內(nèi)容的消耗太大,所以 SSL/TLS 協(xié)議的基本原理是通信雙方通過非對稱加密交換一個(gè)對稱加密密鑰,在交換成功后,所有通信的內(nèi)容通過對稱加密以減少開銷。例如,客戶端首先向服務(wù)端請求其公鑰,在拿到服務(wù)端返回的公鑰后,客戶端用這個(gè)公鑰來加密對稱密鑰并發(fā)送給服務(wù)端,因?yàn)橹挥蟹?wù)端有私鑰可以正確解密加密后的對稱密鑰,所以通過非對稱加密來保證了通信雙方對稱加密密鑰的安全交換。而另一個(gè)要解決的問題是保證客戶端收到的服務(wù)端的公鑰是可信的,解決方法是采用數(shù)字證書。在使用對稱密鑰加密內(nèi)容通信前的部分稱為握手階段,發(fā)生在握手協(xié)議層,而之后的加密通信就是記錄協(xié)議層的工作了。
握手協(xié)議
握手協(xié)議建立在記錄協(xié)議之上,用于在實(shí)際的數(shù)據(jù)傳輸開始前,通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密和MAC算法、交換加密密鑰等。
握手階段涉及四次通信:
- ClientHello,首先,客戶端(通常是瀏覽器)先向服務(wù)器發(fā)出加密通信的請求,在這一步,客戶端主要向服務(wù)器提供以下信息。
- 支持的協(xié)議版本,比如TLS 1.0版。
- 一個(gè)客戶端生成的隨機(jī)數(shù),稍后用于生成"對話密鑰"。
- 支持的加密方法,比如RSA公鑰加密。
- 支持的壓縮方法。
- SeverHello,服務(wù)器收到客戶端請求后,向客戶端發(fā)出回應(yīng),服務(wù)器的回應(yīng)包含以下內(nèi)容。
- 確認(rèn)使用的加密通信協(xié)議版本,比如TLS 1.0版本。如果瀏覽器與服務(wù)器沒有一致的支持版本,服務(wù)器將關(guān)閉加密通信,而此時(shí)客戶端比如瀏覽器也會(huì)給出錯(cuò)誤提示信息。
- 一個(gè)服務(wù)器生成的隨機(jī)數(shù),稍后用于生成"對話密鑰"。
- 確認(rèn)使用的加密方法,比如RSA公鑰加密。
- 服務(wù)器證書。
- 如果服務(wù)器需要確認(rèn)客戶端的身份,還需要要求客戶端提供"客戶端證書"。
- 客戶端回應(yīng),客戶端收到服務(wù)器回應(yīng)以后,首先驗(yàn)證服務(wù)器證書。如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期,就會(huì)向訪問者顯示一個(gè)警告,由其選擇是否還要繼續(xù)通信。如果證書沒有問題,客戶端就會(huì)從證書中取出服務(wù)器的公鑰。然后,向服務(wù)器發(fā)送下面三項(xiàng)信息。
- 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密,防止被竊聽。有了這個(gè)隨機(jī)數(shù)以后,客戶端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù),接著雙方就用事先商定的加密方法,各自生成本次會(huì)話所用的同一把對稱"會(huì)話密鑰"。
- 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
- 客戶端握手結(jié)束通知,表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來供服務(wù)器校驗(yàn)。
- 如果服務(wù)器要求客戶端證書,客戶端會(huì)在這一步發(fā)送證書及相關(guān)信息。
- 服務(wù)器回應(yīng),服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后,計(jì)算生成本次會(huì)話所用的"會(huì)話密鑰"。然后,向客戶端最后發(fā)送下面信息。
- 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
- 服務(wù)器握手結(jié)束通知,表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來供客戶端校驗(yàn)。
交換對稱密鑰時(shí)并不是只能使用RSA算法,也可以使用例如 Diffie-Hellman算法(簡稱DH算法)等。
記錄協(xié)議
記錄協(xié)議建立在可靠的傳輸協(xié)議之上,為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密,數(shù)據(jù)完整性等基本功能的支持。加密通過握手協(xié)議定義的對稱密鑰實(shí)現(xiàn),完整性通過握手協(xié)議定義的帶密鑰的 MAC 算法保證。
操作過程:
- 分段,每個(gè)上層應(yīng)用數(shù)據(jù)被分成2^14字節(jié)或更小的數(shù)據(jù)塊。記錄中包含類型、版本號、長度和數(shù)據(jù)字段。
- 壓縮是可選的,并且是無損壓縮,壓縮后內(nèi)容長度的增加不能超過1024字節(jié)。
- 在壓縮數(shù)據(jù)上計(jì)算消息認(rèn)證MAC。
- 對壓縮數(shù)據(jù)及MAC進(jìn)行加密。
- 增加SSL記錄。
警報(bào)協(xié)議
客戶端和服務(wù)器發(fā)現(xiàn)錯(cuò)誤時(shí),向?qū)Ψ桨l(fā)送一個(gè)警報(bào)消息。如果是致命錯(cuò)誤,則立即關(guān)閉 SSL 連接,雙方還會(huì)先刪除相關(guān)的會(huì)話號,密鑰。每個(gè)警報(bào)消息共2個(gè)字節(jié),第1個(gè)字節(jié)表示錯(cuò)誤類型,如果是警報(bào),則值為1,如果是致命錯(cuò)誤,則值為2,第2個(gè)字節(jié)制定實(shí)際錯(cuò)誤類型。
致命的警報(bào)消息有:意外的消息、錯(cuò)誤的 MAC、解壓縮失敗、記錄溢出、握手失敗、非法參數(shù)、未知的 CA、訪問拒絕、解碼錯(cuò)誤、解密錯(cuò)誤、協(xié)議版本等。
警告類型的消息有:無證書、不支持的證書、吊銷的證書、證書過期、未知證書等。
修改密碼規(guī)范協(xié)議
為了保障SSL傳輸過程的安全性,客戶端和服務(wù)器雙方應(yīng)該每隔一段時(shí)間改變加密規(guī)范。SSL 修改密碼規(guī)范協(xié)議是3個(gè)高層的特定協(xié)議之一,也是其中最簡單的一個(gè)。在客服端和服務(wù)器完成握手協(xié)議之后,它需要向?qū)Ψ桨l(fā)送相關(guān)消息(該消息只包含一個(gè)值為1的單字節(jié)),通知對方隨后的數(shù)據(jù)將用剛剛協(xié)商的密碼規(guī)范算法和關(guān)聯(lián)的密鑰處理,并負(fù)責(zé)協(xié)調(diào)本方模塊按照協(xié)商的算法和密鑰工作。
會(huì)話恢復(fù)
握手階段用來建立SSL連接。如果出于某種原因,對話中斷,就需要重新握手。這時(shí)有兩種方法可以恢復(fù)原來的session:一種叫做session ID,另一種叫做session ticket。session ID的思想很簡單,就是每一次對話都有一個(gè)編號(session ID)。如果對話中斷,下次重連的時(shí)候,只要客戶端給出這個(gè)編號,且服務(wù)器有這個(gè)編號的記錄,雙方就可以重新使用已有的"對話密鑰",而不必重新生成一把。session ID是目前所有瀏覽器都支持的方法,但是它的缺點(diǎn)在于session ID往往只保留在一臺服務(wù)器上。所以,如果客戶端的請求發(fā)到另一臺服務(wù)器,就無法恢復(fù)對話。session ticket就是為了解決這個(gè)問題而誕生的。客戶端不再發(fā)送session ID,而是發(fā)送一個(gè)服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個(gè)session ticket是加密的,只有服務(wù)器才能解密,其中包括本次會(huì)話的主要信息,比如會(huì)話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后,解密后就不必重新生成對話密鑰了。
HTTPS
HTTPS 是 SSL/TLS 協(xié)議的一個(gè)最典型的應(yīng)用,在應(yīng)用層的 HTTP 協(xié)議和傳輸層之間加入了安全協(xié)議,使得原本明文傳輸?shù)?HTTP 協(xié)議具有了保密,校驗(yàn),認(rèn)證的安全功能。在握手成功建立連接后,雙方的通信基本上就是 HTTP 通信了,只是通過 SSL/TLS 的記錄協(xié)議層,將內(nèi)容用協(xié)商好的對稱密鑰進(jìn)行了加密。HTTPS 協(xié)議的使用是以 https:// 作為協(xié)議前綴,默認(rèn)端口是443。