tls壓縮

㈠ 什麼是TLS協議

安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面。
TLS 協議包括兩個協議組―― TLS 記錄協議和 TLS 握手協議――每組具有很多不同格式的信息。
TLS 記錄協議是一種分層協議。每一層中的信息可能包含長度、描述和內容等欄位。記錄協議支持信息傳輸、將數據分段到可處理塊、壓縮數據、應用 MAC 、加密以及傳輸結果等。對接收到的數據進行解密、校驗、解壓縮、重組等，然後將它們傳送到高層客戶機。
TLS 連接狀態指的是TLS 記錄協議的操作環境。它規定了壓縮演算法、加密演算法和 MAC 演算法。
TLS 記錄層從高層接收任意大小無空塊的連續數據。密鑰計算：記錄協議通過演算法從握手協議提供的安全參數中產生密鑰、 IV 和 MAC 密鑰。TLS 握手協議由三個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。

㈡ 更好的 TLS 1.3 協議解析

網路安全篇，面對復雜多變的網路環境，我們需要掌握哪些關於網路安全的相關知識，聊一聊與網路安全相關的：HTTPS、SSL、TLS 等。

《 網路安全 — HTTPS 》
《 網路安全的基石（上）— 加密 》
《 網路安全的基石（下）— 完整性與身份認證 》
《 公鑰信任問題 — 數字證書與 CA 》
《 信任始於握手 — TLS 連接過程詳解 》

《TLS 1.3 特性解析》
《 如何優化 HTTPS 連接 》- 待完善

早在 2013 年，IETF（互聯網工程小組） 就對 TLS 1.2 的過時設計和兩次往返開銷心生不滿，因此開始著手准備新版本的 TLS。同年 8 月由 Eirc Rescorla 提議出新版本 TLS 的 功能願望清單 。在經過一番 辯論 後，最終該提議內容被定義為 TLS 1.3。推動 TLS 1.3 設計的主要問題大概有：

終於在 2018 年 8 月 10 日，歷經 4 年時間，TLS 1.3 最終版本發布了 — RFC-8446 。新的協議使得互聯網變得更快、更安全；隨著 TLS 1.3 的採用率不斷提高，它勢必會長遠影響互聯網的發展；同時盡快將 TLS 1.3 平滑應用到線上環境無疑是勢在必行。

不過在這之前， TLS 1.2 的應用也已經有 10 年（2008 年）的時間了，畢竟歷經了種種考驗，新的協議在推廣和部署上必定會帶來新的挑戰。接下來我們就來看看新版本的 TLS 是如何做的？

由於 TLS 1.1/1.2 等協議已經出現了很多年，很多應用軟體、中間代理（Middlebox）只認老的記錄協議格式，更新改造很困難，甚至僵化。

可部署性

正式由於這些中間代理/軟體（Middlebox）在新的更改中表現不佳，即使是對 TLS 1.3 協議的細微更改（例如消除冗餘的 ChangeCipherSpec 消息，版本號從 0x03 升級為 0x04），也最終導致了某些設備的連接失敗問題。這也是 TLS 1.3 從草稿到最終發布花費了這么長時間的重要原因之一。

為了保證這些被廣泛部署的「舊設備」能夠繼續使用，TLS 1.3 不得不做出妥協，通過「偽裝」來實現兼容：保持現有的記錄格式不變，使得 TLS 1.3 看上去「像是」 TLS 1.2。

擴展協議

那麼，如何區分是 1.2 還是 1.3 呢？

這里用到一個新的 擴展協議 （Extension Protocol），它有點「補充條款」的意思，通過在記錄末尾添加一系列的「擴展欄位」來增加新的功能，舊版本的 TLS 不認識它可以直接忽略，這就實現了「向後兼容」。

TLS 1.3 正是利用擴展實現了許多重要的功能，比如 「supported_groups」 「key_share」 「signature_algorithms」 「server_name」 等。

在經歷十餘年的實踐中獲得許多寶貴經驗的 TLS 1.2 陸續發現了很多的漏洞和加密演算法的弱點。因此消除潛在的危險設計來糾正以前的錯誤成為 TLS 1.3 的設計目標之一。所以新版本的 TLS 協議里要修補這些不安全的因素。

例如：

固定密鑰交換

經過這樣一番「減肥瘦身」之後，TLS 1.3 的密鑰交換演算法只有 ECDHE 和 DHE 了，關於橢圓曲線（ECC）也被「砍」到只剩 P-256 和 x25519 等 5 種。

首先來說下廢除 RSA 和 DH 密鑰交換演算法的原因：

由於客戶端默認會選擇 ECDHE 而非 RSA 做密鑰交換，這是因為它不具有「 前向安全 」（Forward Secrecy）：「假設有人長期記錄了加密的數據，然後在後續的某個時間段獲得了伺服器的 RSA 私鑰，那麼黑客就能夠使用該私鑰解密出之前所有報文的 「Pre-Master」，再計算出會話密鑰，破解所有密文。這便是 今日截獲，明日破解 」

而 ECDHE 演算法在每次握手時都會生成一對臨時公鑰和私鑰，每次通信的秘鑰對都是不同的，也就是「一次一密」，即使黑客花大力氣破解了這一次的會話密鑰，也只是這次通信被攻擊，之前的歷史消息不會受到影響，仍然是安全的。

