tls加密技術屬於hash

A. SSL安全證書的實現機制

TLS/SSL的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

B. 全站HTTPS能帶來怎樣的優勢HTTPS原理是什麼，如何加密

https作用：

1.保護隱私：所有信息都是加密傳播，第三方無法竊聽數據。如果使用HTTP明文傳輸數據的話，很可能被第三方劫持數據，那麼所輸入的密碼或者其他個人資料都被暴露在他人面前，後果可想而知。

2.數據完整性：一旦第三方篡改了數據，接收方會知道數據經過了篡改，這樣便保證了數據在傳輸過程中不被篡改 —— 數據的完整性。

3.身份認證：第三方不可能冒充身份參與通信，因為伺服器配備了由證書頒發機構（Certificate

Authority，簡稱CA）頒發的安全證書，可以證實伺服器的身份信息，防止第三方冒充身份。（也有少數情況下，通信需要客戶端提供證書，例如銀行系統，需要用戶在登錄的時候，插入銀行提供給用戶的USB，就是需要客戶端提供證書，用來驗證客戶的身份信息。）

https原理：

http+ssl證書=https

像目前JoySSL品牌的ssl證書很優質，有著多種品牌證書，價格方面性價比也很高。JoySSL：https安全證書

C. https的基本原理。

HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議，TLS/SSL中使用了非對稱加密，對稱加密以及HASH演算法。握手過程的簡單描述如下：

1.瀏覽器將自己支持的一套加密規則發送給網站。

2.網站從中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址，加密公鑰，以及證書的頒發機構等信息。

3.獲得網站證書之後瀏覽器要做以下工作：

a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。

b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。

c) 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。

4.網站接收瀏覽器發來的數據之後要做以下的操作：

a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。

b) 使用密碼加密一段握手消息，發送給瀏覽器。

5.瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。

這里瀏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為後續真正數據的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH演算法如下：

非對稱加密演算法：RSA，DSA/DSS

對稱加密演算法：AES，RC4，3DES

HASH演算法：MD5，SHA1，SHA256

其中非對稱加密演算法用於在握手過程中加密生成的密碼，對稱加密演算法用於對真正傳輸的數據進行加密，而HASH演算法用於驗證數據的完整性。由於瀏覽器生成的密碼是整個數據加密的關鍵，因此在傳輸的時候使用了非對稱加密演算法對其加密。非對稱加密演算法會生成公鑰和私鑰，公鑰只能用於加密數據，因此可以隨意傳輸，而網站的私鑰用於對數據進行解密，所以網站都會非常小心的保管自己的私鑰，防止泄漏。

TLS握手過程中如果有任何錯誤，都會使加密連接斷開，從而阻止了隱私信息的傳輸。正是由於HTTPS非常的安全，攻擊者無法從中找到下手的地方，於是更多的是採用了假證書的手法來欺騙客戶端，從而獲取明文的信息，但是這些手段都可以被識別出來。

D. 什麼是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 握手協議由三個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。

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

E. 通信安全：哈希、加密、證書、簽名、密鑰協商、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，重放攻擊，放大攻擊，是不是很高端？

F. 什麼是SSL加密，什麼是TLS加密

SSL加密的英文全稱是Secure Socket Layer，翻譯過來就是安全套接層。

它是在傳輸通信協議（TCP/IP）上實現的一種網路安全協議，廣泛支持各種類型的網路，並同時提供三種網路基本安全服務，而且這三種服務都是使用公開密鑰技術。

TLS加密的英文全稱是Transport Layer Security，翻譯過來就是安全傳輸層協議。

TLS是用於在兩個通信應用程序之間，為通信提供保密性和數據完整性。這個協議一共有兩層，分別是記錄協議和握手協議。通過這個協議可以對網站、網路傳真、電子郵件等數據傳輸進行加密、保密。

(6)tls加密技術屬於hash擴展閱讀：

1、SSL

SSL協議優勢

SSL協議的優勢在於它是與應用層協議獨立無關的。

高層的應用層協議（例如：HTTP、FTP、Telnet等等）能透明的建立於SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密演算法、通信密鑰的協商以及伺服器認證工作。在此之後應用層協議所傳送的數據都會被加密，從而保證通信的私密性。

