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。