所以現在主流的伺服器和客戶端在握手階段都已經不再使用 RSA，改用 ECDHE，而 TLS 1.3 在協議里明確廢除了 RSA 和 DH 則在標准層面保證了「前向安全」。

固定密碼

多年以來，密鑰交換機制不是唯一引起安全漏洞的部分，對稱密鑰部分也有相當一部分問題。

同樣，用於對稱加密的演算法在經過「減肥瘦身」之後也只保留了 AES、ChaCha20 ，分組模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要演算法也只能用 SHA 256、SHA 384。

這樣原來眾多的加密演算法、參數組合導緻密碼套件非常復雜，難以選擇。而經過瘦身之後的 TLS 1.3 只剩下 5 個套件，使得客戶端或服務端在選擇密碼套件時變得「更加容易」。然而更重要的是，這些演算法在 TLS 長期的實踐過程中先後已經被證實是構成不安全的因素，從而導致安全漏洞。

修復數字簽名

經過前面的學習，相信你也知道 TLS 另一個重要部分是身份驗證。在每個連接中服務都是用具有公鑰的數字證書向客戶端提供身份認證。在 RSA 加密模式下，伺服器通過解密預主密鑰並通過對話記錄計算 MAC 來證明其對私鑰的所有權。在 Diffie-Hellman 模式下，伺服器使用數字簽名來證明私鑰的所有權。

在 TLS 1.2 和更早的版本中，伺服器的簽名僅涵蓋部分握手。用於協商使用哪種對稱密碼的部分沒有由私鑰簽名。這也導致許多引人注目的漏洞 FREAK ， LogJam 等。而在 TLS 1.3 由於伺服器對整個握手記錄進行簽名，因此可以避免這些情況。

HTTPS 建立連接時除了要做 TCP 握手，還要做 TLS 握手，在 TLS 1.2 中會多花兩個消息往返（2 - RTT），這可能導致幾十毫秒甚至上百毫秒的延遲，在移動網路中延遲還會更嚴重。

1-RTT 模式

密碼套件的大幅度簡化，也就沒有必要再像以前那樣走復雜的的協商流程了。TLS 1.3 壓縮了以前的 「Hello」 協商過程，刪除了 「Key Exchange」 消息，把握手時間減少到了 「1-RTT」，效率提高了一倍。

下面是 TLS 1.3 握手過程的簡圖，注意與前面介紹的 TLS 1.2 對比區別在哪裡。

0-RTT 恢復

除了標準的 「1-RTT」 握手，受 QUIC 協議的啟發，客戶端可以在其第一條消息中將加密的數據發送到伺服器，與未加密的 HTTP 相比，沒有額外的延遲成本。

在 TLS 1.2 中，有兩種恢復連接的方法：會話 ID 和會話 Ticket，而 1.3 則將他們組合在一起形成稱為 PSK（pre-shared key，預共享密鑰）恢復的新模式。

握手分析

目前 Nginx 等 Web 伺服器都能夠很好的支持 TLS 1.3，但是要求底層的 OpenSSL 必須是 1.1.1。因此如果要部署需要先升級你的 OpenSSL 版本。

首先TCP 建立連接之後，瀏覽器首先還是發一個 「 Client Hello 」。

由於 1.3 的消息要兼容 1.2，所以開頭的版本號、支持的密碼套件和隨機數（Client Random）結構都是一樣的（這時的隨機數是 32 個位元組）。

注意 「Client Hello」 里的擴展，「 supported_versions 」 表示這是 TLS 1.3，「 supported_groups 」 是支持的曲線，「 key_share 」是曲線對應的參數。

這有點是像是「有話盡量一口氣說完」，還是按照老規矩進行「打招呼」，我這邊有這些信息，考慮到版本升級，所以附帶了一些信息，可能後面會用到。

伺服器收到 「Client Hello」 同樣返回 「Server Hello」 消息，還是要給出一個 隨機數 （Server Random）和選定密碼套件。

表面上看 Version 和 TLS 1.2 是一樣的，重點是後面的擴展。「 supported_versions 」 里確認使用的是 TLS 1.3，然後在 「 key_share 」 擴展帶上曲線和對應的公鑰參數。

伺服器的回應還是老套路，服務端對客戶端的提供的信息作出選擇，另外服務端還要再附加上幾個參數，這次加密就協商定了。

可以看到相比 TLS 1.2 的握手過程，TLS 1.3 僅用兩條消息就共享了 4 個信息： Client Random 和 Server Random 、 Client Params 和 Server Params 。兩邊就可以各自用 DH 算出 「 Pre-Master 」，再用 HKDF 生成主密鑰 「 Master Secret 」，效率比 TLS 1.2 提高了一大截。

在計算出主密鑰後，伺服器立刻發出 「 Change Cipher Spec 」 消息，比 TLS 1.2 提早進入加密通信，後面的證書等就都是加密的了，減少握手時明文信息泄露。

TLS 1.3 還多了一個 「 Change Cipher Spec 」 消息，伺服器用私鑰把前面的曲線、套件、參數等握手數據加了簽名，作用和 「 Finished 」 消息差不多。但由於是私鑰簽名，所以強化了身份認證和防篡改。

兩個「打招呼」消息之後，客戶端驗證伺服器證書，再發 「Finished」 消息，就正式完成了握手，開始收發 HTTP 報文。