SSL體系結構

SSL被設計成使用TCP來提供一種可靠的端到端的安全服務，不是單個協議，而是二層協議。

低層是SSL記錄層，用於封裝不同的上層協議，另一層是被封裝的協議，即SSL握手協議，它可以讓伺服器和客戶機在傳輸應用數據之前，協商加密演算法和加密密鑰，客戶機提出自己能夠支持的全部加密演算法，伺服器選擇最適合它的演算法。

2、TLS

優勢

TLS協議的優勢是與高層的應用層協議（如HTTP、FTP、Telnet等）無耦合。

應用層協議能透明地運行在TLS協議之上，由TLS協議進行創建加密通道需要的協商和認證。應用層協議傳送的數據在通過TLS協議時都會被加密，從而保證通信的私密性。

TLS協議是可選的，必須配置客戶端和伺服器才能使用。

主要有兩種方式實現這一目標：一個是使用統一的TLS協議通信埠（例如：用於HTTPS的埠443）；另一個是客戶端請求伺服器連接到TLS時使用特定的協議機制（例如：郵件、新聞協議和STARTTLS）。

演算法

在客戶端和伺服器開始交換TLS所保護的加密信息之前，他們必須安全地交換或協定加密密鑰和加密數據時要使用的密碼。

參考資料來源：網路-SSL安全套接層

參考資料來源：網路-TLS安全傳輸層

G. TLS/SSL數字證書里的指紋演算法、簽名演算法和簽名哈希演算法各是做什麼用的

您好！

作用與目的相同都是為了進行加密，更好的保護平台，SSL安全哈希演算法，是數字簽名演算法標准，所以無論您在哪裡注冊無論多少價格的證書，其演算法基本上都是相同的！

申請SSL證書為考慮到瀏覽器兼容性，保持更多的瀏覽器可以訪問，通常採取加密演算法：RSA 2048 bits，簽名演算法：SHA256WithRSA，該演算法被公認使用，就是網路也使用該演算法！

RSA加密演算法：公鑰用於對數據進行加密，私鑰用於對數據進行解密。

RSA簽名演算法：在簽名演算法中，私鑰用於對數據進行簽名，公鑰用於對簽名進行驗證。

加密演算法分為兩大類：1、對稱加密演算法 2、非對稱加密演算法。

由於計算能力的飛速發展，從安全性角度考慮，很多加密原來SHA1WithRSA簽名演算法的基礎上，新增了支持SHA256WithRSA的簽名演算法。該演算法在摘要演算法上比SHA1WithRSA有更強的安全能力。目前SHA1WithRSA的簽名演算法會繼續提供支持，但為了您的應用安全，強烈建議使用SHA256WithRSA的簽名演算法。

H. 深入TLS/SSL協議

TLS/SSL 協議是為了解決網路通訊中的信息安全問題而誕生的。

它的設計目的主要有三個：

TLS/SSL 協議主要包含兩部分：

對稱加密演算法是指在加密和解密過程中使用相同的密鑰。

舉例：
張三在與李四通訊時為了防止第三方竊聽，使用莫斯密碼將通訊內容加密。李四接收到通訊內容後，使用相同的莫斯密碼將內容解密。

因為使用了相同的莫斯密碼，所以這屬於對稱加密。

網路通訊中的對稱加密之所以能夠使用相同的密鑰對內容進行加/解密，是因為使用了異或運算。

在數學領域中異或運算：當兩兩數值相同為否，而數值不同時為真。

舉例：
現有一把密鑰：1010，與明文：0110。

可見 XOR 異或運算是對稱加密的關鍵！

優點：

缺點：

異或運算要求雙方長度一致的這個缺點要怎麼解決呢？聰明的同學或許已經想到解決方法了：就是將明文劃分為多個等長的塊。

比如密鑰為16位元組的，那就將明文劃分為多個16位元組的塊，分別用密鑰對這些明文塊進行加解密。

Block cipher 分組加密原理就是這樣：將明文劃分為多個等長的 Block 塊，對每一個 Block 塊分別加解密。

但並不是所有的明文都能恰好的劃分為16位元組的塊。這時就需要填充！

填充的目的：

填充主要有兩種方法：

其中位元組填充有4種填充方式：

