https安全传输揭秘
HTTPS是什么
我們知道HTTP是明文傳輸的，惡意的中間人和竊聽者通過截取用戶發送的網絡數據包可以拿到用戶的敏感信息。尤其是涉及網上交易，銀行轉賬等操作更是危害極大。
HTTPS的核心是SSL/TLS安全協議層，該層位于應用層和傳輸層之間，TLS對應用層數據加密后再向下交給傳輸層，以解決HTTP安全傳輸的問題。
下面我們就一起來梳理一下TLS在背后做了哪些事情，為我們的互聯網行業保駕護航。
身份驗證
發送方與接收方在決定數據傳輸之前，第一步要做的必然是互相確認對方的身份。TLS使用數字證書幫助確認證書持有者的身份。
證書
證書是一數字形式的身份證明，通常由CA進行頒發。證書中包含了證書持有者的信息，有效期，公鑰，序列號，以及證書頒發者的數字簽名。
CA
CA（Certificate Authority），數字證書認證機構是負責發放和管理數字證書的權威機構，并作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。
CA的作用可以用公安局來做個類比，負責給公民頒發居民身份證，身份證上的信息都是公安局簽字確認過的，具有權威性。
數字簽名
數字簽名是非對稱加密技術的另一項應用。它的原理非常簡單：公私鑰是成對使用的，使用私鑰加密的密文，只能使用公鑰來解密。因為私鑰只有特定服務器才知道，所以如果公鑰可以解密用私鑰加密的密文，必然證明是該服務器發送的。私鑰用來數字簽名，表明報文是特定服務器發送的；公鑰用來驗證數字簽名。
數字簽名是使用私鑰加密的校驗和。將數字簽名附加到報文上，一并發給接收方。
數字簽名的作用：
- 證明是作者編寫了這條報文；
- 可以防止報文被篡改。
描述一下整個身份驗證的過程：
加密
TLS需要解決的問題是安全地交換對稱密鑰，使用對稱密鑰進行數據的加解密。
加密有兩種主要的技術：對稱密鑰加密和公開密鑰加密。 這兩種加密技術，TLS都在使用。
對稱密鑰
在對稱密鑰加密中，密鑰既用于加密也用于解密。消息交換的雙方需要同時知道該密鑰。對稱密鑰加密常用于大數據量的加解密，相比非對稱密鑰加密，它的加密速度要快得多。常見的對稱密鑰加密算法有DES，3-DES，RC2，RC4，和AES。
公開密鑰加密
公開密鑰加密是一組密鑰對，由復雜的數學運算得出。其中一個密鑰對外公開稱之為公鑰，通常密鑰持有者讓CA把自己的公鑰寫到證書中對外發布。另一把密鑰由持有者秘密保存。兩把密鑰一起協作，一把用來加密，另一把用來解密：如果公鑰用來加密，那么只有對應的私鑰能解密；如果私鑰用來加密，同樣只有對應的公鑰才能解密。這種特殊的關系使得公開密鑰加密有兩種重要的應用。首先，任何一個取得了服務器公鑰的人，都可以用該公鑰加密數據，同時只有該服務器私鑰的擁有者才可以進行解密。其次，如果服務器使用私鑰加密數據，那么任何取得該服務器公鑰的人都可以對服務器發送的數據進行解密。這也是數字簽名的實現基礎。最常見的算法是RSA。
| 對稱密鑰 | 加解密速度快，性能好 | 密鑰交換有泄露風險 |
| 公開密鑰 | 不存在密鑰交換竊取的風險；可以用作簽名驗證身份 | 計算復雜，性能差 |
TLS使用公鑰加密對服務器進行身份驗證后，在客戶端和服務器之間商定對稱密鑰。隨后使用商定的對稱密鑰加密會話過程中的大量數據。這種方案既利用公鑰加密解決了身份驗證和密鑰交換的問題，又結合了對稱密鑰加密大量數據速度快的優點。
安全會話建立的完整過程
以上我們已經對TLS的功能和實現方式有了一個初步的了解。接下來，我們將對安全會話建立的細節做一個詳細的介紹。
整個安全會話的建立，TLS是以握手的過程來協商的，具體過程下圖所示：
可以看到握手協議通過一系列的有序的消息協商數據會話所需的安全參數。
客戶端先發送消息啟動握手
Client Hello
客戶端向服務器發送Client Hello以發起會話，Client Hello包含以下信息：
- 版本號?？蛻舳丝梢灾С值淖罡甙姹镜膮f議。
- 隨機數。長度為32字節的隨機數。由4字節的客戶端時間加28字節的隨機數組成。
- sessionID。sessionID用來恢復之前的會話?；謴椭暗臅捄苡斜匾?#xff0c;因為創建新的安全會話，需處理器進行密集的計算得到會話密鑰。通過sessionID恢復已有的會話可以避免此問題。
- 加密套裝。客戶端可以支持的加密套裝列表。例如TLS_RSA_WITH_DES_CBC_SHA，TLS是協議的版本，RSA是密鑰交換的非對稱加密算法，DES_CBC是對稱加密算法，SHA是散列方法。
- 壓縮算法?？蛻舳酥С值膲嚎s算法。
如下是一個 Client Hello消息的示例：
ClientVersion 3,1 ClientRandom[32] SessionID: None (new session) Suggested Cipher Suites:TLS_RSA_WITH_3DES_EDE_CBC_SHATLS_RSA_WITH_DES_CBC_SHA Suggested Compression Algorithm: NONE服務器響應
服務器收到客戶端的hello消息后，同樣以hello消息應答：
Server Hello
服務器向客戶端發送Server Hello，該消息包括以下內容：
- 版本號。
- 隨機數。服務器端隨機數，由服務器時間+隨機數組成。與客戶端隨機數一起生成master key。master key用來生成會話密鑰。
-
sessionID。用來恢復會話。有三種情況：
- 新sessionID?？蛻舳藳]有指明sessionID，服務器返回一個新的sessionID。如果客戶端指明了sessionID，但是服務器無法恢復對應的會話，也會重新生成一個sessionID。
- 恢復的sessionID?？蛻舳酥该饕謴偷膕essionID，同時服務器可以恢復該會話。
- 無。是新的會話，但服務器不希望將來恢復該會話，所以不返回sessionID。
- 加密套裝。服務器選擇一個服務器和客戶端都支持的最強的加密套裝。如果沒有彼此都支持的加密套裝，那么會結束會話，發送一個握手失敗的警告。
- 壓縮算法。指定選用的壓縮算法。
下面是一個Server Hello消息的例子：
Version 3,1 ServerRandom[32] SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77 Use Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA Compression Algorithm: NONEServer Certificate
服務器向客戶端發送證書。服務器證書包含了服務器的公鑰。客戶端使用服務器公鑰驗證服務器的身份，對premaster secret加密。
客戶端還會檢查證書上聲明的服務器名字。該名字必須與客戶端正在訪問的服務器名稱匹配。例如，用戶在瀏覽器中輸如daojia.com，那么該證書中的服務器名必須是daojia.com或*.daojia.com。如果兩者不匹配，瀏覽器會給用戶警告。
Server Key Exchange
可選項，服務器創建并向客戶端發送一個暫時的密鑰。該密鑰可用于加密Client Key Exchange消息。該步驟只有在公鑰算法沒提供必要的密鑰生成元素時才需要，例如當服務器證書中沒有公鑰時。
Client Certificate Request
可選項，當服務器需要客戶端提要身份證明時需要。該步驟適用于那些在提供敏感信息之前需要客戶端驗證自己身份的網站（例如銀行站點）。
Server Hello Done
該信息表示服務器響應完成了，正在等待客戶端響應。
客戶端響應
服務器回復結束，客戶端開始應答，應答消息如下：
Client Certificate
如果服務器向客戶端請求證書，客戶端需要發送自己的證書給服務器，以驗證自己的身份?？蛻舳俗C書中有客戶端的公鑰。
Client Key Exchange
客戶端根據hello消息中發送的隨機數計算出premaster secret，使用服務器公鑰對其加密后發送給服務器。
premaster secret非常重要，因為客戶端和服務器需要用它和前邊的隨機數，在本地獨立計算master secret，然后基于master secret生成會話密鑰，會話密鑰就是安全傳輸時數據加密的對稱密鑰。
Certificate Verify
客戶端使用私鑰對目前為止所有的消息進行hash計算后進行簽名。接收者使用簽名者的公鑰驗證簽名，確保它是客戶端私鑰簽的名。只有當服務器請求客戶端證書時才需要發送該消息。
Change Cipher Spec
該消息通知服務器此后的所有信息都將使用商定的密鑰和算法進行加密。
Client Finished
該消息是先前的握手消息的加密校驗和。使用hash函數計算所有握手消息的hash值，然后使用會話密鑰進行加密后作為該消息的內容。
服務器響應
Change Cipher Spec Message
該消息通知客戶端服務器將使用剛剛協商的密鑰加密數據。
Server Finished
與Client Finished類似，該消息是整個握手消息的hash值，hash值使用會話密鑰加密處理。如果客戶端能成功解密和驗證包含的hash值，那么可以證明握手是成功的，客戶端計算出的密鑰和服務器計算出來密鑰匹配。
服務器響應完成后，整個握手環節結束。一切正常的話，安全會話建立成功，https安全連接建立成功，客戶端和服務器接下來可以安全地傳輸應用層數據了。
完整的握手過程描述：
如何避免多次繁復的握手過程
如果每次https連接都要進行這么長的協商過程效率太低，因此tls支持基于sessionID保存會話，以便下次訪問時快速恢復會話。
在完整的安全會話協商過程中，服務器向客戶端發送了一個sessionID。隨后，客戶端在ClientHello消息中攜帶sessionID，這意味著客戶端還記得之前與服務器商定的加密套裝和密鑰。如果服務器也記得的話，會在ServerHello消息中攜帶sessionID。
簡化的過程如下：
Client ServerClientHello -------->ServerHello[ChangeCipherSpec]<-------- Finished[ChangeCipherSpec]Finished -------->Application Data <-------> Application Data握手過程描述：
通常瀏覽器打開HTTPS連接時需要完整的握手過程，隨后對同一個服務器的請求進行快速握手。服務器通常15s后會關閉非活動狀態的連接，但是會話信息一般保存的時間很久（數小時甚至幾天）。
總結
https協議解決安全傳輸的核心是TLS協議。TLS在解決安全傳輸時主要處理的問題就是身份識別和密鑰交換。這兩個問題的解決依賴于公開密鑰加密技術。以公開密鑰加密技術為基礎的數字證書系統是互聯網安全傳輸的基石，是信任鏈的根基。
啰啰嗦嗦寫了很多，目的還是希望能把細節交待的更清楚，能把一些生澀的術語講的相對易懂一些，如果大家還是有些地方看的不清楚，可以在留言互動。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的https安全传输揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Jmeter模拟不同带宽进行测试
- 下一篇： Linux sar性能分析