現在已經有很多網站都支持了 TLS 1.3，例如 GitHub ：

今天我們主要介紹了 TLS 1.3 的一些新特性，簡單總結下來主要包含下面幾點：

TLS 1.3 涉及的內容很多，有關它的更詳細信息請去參照 RFC-8446 ，關於這部分大家還有哪些要分享的呢？歡迎您的留言或指正。

網路安全系列專題

擴展閱讀

㈢ tls1.2安全嗎

是的，屬於安全協議，目前最新版本：TLS1.3

㈣ 通信安全：哈希、加密、證書、簽名、密鑰協商、ECDH、TLS、DTLS

哈希也叫散列，是把任意長度的輸入通過散列演算法變換成固定長度的輸出，該輸出就是散列值，也叫摘要（Digest）。

這種轉換是一種 壓縮映射。 也就是，散列值的空間通常遠小於輸入的空間，不同的輸入可能會散列成相同的輸出，所以不可能從散列值來確定唯一的輸入值，但如果輸出的位數足夠，不同輸入散列成相同輸出的概率非常非常小。

簡單的說， 散列就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的過程 。

散列是不可逆的 ，也就是無法通過輸出還原輸入，此特性常被用於密碼保存。

SHA-512、MD5等都是著名的散列函數，MD5生成的散列碼是128位，甚至MD5就是哈希的同名詞，你可以通過網站：https://passwordsgenerator.net/sha512-hash-generator/ 在線計算哈希。

散列有什麼用？

加密就是把 明文變成密文的過程，解密就是反方向把密文變成明文 。

比如著名的 凱撒密碼 ，就是把每個字對應到另一個，這樣的話，只要有密碼本，就能對照完成加解密。比如最簡單的，對於英文26個字母，每個字母右移3個，abc變成def，這也是一種加密，當然這種加密很簡單，很容易被破譯。

而諸如AES（高級加密標准）、3DES（三重數據加密演算法）則被公認為很難破解，不過山東大學女教授王小雲很厲害，破解了MD5和SHA-1，迫使加密標准升級，最終當上了院士。

對稱加密

對稱加密就是加解密的密鑰是一樣的，優點是快，這也是傳統的加密方式，像AES、3DES都是對稱加密。

非對稱加密

非對稱加密用於加解密的密鑰不一樣，有2個密鑰，公鑰和私鑰，公鑰可以公開，私鑰妥善保管。RSA、ECC（橢圓曲線加密演算法）、DH（密鑰交換演算法）這些都是非對稱加密。

非對稱加密很慢，有多慢？相比對稱加密慢1000倍，因為慢，所以它常用於密鑰協商（Handshake），協商出會話密鑰後，再用對稱密鑰加密通信數據。

1976年，Whitfield Diffie和Martin Hellman首次提出了非對稱加密的概念，該演算法被稱為Diffie-Hellman密鑰交換。然後在1978年，麻省理工學院的Ron Rivest，Adi Shamir和Leonard Adleman發表了RSA 演算法。這些都可以被視為非對稱加密的基礎。

非對稱加密也稱為公鑰基礎結構，又稱PKI。 非對稱加密的提出是密碼學上的一次革命，影響深遠。

非對稱加密演算法用私鑰加密，用公鑰解密，或者用公鑰加密，用私鑰解密。

證書就是為了證明我是我，比如你要訪問中國銀行網站，但中行官網如何證明它是中行官網呢？答案就是數字證書。

CA是數字證書中心，伺服器需要找CA做認證，讓CA給自己頒布數字證書，數字證書內一般包含服務的一些信息、以及伺服器的公鑰，通過CA的私鑰加密後，產生的數字證書，因為CA的權威性，且它的公鑰天下皆知，所以，如果你能用CA的公鑰解開證書，那便可證明該證書一定是CA頒發的，要不然它不會有CA的私鑰，也便沒法產生可用CA公鑰解密的證書。

所以，由此可見，數字證書用到了非對稱加密。

日常生活中也有簽名，每個人的筆跡是不一樣的，你刷卡消費後在賬單簽上大名，服務員校驗過之後保存下來，你哪天賴賬，便可以有簽名為證，因為別人寫的字跟你的筆跡終有差別。

那數字簽名是什麼呢？比如a發一封email，接收方怎麼證明這封信是a寫的？

本質上，數字簽名也是利用了非對稱加密。

前面講了，非對稱加密有公鑰和私鑰，如果發生方用私鑰加密，然後接收方用發送方的公鑰可以解密，那便可以證明是從某發送方發送的，因為別人拿不到你的私鑰，也便無法用你的私鑰加密，你不能抵賴。

數字簽名通常先對內容算哈希，產生內容摘要，再用私鑰加密，得到簽名。

下面舉一個例子來說明這幾個問題：

張三有2把鑰匙，一把公鑰，公告天下，一把私鑰，妥善保管，只有自己知道，很明顯，非對稱加密。

李四給張三寫信，寫完之後，用張三的公鑰加密，通過郵局寄給張三，即使郵遞員拆開信封看，他也看不懂，因為內容是密文，只有張三的密鑰才能解密。

張三收到信後，用私鑰解密，可以正常閱讀。

現在張三要給李四回信，寫完後，用hash函數生成摘要digest。

然後張三，再用私鑰對摘要加密，生成數字簽名signature。