對明文進行分組、填充後，還要按照一定的規律或方法進行加/解密。這些規律或者方法就是工作模式。

分組工作模式： block cipher mode of operation

1、 電子密碼本 ECB 模式-- Electronic codebook
就是直接將明文分解為多個塊，對每個塊進行加密。

這種工作方法非常簡單、快速。但是缺點在於同樣的明文塊會被加密成相同的密文塊；因此，它不能很好的隱藏數據模式。

舉例：
對圖片進行 ECB 之後，是無法隱藏到圖像的輪廓特性的。如下圖所示：

CTR 模式同樣存在問題：無法提供密文的完整性校驗。當密文在傳輸過程中存在丟失的情況下，是無法保證密文的完整性的。

MAC 演算法-- Message Authentication Code 。
MAC 演算法能夠實現消息的完整性校驗。工作原理是基於hash函數的。

hash 函數是一種從任何一種數據中創建小的數字「指紋」的方法。 hash 函數把消息或數據壓縮成摘要，使得數據量變小，將數據的格式固定下來。
簡而言之就是：無論輸入多長的字元串，通過 hash 函數，都能得到定長較短的字元串。

MAC 工作流程如圖所示：

CTR 分組工作模式加上 MAC 演算法就誕生了 GCM 分組工作模式。

高級加密標准 AES 演算法-- Advanced Encryption Standard

AES 的分組 Block 塊長度固定為128比特，也就是16位元組。
密鑰長度則可以是128，192或256比特。

所以從上圖中看出，分組長度128比特分為4個32比特。而不同長度的密鑰則分為4、6. 8組32位比特的矩陣。

AES 加密流程：如圖所示

10輪加密可分為初始輪、普通輪和最終輪。

addRoundKey 輪密鑰加

SubBytes 位元組替代

ShiftRows 行移位

對稱加密的最大的問題是怎麼把密鑰傳遞給對方。非對稱密碼可以實現密鑰的安全傳遞。

每一個參與方都有一對密鑰：

非對稱加解密過程：

舉例：
張三要和李四通訊
第一步：張三用李四的公鑰進行加密，將密文發送給李四。
第二步：李四用自己的私鑰進行解密。

密文是無法通過公鑰解密的，只有私鑰才能解密。

張三怎麼拿到李四的公鑰？有兩種辦法：

RSA 是基於公開密鑰密碼體制的。

公開密鑰密碼體制是一種「由已知加密密鑰推導出解密密鑰在計算上是不可行的」密碼體制。

RSA 演算法中公私鑰的產生：

RSA 的安全性依賴於大數因數分解非常非常困難，也就是通過一個大數 n 是非常難的分解出 p 和 q 。

RSA 演算法的加解密流程：如下圖所示

由於進行大量的大數乘法運算，RSA的速度是對應同樣安全級別的對稱密碼演算法的1/1000左右。

PKI 是非對稱密碼學的一個非常重要的應用。

基於私鑰加密，只能使用公鑰解密的原理實現身份驗證的作用。

簽名與驗簽的流程

簽名：

驗簽：

證書類型：

從加密安全性上看，三類證書的保密性都是一樣的，只有在站長的個人信息驗證上有所不同。

上面說到張三有兩種辦法可以拿到李四的公鑰：

RSA 演算法一般是第一種方法中用於 CA 機構的身份驗證上的。事實上 RSA 演算法用於第二種方法也是可行的。

舉例：
張三與李四建立鏈接。李四用RSA演算法生成一對公私鑰，在握手中李四將公鑰傳遞給張三。然後張三將對稱加密的密鑰用公鑰進行加密後傳遞給李四，李四用私鑰解密得到密鑰。

就算第三方拿到公鑰，沒有私鑰是無法解密密文的。

但這種方式有一個缺點：沒有前向保密性。
也就是說當第三方將通訊的報文全部保存下來後，在破解出私鑰之後，就能知道所有密文內容。

而 DH 密鑰交換協議就解決了這個問題。它可以雙方在完全沒有對方任何預先信息的條件下通過不安全信道創建起一個密鑰。所以每一次通訊中密鑰都是實時生成的

具體流程：

DH密鑰交互協議的原理：