然後把簽名附在信的下面，一起發給李四。

過程是：信明文 -> hash -> digist -> 私鑰加密 -> signature。

李四收到回信後，用張三的公鑰對數字簽名解密，得到摘要，由此證明，信確實是張三發出的，為什麼？因為如果不是張三發的，那寫信的人就沒有張三私鑰，用別的私鑰加密得到的簽名，是無法用張三的公鑰解開的。

李四，再對信的內容做hash，得到摘要，與上一步得到的摘要對比，如果一致，則證明信的內容沒有被修改過，信的內容是完整的。

復雜的情況出現了。

王五，用自己的公鑰替換李四保存的張三的公鑰，也就是王五欺騙了李四，李四誤把王五的公鑰當張三的公鑰，這樣一來，王五就能冒充張三給李四寫信（王五用自己的私鑰加密）。

問題是什麼？問題是李四不能確信自己保存的公鑰真的是張三的公鑰。如果客戶端電腦上存的工商銀行官網的公鑰，實際上是騙子公司的公鑰，那就麻煩大了。

怎麼破？讓張三去認證中心CA（Certificate Authority），為公鑰做認證，怎麼做呢？CA中心用自己的私鑰，對張三的公鑰和其他相關信息一起加密，生成數字證書（Digital Certificate）。

張三拿到數字證書後，以後給李四回信，在簽名的同時，附帶上數字證書。

李四收到信之後，從CA的公鑰解開數字證書，取出張三的公鑰（一定是真的），然後就能放心的愉快的按之前的流程解開簽名了。

數字證書加入後，核心區別就是張三的公鑰不再保存在李四處，而是通過數字證書下發。

為什麼數字證書里的張三的公鑰一定是真的呢？因為CA是權威機構，假設全世界就一家（其實不止，但也不多），它的公鑰天下盡知，就是固定的串，所以能用CA公鑰解開的證書，一定是CA頒布的，因為CA用它的私鑰加密產生的證書。很明顯，非對稱加密能用於證明我是我。

密鑰交換演算法

著名的DH密鑰交換演算法，這個演算法很有意思，也很巧妙，簡而言之，就是通信雙方交換一點信息（不怕被偷看到），然後就在兩端，分布產生出一個相同的密鑰，神奇啊。

有一個很有意思的例子。

Alice和Bob要協商出一個公共的顏色，他們可以交換信息，但交換的信息，可以被偷看到，怎麼辦？既能協商出公共顏色，又不能讓別人知道呢。

密鑰交換演算法的原理跟這個差不多，網上有大量的資料講述這個問題，我覺得理解了上面的例子，再看ECDH便也不難了。

眾所周知http是互聯網協議，但是它不夠安全，所以後面有改進版的https，其實就是多了一個TLS，這個是傳輸層加密，本質上，就是通過handshake，協商出一個會話密鑰，後面的數據傳遞，都用這個密鑰做對稱加解密。

我們經常講安全通道，其實也就是協商出一個會話密鑰，他並不神秘。胡亂放幾張圖片吧。

為了減少這幾個RTT，又想了各種辦法，然後復用連接的話，就可以做到0RTT，1RTT了。

就說這些吧，最後拋幾個名詞，有興趣自行網路學習：DTLS，HMAC，AEAD，重放攻擊，放大攻擊，是不是很高端？

㈤ 如何使用 TLS/SSL 確保 WebSocket 連接的安全

TLS 為傳輸層安全性協議，是 MySQL 在客戶端與伺服器之間進行加密連接的協議。TLS 有時被稱為 SSL（安全套接層），但是 MySQL 實際上並不使用 SSL 協議進行加密連接，因為它的加密很弱。TLS 協議通過加密數據來確保在兩個通信應用程序之間提供隱私和數據完整性，以便任何第三方都無法攔截通信。它還會驗證對等方以驗證其身份。通過在兩個對等點之間提供安全的通信通道，TLS 協議可以保護消息的完整性並確保其不會被篡改。MySQL 支持多種 TLS 版本協議，此次測試使用 8.0 的 client 為 TLSv1.2。

從 wireshark 中看一下 TLS 握手的步驟：

㈥ TLS協議的協議結構

TLS 協議包括兩個協議組―― TLS 記錄協議和 TLS 握手協議――每組具有很多不同格式的信息 。
TLS 記錄協議是一種分層協議。每一層中的信息可能包含長度、描述和內容等欄位。記錄協議支持信息傳輸、將數據分段到可處理塊、壓縮數據、應用 MAC 、加密以及傳輸結果等。對接收到的數據進行解密、校驗、解壓縮、重組等，然後將它們傳送到高層客戶機。
TLS 連接狀態指的是TLS 記錄協議的操作環境。它規定了壓縮演算法、加密演算法和 MAC 演算法。
TLS 記錄層從高層接收任意大小無空塊的連續數據。密鑰計算：記錄協議通過演算法從握手協議提供的安全參數中產生密鑰、 IV 和 MAC 密鑰。TLS 握手協議由三個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。
TLS握手協議：
1.改變密碼規格協議
2.警惕協議
3.握手協議

㈦ SSL/TLS協議原理解讀

HTTPS是什麼相信大家都知道，如果你不知道。。。請關閉此文！！！
HTTP的數據是明文傳輸的，沒有安全性可言。HTTPS是秘文傳輸，那麼HTTPS是怎麼實現數據的安全(加密)傳輸的？那是因為HTTPS比HTTP多了個'S'。 即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

SSL/TLS協議是網路安全通信的重要基石，本文將簡單介紹SSL/TLS協議，主要關注SSL/TLS協議的安全性，特別是SSL規范的正確實現。 本系列的文章大體分為幾個部分：

1、SSL/TLS簡介
2、SSL/TLS協議的基本流程
3、從SSL到TLS
4、SSL/TLS的流行實現庫

SSL全稱是Secure Sockets Layer，安全套接字層，它是由網景公司(Netscape)設計的主要用於Web的安全傳輸協議，目的是為網路通信提供機密性、認證性及數據完整性保障。如今，SSL已經成為互聯網保密通信的工業標准。

SSL最初的幾個版本(SSL 1.0、SSL2.0、SSL 3.0)由網景公司設計和維護，從3.1版本開始，SSL協議由網際網路工程任務小組(IETF)正式接管，並更名為TLS(Transport Layer Security)，發展至今已有TLS 1.0、TLS1.1、TLS1.2這幾個版本。

如TLS名字所說，SSL/TLS協議僅保障傳輸層安全。同時，由於協議自身特性(數字證書機制)，SSL/TLS不能被用於保護多跳(multi-hop)端到端通信，而只能保護點到點通信。

SSL/TLS協議能夠提供的安全目標主要包括如下幾個：

認證性——藉助數字證書認證伺服器端和客戶端身份，防止身份偽造

機密性——藉助加密防止第三方竊聽

完整性——藉助消息認證碼(MAC)保障數據完整性，防止消息篡改

重放保護——通過使用隱式序列號防止重放攻擊

為了實現這些安全目標，SSL/TLS協議被設計為一個兩階段協議，分為握手階段和應用階段：

握手階段也稱協商階段，在這一階段，客戶端和伺服器端會認證對方身份(依賴於PKI體系，利用數字證書進行身份認證)，並協商通信中使用的安全參數、密碼套件以及MasterSecret。後續通信使用的所有密鑰都是通過MasterSecret生成。

在握手階段完成後，進入應用階段。在應用階段通信雙方使用握手階段協商好的密鑰進行安全通信。

Handshake協議：包括協商安全參數和密碼套件、伺服器身份認證(客戶端身份認證可選)、密鑰交換;

ChangeCipherSpec 協議：一條消息表明握手協議已經完成;

Alert 協議：對握手協議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續，只是會給出錯誤警告;

Record 協議：包括對消息的分段、壓縮、消息認證和完整性保護、加密等。

圖2、圖3都是表示的協議流程，大同小異。可以對比著看加深理解。

每一個SSL/TLS鏈接都是從握手開始的，握手過程包含一個消息序列，用以協商安全參數、密碼套件，進行身份認證以及密鑰交換。握手過程中的消息必須嚴格按照預先定義的順序發生，否則就會帶來潛在的安全威脅。今年頂級安全會議CCS 有文章提出了建立綜合狀態機來檢查SSL鏈接中消息序列……

2.1 握手過程中的消息序列

ClientHello：ClientHello通常是握手過程中的第一條消息，用於告知伺服器客戶端所支持的密碼套件種類、最高SSL/TLS協議版本以及壓縮演算法。

ClientHello中還包含一個隨機數，這個隨機數由4個位元組的當前GMT UNIX時間以及28個隨機選擇的位元組組成，共32位元組。該隨機數會在密鑰生成過程中被使用。

另外，ClientHello中還可能包含客戶端支持的TLS擴展。(TLS擴展可以被用來豐富TLS協議的功能或者增強協議的安全性)

ServerHello：伺服器接受到ClientHello後，會返回ServerHello。伺服器從客戶端在ClientHello中提供的密碼套件、SSL/TLS版本、壓縮演算法列表裡選擇它所支持的項，並把它的選擇包含在ServerHello中告知客戶端。接下來SSL協議的建立就基於伺服器選擇的密碼套件類型、SSL/TLS協議版本以及壓縮演算法。

ServerHello中同樣會包含一個隨機數，同樣4+28 位元組類型，由伺服器生成。

Certificate：客戶端和伺服器都可以發送證書消息來證明自己的身份，但是通常客戶端證書不被使用。 伺服器一般在ServerHello後會接一條Certificate消息，Certificate消息中會包含一條證書鏈，從伺服器證書開始，到Certificate authority(CA)或者最新的自簽名證書結束。下圖形象地描述了證書鏈：

SSL中使用的證書通常是X.509類型證書，X.509證書的內容如下表所示：

在用的X.509證書包含Version 1和Version 3兩種版本，其中v1版本的證書存在安全隱患，同時不支持TLS擴展，被逐漸棄用。現在大多數在用的SSL證書都是V3版本。

同時證書會附帶與協商好的密鑰交換演算法對應的密鑰。密鑰交換演算法以及它們所要求的密鑰類型如下表所示。

ServerKeyExchange：該消息僅當以下密鑰交換演算法被使用時由伺服器發出：

RSA_EXPORT(僅當伺服器的公鑰大於512bit時)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密鑰交換演算法時，伺服器不能發送此消息。

ServerkeyExchange消息會攜帶這些密鑰交換演算法所需要的額外參數，以在後續步驟中協商PreMasterSecret。這些參數需要被簽過名。