DH 交換協議的問題：容易遭到中間人偽造攻擊。

簡單來說：第三方假裝自己是張三向李四進行一次 DH 密鑰交換，然後又假裝李四向張三進行一個 DH 密鑰交換。就可以知道密鑰 K 。

解決這個方法很簡單，就是使用 PKI 公鑰基礎體系中的身份驗證。第三方就無法假裝李四這個站長了。

從圖中看出 DH 協議也涉及到大量的大數乘法運算，速度也是非常慢的。而目前使用的 DH 密鑰交換協議是基於 ECC 橢圓曲線加持過的，速度非常的快。稱為 ECDHE 密鑰交換演算法。具體細節可以自己去搜索查詢。

TLS1.2 中經常使用的一個安全套件是：
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

具體說明一下：

分組密碼工作模式 --wiki
高級加密標准 --wiki
RSA演算法 --wiki
DH密鑰交換協議 --wiki
《計算機網路：自頂向下方法》
Web協議詳解與抓包實戰--陶輝

I. TLS 詳解

SSL (Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本後發展成了標准安全協議 - TLS (Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在實現上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規范協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)

只需配置瀏覽器和伺服器相關設置開啟 TLS，即可實現 HTTPS，TLS 高度解耦，可裝可卸，與上層高級應用層協議相互協作又相互獨立。

TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

TLS 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密演算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

例如，在 HTTPS 協議中，客戶端發出請求，服務端會將公鑰發給客戶端，客戶端驗證過後生成一個密鑰再用公鑰加密後發送給服務端（非對稱加密），雙方會在 TLS 握手過程中生成一個協商密鑰（對稱密鑰），成功後建立加密連接。通信過程中客戶端將請求數據用協商密鑰加密後發送，服務端也用協商密鑰解密，響應也用相同的協商密鑰。後續的通信使用對稱加密是因為對稱加解密快，而握手過程中非對稱加密可以保證加密的有效性，但是過程復雜，計算量相對來說也大。

記錄協議負責在傳輸連接上交換的所有底層消息，並且可以配置加密。每一條 TLS 記錄以一個短標頭開始。標頭包含記錄內容的類型 (或子協議)、協議版本和長度。原始消息經過分段 (或者合並)、壓縮、添加認證碼、加密轉為 TLS 記錄的數據部分。

記錄層將信息塊分割成攜帶 2^14 位元組 (16KB) 或更小塊的數據的 TLSPlaintext 記錄。

記錄協議傳輸由其他協議層提交給它的不透明數據緩沖區。如果緩沖區超過記錄的長度限制（2^14），記錄協議會將其切分成更小的片段。反過來也是可能的，屬於同一個子協議的小緩沖區也可以組合成一個單獨的記錄。

壓縮演算法將 TLSPlaintext 結構轉換為 TLSCompressed 結構。如果定義 CompressionMethod 為 null 表示不壓縮

流加密（BulkCipherAlgorithm）將 TLSCompressed.fragment 結構轉換為流 TLSCiphertext.fragment 結構

MAC 產生方法如下：

seq_num（記錄的序列號）、hash（SecurityParameters.mac_algorithm 指定的哈希演算法）

塊加密（如 RC2 或 DES），將 TLSCompressed.fragment 結構轉換為塊 TLSCiphertext.fragment 結構

padding: 添加的填充將明文長度強制為塊密碼塊長度的整數倍。填充可以是長達 255 位元組的任何長度，只要滿足 TLSCiphertext.length 是塊長度的整數倍。長度大於需要的值可以阻止基於分析交換信息長度的協議攻擊。填充數據向量中的每個 uint8 必須填入填充長度值 (即 padding_length)。

padding_length: 填充長度應該使得 GenericBlockCipher 結構的總大小是加密塊長度的倍數。合法值范圍從零到 255（含）。 該長度指定 padding_length 欄位本身除外的填充欄位的長度

加密塊的數據長度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的總和加一

加密和 MAC 功能將 TLSCompressed 結構轉換為 TLSCiphertext。記錄的 MAC 還包括序列號，以便可以檢測到丟失，額外或重復的消息。

記錄協議需要一種演算法，從握手協議提供的安全性參數生成密鑰、 IV 和 MAC secret.

主密鑰 (Master secret): 在連接中雙方共享的一個 48 位元組的密鑰
客戶隨機數 (client random): 由客戶端提供的 32 位元組值
伺服器隨機數 (server random): 由伺服器提供的 32 位元組值

握手是 TLS 協議中最精密復雜的部分。在這個過程中，通信雙方協商連接參數，並且完成身 份驗證。根據使用的功能的不同，整個過程通常需要交換 6~10 條消息。根據配置和支持的協議擴展的不同，交換過程可能有許多變種。在使用中經常可以觀察到以下三種流程：(1) 完整的握手， 對伺服器進行身份驗證；(2) 恢復之前的會話採用的簡短握手；(3) 對客戶端和伺服器都進行身份驗證的握手。

握手協議消息的標頭信息包含消息類型（1 位元組）和長度（3 位元組），餘下的信息則取決於消息類型：

每一個 TLS 連接都會以握手開始。如果客戶端此前並未與伺服器建立會話，那麼雙方會執行一次完整的握手流程來協商 TLS 會話。握手過程中，客戶端和伺服器將進行以下四個主要步驟:

下面介紹最常見的握手規則，一種不需要驗證客戶端身份但需要驗證伺服器身份的握手:

這條消息將客戶端的功能和首選項傳送給伺服器。

是將伺服器選擇的連接參數傳回客戶端。

這個消息的結構與 ClientHello 類似，只是每個欄位只包含一個選項，其中包含服務端的 random_S 參數 (用於後續的密鑰協商)。伺服器無需支持客戶端支持的最佳版本。如果伺服器不支持與客戶端相同的版本，可以提供某個其他版本以期待客戶端能夠接受

圖中的 Cipher Suite 是後續密鑰協商和身份驗證要用的加密套件，此處選擇的密鑰交換與簽名演算法是 ECDHE_RSA，對稱加密演算法是 AES-GCM，後面會講到這個

還有一點默認情況下 TLS 壓縮都是關閉的，因為 CRIME 攻擊會利用 TLS 壓縮恢復加密認證 cookie，實現會話劫持，而且一般配置 gzip 等內容壓縮後再壓縮 TLS 分片效益不大又額外佔用資源，所以一般都關閉 TLS 壓縮

典型的 Certificate 消息用於攜帶伺服器 X.509 證書鏈 。
伺服器必須保證它發送的證書與選擇的演算法套件一致。比方說，公鑰演算法與套件中使用的必須匹配。除此以外，一些密鑰交換演算法依賴嵌入證書的特定數據，而且要求證書必須以客戶端支持的演算法簽名。所有這些都表明伺服器需要配置多個證書（每個證書可能會配備不同的證書鏈）。

Certificate 消息是可選的，因為並非所有套件都使用身份驗證，也並非所有身份驗證方法都需要證書。更進一步說，雖然消息默認使用 X.509 證書，但是也可以攜帶其他形式的標志；一些套件就依賴 PGP 密鑰

攜帶密鑰交換需要的額外數據。ServerKeyExchange 是可選的，消息內容對於不同的協商演算法套件會存在差異。部分場景下，比如使用 RSA 演算法時，伺服器不需要發送此消息。

ServerKeyExchange 僅在伺服器證書消息（也就是上述 Certificate 消息）不包含足夠的數據以允許客戶端交換預主密鑰（premaster secret）時才由伺服器發送。

比如基於 DH 演算法的握手過程中，需要單獨發送一條 ServerKeyExchange 消息帶上 DH 參數:

表明伺服器已經將所有預計的握手消息發送完畢。在此之後，伺服器會等待客戶端發送消息。

客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證內容包括如下:

由 PKI 體系 的內容可知，對端發來的證書簽名是 CA 私鑰加密的，接收到證書後，先讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性；然後去查詢證書的吊銷情況等

合法性驗證通過之後，客戶端計算產生隨機數字的預主密鑰（Pre-master），並用證書公鑰加密，發送給伺服器並攜帶客戶端為密鑰交換提供的所有信息。這個消息受協商的密碼套件的影響，內容隨著不同的協商密碼套件而不同。

此時客戶端已經獲取全部的計算協商密鑰需要的信息: 兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，然後得到協商密鑰(用於之後的消息加密)

圖中使用的是 ECDHE 演算法，ClientKeyExchange 傳遞的是 DH 演算法的客戶端參數，如果使用的是 RSA 演算法則此處應該傳遞加密的預主密鑰

通知伺服器後續的通信都採用協商的通信密鑰和加密演算法進行加密通信

Finished 消息意味著握手已經完成。消息內容將加密，以便雙方可以安全地交換驗證整個握手完整性所需的數據。

這個消息包含 verify_data 欄位，它的值是握手過程中所有消息的散列值。這些消息在連接兩端都按照各自所見的順序排列，並以協商得到的主密鑰 (enc_key) 計算散列。這個過程是通過一個偽隨機函數（pseudorandom function，PRF）來完成的，這個函數可以生成任意數量的偽隨機數據。
兩端的計算方法一致，但會使用不同的標簽（finished_label）：客戶端使用 client finished，而伺服器則使用 server finished。

因為 Finished 消息是加密的，並且它們的完整性由協商 MAC 演算法保證，所以主動網路攻擊者不能改變握手消息並對 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的長度默認是 12 位元組（96 位），並且允許密碼套件使用更長的長度。在此之前的版本，除了 SSL 3 使用 36 位元組的定長消息，其他版本都使用 12 位元組的定長消息。

伺服器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，同樣計算得到協商密鑰: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;

同樣計算之前所有收發信息的 hash 值，然後用協商密鑰解密客戶端發送的 verify_data_C，驗證消息正確性;

服務端驗證通過之後，伺服器同樣發送 change_cipher_spec 以告知客戶端後續的通信都採用協商的密鑰與演算法進行加密通信（圖中多了一步 New Session Ticket，此為會話票證，會在會話恢復中解釋）;

伺服器也結合所有當前的通信參數信息生成一段數據 (verify_data_S) 並採用協商密鑰 session secret (enc_key) 與演算法加密並發送到客戶端;

客戶端計算所有接收信息的 hash 值，並採用協商密鑰解密 verify_data_S，驗證伺服器發送的數據和密鑰，驗證通過則握手完成;

開始使用協商密鑰與演算法進行加密通信。

HTTPS 通過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能。加密過程中，需要用到非對稱密鑰交換和對稱內容加密兩大演算法。

對稱內容加密強度非常高，加解密速度也很快，只是無法安全地生成和保管密鑰。在 TLS 協議中，最後的應用數據都是經過對稱加密後傳輸的，傳輸中所使用的對稱協商密鑰(上文中的 enc_key)，則是在握手階段通過非對稱密鑰交換而來。常見的 AES-GCM、ChaCha20-Poly1305，都是對稱加密演算法。

非對稱密鑰交換能在不安全的數據通道中，產生只有通信雙方才知道的對稱加密密鑰。目前最常用的密鑰交換演算法有 RSA 和 ECDHE。

RSA 歷史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（橢圓曲線）的 DH（Diffie-Hellman）演算法，計算速度快，且支持 PFS。

在 PKI 體系 一節中說明了僅有非對稱密鑰交換還是無法抵禦 MITM 攻擊的，所以需要引入了 PKI 體系的證書來進行身份驗證，其中服務端非對稱加密產生的公鑰會放在證書中傳給客戶端。

在 RSA 密鑰交換中，瀏覽器使用證書提供的 RSA 公鑰加密相關信息，如果服務端能解密，意味著服務端擁有與公鑰對應的私鑰，同時也能算出對稱加密所需密鑰。密鑰交換和服務端認證合並在一起。

在 ECDH 密鑰交換中，服務端使用私鑰 (RSA 或 ECDSA) 對相關信息進行簽名，如果瀏覽器能用證書公鑰驗證簽名，就說明服務端確實擁有對應私鑰，從而完成了服務端認證。密鑰交換則是各自發送 DH 參數完成的，密鑰交換和服務端認證是完全分開的。

可用於 ECDHE 數字簽名的演算法主要有 RSA 和 ECDSA - 橢圓曲線數字簽名演算法 ，也就是目前密鑰交換 + 簽名有三種主流選擇:

比如我的網站使用的加密套件是 ECDHE_RSA，可以看到數字簽名演算法是 sha256 哈希加 RSA 加密，在 PKI 體系 一節中講了簽名是伺服器信息摘要的哈希值加密生成的

內置 ECDSA 公鑰的證書一般被稱之為 ECC 證書，內置 RSA 公鑰的證書就是 RSA 證書。因為 256 位 ECC Key 在安全性上等同於 3072 位 RSA Key，所以 ECC 證書體積比 RSA 證書小，而且 ECC 運算速度更快，ECDHE 密鑰交換 + ECDSA 數字簽名是目前最好的加密套件

以上內容來自本文: 開始使用 ECC 證書

關於 ECC 證書的更多細節可見文檔: ECC Cipher Suites for TLS - RFC4492

使用 RSA 進行密鑰交換的握手過程與前面說明的基本一致，只是沒有 ServerKeyExchange 消息，其中協商密鑰涉及到三個參數 (客戶端隨機數 random_C、服務端隨機數 random_S、預主密鑰 Premaster secret)，
其中前兩個隨機數和協商使用的演算法是明文的很容易獲取，最後一個 Premaster secret 會用伺服器提供的公鑰加密後傳輸給伺服器 (密鑰交換)，如果這個預主密鑰被截取並破解則協商密鑰也可以被破解。

RSA 演算法的細節見: wiki 和 RSA演算法原理（二）- 阮一峰

RSA 的演算法核心思想是利用了極大整數 因數分解 的計算復雜性

而使用 DH(Diffie-Hellman) 演算法 進行密鑰交換，雙方只要交換各自的 DH 參數(在 ServerKeyExchange 發送 Server params，在 ClientKeyExchange 發送 Client params)，不需要傳遞 Premaster secret，就可以各自算出這個預主密鑰

DH 的握手過程如下，大致過程與 RSA 類似，圖中只表達如何生成預主密鑰:

伺服器通過私鑰將客戶端隨機數 random_C，服務端隨機數 random_S，服務端 DH 參數 Server params 簽名生成 signature，然後在 ServerKeyExchange 消息中發送服務端 DH 參數和該簽名；

客戶端收到後用伺服器給的公鑰解密驗證簽名，並在 ClientKeyExchange 消息中發送客戶端 DH 參數 Client params；

服務端收到後，雙方都有這兩個參數，再各自使用這兩個參數生成預主密鑰 Premaster secret，之後的協商密鑰等步驟與 RSA 基本一致。

關於 DH 演算法如何生成預主密鑰，推薦看下 Wiki 和 Ephemeral Diffie-Hellman handshake

其核心思想是利用了 離散對數問題 的計算復雜性

演算法過程可以抽象成下圖:

雙方預先商定好了一對 P g 值 (公開的)，而 Alice 有一個私密數 a(非公開，對應一個私鑰)，Bob 有一個私密數 b(非公開，對應一個私鑰)

對於 Alice 和 Bob 來說通過對方發過來的公鑰參數和自己手中的私鑰可以得到最終相同的密鑰

而第三方最多知道 P g A B，想得到私鑰和最後的密鑰很困難，當然前提是 a b P 足夠大 (RFC3526 文檔中有幾個常用的大素數可供使用)，否則暴力破解也有可能試出答案，至於 g 一般取個較小值就可以

如下幾張圖是實際 DH 握手發送的內容:

可以看到雙方發給對方的參數中攜帶了一個公鑰值，對應上述的 A 和 B

而且實際用的加密套件是 橢圓曲線 DH 密鑰交換 (ECDH) ，利用由橢圓曲線加密建立公鑰與私鑰對可以更進一步加強 DH 的安全性，因為目前解決橢圓曲線離散對數問題要比因式分解困難的多，而且 ECC 使用的密鑰長度比 RSA 密鑰短得多(目前 RSA 密鑰需要 2048 位以上才能保證安全，而 ECC 密鑰 256 位就足夠)

關於 橢圓曲線密碼學 - ECC ，推薦看下 A Primer on Elliptic Curve Cryptography - 原文 - 譯文

盡管可以選擇對任意一端進行身份驗證，但人們幾乎都啟用了對伺服器的身份驗證。如果伺服器選擇的套件不是匿名的，那麼就需要在 Certificate 消息中跟上自己的證書。

相比之下，伺服器通過發送 CertificateRequest 消息請求對客戶端進行身份驗證。消息中列出所有可接受的客戶端證書。作為響應，客戶端發送自己的 Certificate 消息（使用與伺服器發送證書相同的格式），並附上證書。此後，客戶端發送 CertificateVerify 消息，證明自己擁有對應的私鑰。

只有已經過身份驗證的伺服器才被允許請求客戶端身份驗證。基於這個原因，這個選項也被稱為相互身份驗證（mutual authentication）。

在 ServerHello 的過程中發出，請求對客戶端進行身份驗證，並將其接受的證書的公鑰和簽名演算法傳送給客戶端。

它也可以選擇發送一份自己接受的證書頒發機構列表，這些機構都用其可分辨名稱來表示:

在 ClientKeyExchange 的過程中發出，證明自己擁有的私鑰與之前發送的客戶端證書中的公鑰匹配。消息中包含一條到這一步為止的所有握手消息的簽名：

最初的會話恢復機制是，在一次完整協商的連接斷開時，客戶端和伺服器都會將會話的安全參數保存一段時間。希望使用會話恢復的伺服器為會話指定唯一的標識，稱為會話 ID(Session ID)。伺服器在 ServerHello 消息中將會話 ID 發回客戶端。

希望恢復早先會話的客戶端將適當的 Session ID 放入 ClientHello 消息，然後提交。伺服器如果同意恢復會話，就將相同的 Session ID 放入 ServerHello 消息返回，接著使用之前協商的主密鑰生成一套新的密鑰，再切換到加密模式，發送 Finished 消息。
客戶端收到會話已恢復的消息以後，也進行相同的操作。這樣的結果是握手只需要一次網路往返。

Session ID 由伺服器端支持，協議中的標准欄位，因此基本所有伺服器都支持，伺服器端保存會話 ID 以及協商的通信信息，佔用伺服器資源較多。

用來替代伺服器會話緩存和恢復的方案是使用會話票證（Session ticket）。使用這種方式，除了所有的狀態都保存在客戶端（與 HTTP Cookie 的原理類似）之外，其消息流與伺服器會話緩存是一樣的。

其思想是伺服器取出它的所有會話數據（狀態）並進行加密 (密鑰只有伺服器知道)，再以票證的方式發回客戶端。在接下來的連接中，客戶端恢復會話時在 ClientHello 的擴展欄位 session_ticket 中攜帶加密信息將票證提交回伺服器，由伺服器檢查票證的完整性，解密其內容，再使用其中的信息恢復會話。

這種方法有可能使擴展伺服器集群更為簡單，因為如果不使用這種方式，就需要在服務集群的各個節點之間同步會話。
Session ticket 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。

J. 什麼是SSL加密，什麼是TLS加密

SSL加密是Netscape公司所提出的安全保密協議，在瀏覽器和Web伺服器之間構造安全通道來進行數據傳輸，SSL運行在TCP/IP層之上、應用層之下，為應用程序提供加密數據通道，它採用了RC4、MD5以及RSA等加密演算法，使用40 位的密鑰，適用於商業信息的加密。

TLS是安全傳輸層協議。安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議上面。

(10)tls加密技術屬於hash擴展閱讀：

SSL加密並不保護數據中心本身，而是確保了SSL加密設備的數據中心安全，可以監控企業中來往於數據中心的最終用戶流量。

從某個角度來看，數據中心管理員可以放心將加密裝置放在某個地方，需要使用時再進行應用，數據中心應該會有更合理的方法來應對利用SSL的惡意攻擊，需要找到SSL加密應用的最佳實踐。

TLS協議是可選的，必須配置客戶端和伺服器才能使用。主要有兩種方式實現這一目標：一個是使用統一的TLS協議通信埠（例如：用於HTTPS的埠443）。另一個是客戶端請求伺服器連接到TLS時使用特定的協議機制（例如：郵件、新聞協議和STARTTLS）。

一旦客戶端和伺服器都同意使用TLS協議，他們通過使用一個握手過程協商出一個有狀態的連接以傳輸數據。通過握手，客戶端和伺服器協商各種參數用於創建安全連接。

參考資料來源：網路-SSL加密技術

參考資料來源：網路-TLS