CertificateRequest：這個消息通常在要求認證客戶端身份時才會有。消息中包含了證書類型以及可接受的CA列表。

ServerHelloDone：伺服器發送這條消息表明伺服器部分的密鑰交換信息已經發送完了，等待客戶端的消息以繼續接下來的步驟。這條消息只用作提醒，不包含數據域。

ClientKeyExchange：這條消息包含的數據與所選用的密鑰交換演算法有關。

如果選擇的密鑰交換演算法是RSA，那麼消息包含的參數為用伺服器RSA公鑰(包含在之前證書中的或者是ServerKeyExchange中的)加密過的PreMasterSecret，它有48個位元組，前2個位元組表示客戶端支持的最高協議版本，後46個位元組是隨機選擇的。

如果選擇的密鑰交換演算法是DH或者DHE，則可能有兩種情況：

隱式DH公開值：包含在Certificate消息里;

顯示DH公開值：公開值是本消息的一部分。

CertificateVerify：這條消息用來證明客戶端擁有之前提交的客戶端證書的私鑰。

Finished：表明握手階段結束。這是第一條用協商的演算法和密鑰保護的消息。

因為是用協商好的密鑰加密的消息，它可以用來確認已經協商好的密鑰。

同時Finished消息包含一個verify_data域，可以用來校驗之前發送和接收的信息。

Verify_data域是一個PRF函數的輸出(pseudo-random function)。這個偽隨機函數的輸入為：(1)兩個hash值：一個SHA-1，一個MD5，對之前握手過程中交換的所有消息做哈希;(2)the MasterSecret，由預備主密鑰生成;(3)finished_label，如果客戶端發送的則是」client finished」，伺服器發送的則是」server finished」。關於這個PRF的細節在3.3節中會具體描述。 此外，Finished 消息不能夠在ChangeCipherSpec前發送。

2.2 不同密鑰交換演算法對應的握手過程

不同的密鑰交換演算法對應的握手過程中的消息序列是不同的，相應的實現方式也不同，本節介紹幾個常見密鑰交換演算法對應的握手過程。

TLS-RSA：在這個場景下，PreMasterSecret是由客戶端指定的，並用RSA公鑰加密發送給伺服器。伺服器不影響PReMasterSecret的生成。

TLS-DH：基於DH的密鑰交換也被稱為靜態Diffie-Hellman。在這種場景下，可能是雙方各自提交一個證書包含DH公開值，或者伺服器端提交證書包含DH公開值，客戶端在每次會話中選擇一個值。協商好的DH值被用作PreMasterSecret。顯然證書中的參數是固定的，那麼每次鏈接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基於DHE的TLS握手中會有ServerKeyExchange消息。握手過程中交換參數的認證通過數字簽名來實現，支持的簽名演算法包括RSA和DSS。DH參數會有它的數字簽名一起被包含在ServerKeyExchange中被發送出去。客戶端在ClientKeyExchange中返回它的公開DH參數，但沒有簽名保護。同樣協商出來的DH密鑰被用作PreMasterSecret。

2.3 密鑰生成

Pseudo-random Function(PRF)：偽隨機函數是SSL協議中的一個重要組成部分，它被用來秘密擴展以及生成密鑰。在3.1節講解Finished消息時已經簡單提及PRF，在這里我們詳細討論PRF的工作原理。SSL/TLS協議中的PRF如下圖所示：

這個PRF基於兩個hash函數：MD5和SHA-1，它有3個輸入，一個Secret(比如PreMasterSecret)，一個標志符(比如」client finished」, 「server finished」)，還有一個種子值(比如客戶端隨機數+伺服器端隨機數)。

Secret在使用時被分為長度相同的兩半：S1和S2，分別作為P_MD5和P_SHA-1的輸入。

PRF的輸出按如下方式處理得到：

P_MD5和P_SHA-1都是擴展函數，用來擴展秘密值以用於密鑰生成，它們的計算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

這個秘密擴展會一直進行直到得到足夠多的擴展數據。 Key Derivation：主密鑰(MasterSecret)是利用上述PRF從預備主密鑰(PreMasterSecret)生成的。每個MasterSecret為48位元組，生成方式如下：

得到MasterSecret後，它會被進一步處理最後生成4個不同的密鑰和2個初始向量(IV)。處理過程如下：

處理過程一直持續到足夠多的輸出被生成，然後把輸出分為4個key和2個IV：

下圖完整闡述了SSL/TLS協議中的密鑰生成過程。

本節介紹SSL/TLS協議的版本變遷，不同版本的區別以及安全特性等。

SSL 1.0由於從來沒有被公開過，並且存在嚴重安全漏洞，我們就不討論了。

SSL 2.0：SSL 2.0於1995年4月被發布。SSL 2.0中主要存在的問題如下：

MAC不能覆蓋填充長度域，攻擊者可能利用這點破壞消息完整性;

缺乏握手認證，攻擊者可以篡改密碼套件列表，誘騙通信雙方使用較弱的密碼套件;

使用較弱的或有問題的密碼演算法(如MD5，RC4等)，或者使用不安全的分組模式(如CBC模式);

對於不同的密碼學基元使用相同的密鑰，違背基本安全常識。

由於以上安全問題，RFC 6176已經明確提出避免使用SSL 2.0，但是現實生活中還有少量客戶端和伺服器支持SSL 2.0.

SSL 3.0：SSL 3.0引入了一些新的特性和機制解決了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子協議。SSL 3.0向後兼容SSL 2.0，相對於SSL 2.0，它的主要改變包括以下幾點：

支持更多的密碼套件(支持更多的密碼演算法如DSS，SHA-1)

在握手階段支持密鑰協商(DH和FORTEZZA)

支持密碼學參數的重協商

增加了消息壓縮選項

MAC能夠覆蓋填充長度域了，同時MAC可以使用MD5或者SHA-1

不同的密碼學基元使用不同的key

Alert子協議能對任何錯誤給出兩種提示：Warning和Fatal

中止鏈接的時候會用一個close_notify警告通知通信雙方

支持證書鏈，而非單個證書

通過Finished消息認證所有發送和接收的消息

加密了的PreMasterSecret包含當前使用的協議版本，防止協議回滾

TLS 1.0：TLS 1.0和SSL 3.0差別非常小。實際上，TLS 1.0是SSL 3.1，在IETF接手後改名為TLS。TLS 1.0版本是目前使用最廣泛的SSL/TLS協議版本。

TLS 1.0不再支持使用FORTEZZA的密碼套件。

TLS 1.0中MAC被替換成HMAC。

之前提到ChangeCipherSpec消息必須在Finished消息前發送，在TLS 1.0中，如果消息序列不符合這個要求，會產生FATAL警告並終止鏈接。

TLS 1.1：這個版本相比之前改動也很小。最重要的改動是預防了針對CBC分組模式的一些攻擊。現在的填充錯誤變的和非法MAC錯誤不可區分了，防止攻擊者利用可區分錯誤響應建立解密預言機對密文進行攻擊。

在每次加密過程中，使用CBC分組模式時，都需要顯示給出IV，而不用再密鑰生成時使用PRF生成IV。

此外，TLS 1.1禁止為適應之前出口限制而使用弱化的密碼套件。

TLS 1.2：這是最新的版本，部署的還比較少。這個版本禁用了PRF中的MD5和SHA-1，而用一個可配置的hash函數取代了它們，這樣的修改簡化了計算過程。修改後的PRF風格如下：

此外，TLS 1.2的一個重要變化是支持認證加密模式(支持GCM等)。但是由於一些AEAD(Authenticated Encryption with Associated Data)密碼演算法要求IV為隱式的，所以IV又恢復到由MasterSecret生成，即TLS 1.0以前的風格。

TLS 1.2支持使用GCM、CCM的新密碼套件。

同時SSL 2.0被宣布放棄，不再向後兼容SSL 2.0.

本節簡單介紹一下流行的SSL/TLS實現庫，SSL協議非常復雜，由開發者自己實現常常會出錯，開發者在具體實現SSL協議時通常會依賴於這些密碼學庫。

4.1 常見的SSL/TLS 實現

OpenSSL：這是非常流行的開源SSL/TLS實現。

OpenSSLim完全用C語言實現，支持SSL 2.0/3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。

OpenSSL 近年來出現了很多的安全漏洞，比如2014年曝出的著名的Heartbleed漏洞等。

JSSE：這是使用Java實現的，支持SSL 3.0，TLS 1.0/1.1/1.2.

Bouncy Castle：它不僅僅支持SSL/TLS，它是一個完整的密碼學庫，支持各種密碼學演算法和協議。不過它僅僅支持TLS 1.0版本。

Android平台主要使用這個密碼學庫。

GnuTLS：這是另一個用C語言實現的庫，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同時以各種安全漏洞多而聞名。

NSS：這是最初由網景公司(Netscape)開發的庫，支持SSL 2.0/3.0，TLS 1.0/1.1，現在主要被瀏覽器和客戶端軟體使用，比如Firefox使用的就是NSS庫，Chrome使用的是一個NSS庫的修正版。

下表是一些常見軟體以及它們所使用的SSL/TLS實現庫的情況：

其它還有一些常用的SSL實現庫，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由於市場佔有率不高，我們這里就不多做介紹了。

4.2 流行SSL/TLS實現庫的安全研究

最近幾年曝出的高風險SSL安全漏洞大多跟SSL實現庫有關，比如2014年4月曝出的「心臟滴血」漏洞，存在於OpenSSL 1.0.1-1.0.1f版本中，影響全球近17%的Web伺服器;同樣是2014年曝出的蘋果公司iOS 7.0.6版本系統中存在的「gotofail」漏洞，因為程序員的疏忽導致SSL證書校驗中的簽名校驗失效;包括今年曝出的SSL Freak攻擊也是由於SSL實現庫的安全漏洞導致的攻擊，我們研究小組的同學對這個攻擊有詳細的分析，參見《SSL Freak來襲：如何實施一個具體的SSL Freak攻擊》。同時我們還開發了一個基於python的中間人代理攻擊框架「風聲」對某國內知名電商的伺服器進行具體的攻擊，並上報了漏洞。

考慮到大量SSL/TLS實現庫中存在安全問題，同時這些主流的SSL/TLS實現庫對開發者而言使用難度較高，比如有些SSL/TLS實現庫要求開發者自己進行隨機數生成或密鑰管理，讓缺乏系統信息安全知識培訓的開發者去使用這樣高度復雜的密碼學庫容易產生很多安全問題。我們在這里推薦一些高級密碼學庫：Google keycazer、NaCl、Cryptlib、GPGME。這些密碼學庫存在的安全問題較少，同時封裝了一些底層的密碼學操作，降低了開發者的使用難度。

以上就是本次要介紹的SSL /TLS協議基本知識，後續的文章我們會對一些典型SSL/TLS攻擊進行具體介紹。

參考：
1、 http://netsecurity.51cto.com/art/201505/476337.htm
2、 http://www.cnblogs.com/NathanYang/p/9183300.html
3、 https://www.cnblogs.com/bhlsheji/p/4586597.html

㈧ 網頁設置tls是什麼意思

網頁設置tls是加密的安全協議。TLS 保證安全，這里的，安全，分兩部分，一是傳輸內容加密，二是服務端的身份認證。

此為服務端單向認證，還有客戶端或服務端雙向認證，流程類似，只不過客戶端也有自己的證書，並發送給伺服器進行驗證。

內容結構

安全傳輸層協議TLS用於在兩個通信應用程序之間提供保密性和數據完整性，TLS協議包括兩個協議組TLS記錄協議和TLS握手協議每組具有很多不同格式的信息。

TLS記錄協議是一種分層協議，每一層中的信息可能包含長度，描述和內容等欄位，記錄協議支持信息傳輸，將數據分段到可處理塊，壓縮數據，應用MAC，加密以及傳輸結果等，對接收到的數據進行解密，校驗，解壓縮，重組等，然後將它們傳送到高層客戶機。

TLS連接狀態指的是TLS記錄協議的操作環境，它規定了壓縮演算法，加密演算法和MAC演算法。

㈨ ssl協議包含幾個子協議

SSL(Secure Sockets Layer 安全套接層)協議目前已成為互聯網上用來鑒別網站和網頁瀏覽者的身份，以及在瀏覽器使用者及網頁伺服器之間進行加密通訊的全球化標准協議。簡單理解是網路連接的一種安全協議，可以保護用戶信息安全。

目前SSL協議有SSL記錄協議和SSL握手協議兩種：

• SSL記錄協議建立在可靠的傳輸協議之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。

• SSL握手協議建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等。

SSL協議的主要作用有哪些：

1、認證用戶和伺服器，確保數據發送到正確的客戶機和伺服器;

2、加密數據以防止數據中途被竊取;

3、維護數據的完整性，確保數據在傳輸過程中不被改變。

㈩ 什麼是TLS

資料來自網路

TLS
TLS：安全傳輸層協議
（TLS：Transport Layer Security Protocol）
安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面。 TLS 記錄協議提供的連接安全性具有兩個基本特性：

私有――對稱加密用以數據加密（DES 、RC4 等）。對稱加密所產生的密鑰對每個連接都是唯一的，且此密鑰基於另一個協議（如握手協議）協商。記錄協議也可以不加密使用。
可靠――信息傳輸包括使用密鑰的 MAC 進行信息完整性檢查。安全哈希功能（ SHA、MD5 等）用於 MAC 計算。記錄協議在沒有 MAC 的情況下也能操作，但一般只能用於這種模式，即有另一個協議正在使用記錄協議傳輸協商安全參數。
TLS 記錄協議用於封裝各種高層協議。作為這種封裝協議之一的握手協議允許伺服器與客戶機在應用程序協議傳輸和接收其第一個數據位元組前彼此之間相互認證，協商加密演算法和加密密鑰。 TLS 握手協議提供的連接安全具有三個基本屬性：

可以使用非對稱的，或公共密鑰的密碼術來認證對等方的身份。該認證是可選的，但至少需要一個結點方。
共享加密密鑰的協商是安全的。對偷竊者來說協商加密是難以獲得的。此外經過認證過的連接不能獲得加密，即使是進入連接中間的攻擊者也不能。
協商是可靠的。沒有經過通信方成員的檢測，任何攻擊者都不能修改通信協商。
TLS 的最大優勢就在於：TLS 是獨立於應用協議。高層協議可以透明地分布在 TLS 協議上面。然而， TLS 標准並沒有規定應用程序如何在 TLS 上增加安全性；它把如何啟動 TLS 握手協議以及如何解釋交換的認證證書的決定權留給協議的設計者和實施者來判斷。

協議結構

TLS 協議包括兩個協議組―― TLS 記錄協議和 TLS 握手協議――每組具有很多不同格式的信息。在此文件中我們只列出協議摘要並不作具體解析。具體內容可參照相關文檔。

TLS 記錄協議是一種分層協議。每一層中的信息可能包含長度、描述和內容等欄位。記錄協議支持信息傳輸、將數據分段到可處理塊、壓縮數據、應用 MAC 、加密以及傳輸結果等。對接收到的數據進行解密、校驗、解壓縮、重組等，然後將它們傳送到高層客戶機。

TLS 連接狀態指的是 TLS 記錄協議的操作環境。它規定了壓縮演算法、加密演算法和 MAC 演算法。

TLS 記錄層從高層接收任意大小無空塊的連續數據。密鑰計算：記錄協議通過演算法從握手協議提供的安全參數中產生密鑰、 IV 和 MAC 密鑰。 TLS 握手協議由三個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。

改變密碼規格協議
警惕協議
握手協議