tls加密後數據包變大

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

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

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

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

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

(1)tls加密後數據包變大擴展閱讀：

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安全傳輸層

B. TLS協議的TLS握手協議

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

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

C. tls是否具有防重放攻擊機制，如何解決經過tls傳輸的數據的有效性檢測

tls具有防重放攻擊機制。

1. 加密，時間戳，每個包要有包序號，每次同向加1，收到重復序號認為是攻擊，可以抵禦重放攻擊。此外藉助於HTTPS/TLS其自身機制，保證了消息完整性，並且可以抵禦重放攻擊。由於加密，對方也無法看到明文內容。

2. 客戶端生成一串隨機數R1，發給伺服器，伺服器判斷此R1是否重復，之後根據演算法(R1+R2)生成密鑰。最好是結合驗簽機制。

3. https 會被中間人攻擊，Fiddler 能用替換證書的方式截獲並還原明文。非對稱加密（例如RSA）是個好辦法，不過得防止別人。

D. SSL/TLS協議解析

本文藉助wireshark抓包詳細的講解SSL/TLS協議。HTTPS是為了解決http報文明文傳輸過程中的安全問題。HTTPS是「HTTP over SSL」的縮寫。所以要了解HTTPS就必須先了解SSL/TLS協議。

HTTP協議中所有消息都是明文傳播，存在如下三大風險

為了解決這個三個風險，分別對應如下三個解決方案。

由於SSL的2個版本都已經退出歷史舞台了，所以本文後面只用TLS這個名字。 一般所說的SSL就是TLS。

TLS建立連接的過程如下圖，先有個大概的印象，後面我們再詳細分析。整個需要四次握手。

SSL/TLS工作在應用層和傳輸層之間 ，在建立連接的之前需要先建立TCP連接（三次握手），如下圖。

記錄協議根據rfc描述 記錄協議（Record Layer） 有如下4種類型，即上圖中Content Type可以取的值。

記錄協議（Record Layer） 數據結構

握手協議（Handshake Protocal） 有如下10種類型。

握手協議（Handshake Protocal） 數據結構

wireshark抓包顯示客戶端支持的加密套件有31種。 cipher的格式為：認證演算法 密鑰交換演算法 加密演算法_ 摘要演算法 。server會從這些演算法組合中選取一組，作為本次SSL連接中使用。

這個包告訴我們伺服器和客戶端是通過Diffie-Hellman演算法來生成最終的密鑰（也就是Sessionkey會話密鑰），pubkey是Diffie-Hellman演算法中的一個參數，這個參數需要通過網路傳給客戶端，即使它被截取也不會影響安全性。具體見參考文獻三。
在client hello和server hello包中都有Random欄位，上面我們是沒有說明的，client和server這兩個隨機數加Diffie-Hellman演算法生成出來的這個key。一共三個數字生成最終對稱加密的key

從現在開始發送的數據就是採用上述步驟協商出的對稱加密密鑰加密過的數據了

再回過頭來看一下這張圖，加密過程總結如下：

E. 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 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。

F. HTTPS 到底加密了些什麼內容

https其實是有兩部分組成：http + SSL / TLS，也就是在http上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密後的數據。具體是如何進行加密，解密，驗證的，且看下圖。

1. 客戶端發起https請求

客戶端發起https請求就是指用戶在瀏覽器里輸入一個https網址，然後連接到server的443埠。

2. 伺服器端的配置

採用https協議的伺服器必須要有一套SSL數字證書，需要向CA組織(如WoSign沃通CA)申請。這套SSL證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想像成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，證書過期時間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5. 傳送加密信息

這部分傳送的是用SSL證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務段解密信息

服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠復雜，數據就夠安全。

7. 傳輸加密後的信息

這部分信息是服務段用私鑰加密後的信息，可以在客戶端被還原。

8. 客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，於是獲取了解密後的內容。整個過程第三方即使監聽到了數據，也束手無策。

G. 深入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協議詳解與抓包實戰--陶輝

H. 【opensips】使用tls加密後的sip流如何通過wireshark查看

使用tls加密sip後，所有的sip都是密文，所以即使抓包，也無法查看到sip信令流。

實際上如果有tls伺服器端certificate的private key的話，是可以把tls的sip流解密的。

選擇 wireshark首先項，在prototols中選擇TLS（有的版本是SSL）
選擇 RSA keys list 彈出第二頁配置窗

配置tls 的private key

整個pcap包里有兩個IP，一個是server ip（這里是private IP），一個是client IP。

I. HTTP，SSL/TLS和HTTPS協議的區別與聯系

概述：HTTP是普通明文傳輸協議，HTTPS是加密協議，相當於HTTP的安全版本，但需要HTTPS加密必須擁有SSL證書與TLS協議交流產生，SSL證書在線簽發：網頁鏈接

1、「HTTP」是什麼？

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網路協議，所有的WWW文件都必須遵守這個標准，設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法（具體可查看馬海祥博客《深入解析互聯網協議的原理》的相關介紹）。

1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法，並稱之為超文本（hypertext），這成為了HTTP超文本傳輸協議標准架構的發展根基。

簡單來說，HTTP就是一個網路協議，是專門用來幫你傳輸Web內容的，關於這個協議，就算你不了解，至少也聽說過吧？比如你訪問我的博客的主頁，瀏覽器地址欄會出現的網址：http://www.mahaixiang.cn，大部分網站都是通過HTTP協議來傳輸Web頁面、以及Web頁面上包含的各種東東（圖片、CSS 樣式、JS 腳本）。

2、「SSL/TLS」是什麼？

SSL是「Secure Sockets Layer」的縮寫，中文叫做「安全套接層」，它是在上世紀90年代中期，由網景公司設計的（順便插一句，網景公司不光發明了 SSL，還發明了很多 Web 的基礎設施——比如「CSS 樣式表」和「JS 腳本」）。

為啥要發明SSL這個協議捏？因為原先互聯網上使用的HTTP協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改，發明SSL協議，就是為了解決這些問題。

到了1999年，SSL因為應用廣泛，已經成為互聯網上的事實標准，IETF就在那年把SSL標准化，標准化之後的名稱改為TLS（是「Transport Layer Security」的縮寫），中文叫做「傳輸層安全協議」。

很多相關的文章都把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。

3、「HTTPS」是什麼意思？

解釋完 HTTP 和 SSL/TLS，現在就可以來解釋 HTTPS 啦，咱們通常所說的 HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合，你可以把 HTTPS 大致理解為——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差不多）。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

它是一個URI scheme（抽象標識符體系），句法類同http:體系，用於安全的HTTP數據傳輸。

https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的默認埠及一個加密/身份驗證層（在HTTP與TCP之間），這個系統的最初研發由網景公司(Netscape)進行，並內置於其瀏覽器Netscape Navigator中，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。

4、談談「對稱加密」和「非對稱加密」的概念

如果我們想搞明白「對稱加密」和「非對稱加密」的概念，首先，我們就要先知道什麼是「加密」和「解密」？

（1）、什麼是「加密」和「解密」？

通俗而言，你可以把「加密」和「解密」理解為某種互逆的數學運算，就好比「加法和減法」互為逆運算、「乘法和除法」互為逆運算。

「加密」的過程，就是把「明文」變成「密文」的過程；反之，「解密」的過程，就是把「密文」變為「明文」，在這兩個過程中，都需要一個關鍵的東東——叫做「密鑰」——來參與數學運算。

（2）、什麼是「對稱加密」？

所謂的「對稱加密技術」，意思就是說：「加密」和「解密」使用相同的密鑰。這個比較好理解，就好比你用 7zip 或 WinRAR 創建一個帶密碼（口令）的加密壓縮包，當你下次要把這個壓縮文件解開的時候，你需要輸入同樣的密碼，在這個例子中，密碼/口令就如同剛才說的「密鑰」。

對稱加密是最快速、最簡單的一種加密方式，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key），這種方法在密碼學中叫做對稱加密演算法，對稱加密有很多種演算法，由於它效率很高，所以被廣泛使用在很多加密協議的核心當中。

（3）、什麼是「非對稱加密」？

所謂的「非對稱加密技術」，意思就是說：「加密」和「解密」使用不同的密鑰，這玩意兒比較難理解，也比較難想到，當年「非對稱加密」的發明，還被譽為「密碼學」歷史上的一次革命。

非對稱加密為數據的加密與解密提供了一個非常安全的方法，它使用了一對密鑰，公鑰（public key）和私鑰（private key），私鑰只能由一方安全保管，不能外泄，而公鑰則可以發給任何請求它的人，非對稱加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰。

由於篇幅有限，對「非對稱加密」這個話題，我就不展開了，有空的話，我會再單獨寫一篇文章在馬海祥博客上發布。

（4）、各自有啥優缺點？

看完剛才的定義，很顯然：（從功能角度而言）「非對稱加密」能乾的事情比「對稱加密」要多，這是「非對稱加密」的優點，但是「非對稱加密」的實現，通常需要涉及到「復雜數學問題」，所以，「非對稱加密」的性能通常要差很多（相對於「對稱加密」而言）。

這兩者的優缺點，也影響到了 SSL 協議的設計。

5、HTTP協議的特點

作為背景知識介紹，還需要再稍微談一下 HTTP 協議本身的特點，HTTP本身有很多特點，考慮到篇幅有限，馬海祥只談那些和HTTPS相關的特點，想要了解更深入的HTTP知識，可查看馬海祥博客《HTTP服務的七層架構技術解析及運用》的相關介紹。

（1）、HTTP的版本和歷史

如今咱們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1），這個 1.1 版本是1995年底開始起草的（技術文檔是RFC2068），並在1999年正式發布（技術文檔是RFC2616）。

在 1.1 之前，還有曾經出現過兩個版本「0.9 和 1.0」，其中的 HTTP 0.9 沒有被廣泛使用，而 HTTP 1.0 被廣泛使用過。

（2）、HTTP 和 TCP 之間的關系

簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議需要依靠 TCP 協議來傳輸數據。

在網路分層模型中，TCP 被稱為「傳輸層協議」，而 HTTP 被稱為「應用層協議」。

有很多常見的應用層協議是以 TCP 為基礎的，比如「FTP、SMTP、POP、IMAP」等。

TCP被稱為「面向連接」的傳輸層協議，關於它的具體細節，俺就不展開了（否則篇幅又失控了），你只需知道：傳輸層主要有兩個協議，分別是TCP和UDP，TCP比UDP更可靠，你可以把 TCP 協議想像成某個水管，發送端這頭進水，接收端那頭就出水，並且 TCP 協議能夠確保，先發送的數據先到達（與之相反，UDP不保證這點）。

（3）、HTTP協議如何使用 TCP 連接？

HTTP對 TCP 連接的使用，分為兩種方式：俗稱「短連接」和「長連接」（「長連接」又稱「持久連接」，叫做「Keep-Alive」或「Persistent Connection」）

假設有一個網頁，裡麵包含好多圖片，還包含好多外部的CSS文件和JS文件，在「短連接」的模式下，瀏覽器會先發起一個 TCP 連接，拿到該網頁的 HTML 源代碼（拿到 HTML 之後，這個 TCP 連接就關閉了）。然後，瀏覽器開始分析這個網頁的源碼，知道這個頁麵包含很多外部資源（圖片、CSS、JS）。然後針對每一個外部資源，再分別發起一個個 TCP 連接，把這些文件獲取到本地（同樣的，每抓取一個外部資源後，相應的 TCP 就斷開）。

相反，如果是「長連接」的方式，瀏覽器也會先發起一個 TCP 連接去抓取頁面，但是抓取頁面之後，該 TCP 連接並不會立即關閉，而是暫時先保持著（所謂的「Keep-Alive」），然後瀏覽器分析 HTML 源碼之後，發現有很多外部資源，就用剛才那個 TCP 連接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，默認使用的是「短連接」（那時候是 Web 誕生初期，網頁相對簡單，「短連接」的問題不大）。

到了1995年底開始制定 HTTP 1.1 草案的時候，網頁已經開始變得復雜（網頁內的圖片、腳本越來越多了），這時候再用短連接的方式，效率太低下了（因為建立 TCP 連接是有「時間成本」和「CPU成本」），所以，在 HTTP 1.1 中，默認採用的是「Keep-Alive」的方式。

6、SSL/TLS協議的基本運行過程

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向伺服器端索要公鑰，然後用公鑰加密信息，伺服器收到密文後，用自己的私鑰解密，但是這里有兩個問題：

（1）、如何保證公鑰不被篡改？

解決方法：將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。

（2）、公鑰加密計算量太大，如何減少耗用的時間？

解決方法：每一次對話（session），客戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密信息。由於"對話密鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協議的基本過程是這樣的：

（1）、客戶端向伺服器端索要並驗證公鑰。

（2）、雙方協商生成「對話密鑰」。

（3）、雙方採用「對話密鑰」進行加密通信。

7、SSL、HTTP和HTTPS協議的聯系

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

同時，Netscape公司相應開發了HTTPS協議並內置於其瀏覽器中，HTTPS實際上就是SSL over HTTP，它使用默認埠443，而不是像HTTP那樣使用埠80來和TCP/IP進行通信。HTTPS協議使用SSL在發送方把原始數據進行加密，然後在接受方進行解密，加密和解密需要發送方和接受方通過交換共知的密鑰來實現，因此，所傳送的數據不容易被網路黑客截獲和解密。

然而，加密和解密過程需要耗費系統大量的開銷，嚴重降低機器的性能，相關測試數據表明使用HTTPS協議傳輸數據的工作效率只有使用HTTP協議傳輸的十分之一。

假如為了安全保密，將一個網站所有的Web應用都啟用SSL技術來加密，並使用HTTPS協議進行傳輸，那麼該網站的性能和效率將會大大降低，而且沒有這個必要，因為一般來說並不是所有數據都要求那麼高的安全保密級別，所以，我們只需對那些涉及機密數據的交互處理使用HTTPS協議，這樣就做到魚與熊掌兼得（具體可查看馬海祥博客《從SEO的角度來分析網站是否該採用HTTPS協議》的相關介紹）。

總之不需要用https的地方，就盡量不要用。

8、HTTPS協議的需求是什麼？

花了好多口水，終於把背景知識說完了，下面正式進入正題，先來說說當初設計HTTPS是為了滿足哪些需求？

很多介紹 HTTPS 的文章一上來就給你講實現細節，對此，馬海祥覺得這是不好的做法，一上來就給你講協議細節，你充其量只能知道如何做，無法理解為什麼，我在前一個章節講了「背景知識」，在這個章節講了「需求」，這就有助於你理解了。

為什麼要設計成這樣？——這就是 WHY 型的問題。

（1）、兼容性

因為是先有 HTTP 再有 HTTPS，所以，HTTPS 的設計者肯定要考慮到對原有 HTTP 的兼容性。

這里所說的兼容性包括很多方面，比如已有的 Web 應用要盡可能無縫地遷移到 HTTPS；比如對瀏覽器廠商而言，改動要盡可能小。

基於「兼容性」方面的考慮，很容易得出如下幾個結論：

①、HTTPS還是要基於 TCP 來傳輸

如果改為 UDP 作傳輸層，無論是 Web 服務端還是瀏覽器客戶端，都要大改，動靜太大了。

②、單獨使用一個新的協議，把 HTTP 協議包裹起來

所謂的「HTTP over SSL」，實際上是在原有的 HTTP 數據外面加了一層 SSL 的封裝，HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動。

打個比方：如果原來的 HTTP 是塑料水管，容易被戳破；那麼如今新設計的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管，一來，原有的塑料水管照樣運行；二來，用金屬加固了之後，不容易被戳破。

（2）、可擴展性

前面說了，HTTPS 相當於是「HTTP over SSL」。

如果 SSL 這個協議在「可擴展性」方面的設計足夠牛逼，那麼它除了能跟 HTTP 搭配，還能夠跟其它的應用層協議搭配，豈不美哉？

現在看來，當初設計 SSL 的人確實比較牛，如今的 SSL/TLS 可以跟很多常用的應用層協議（比如：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協議的安全性。

接著剛才打的比方：如果把 SSL/TLS 視作一根用來加固的金屬管，它不僅可以用來加固輸水的管道，還可以用來加固輸煤氣的管道。

（3）、保密性（防泄密）

HTTPS需要做到足夠好的保密性。

說到保密性，首先要能夠對抗嗅探（行話叫 Sniffer），所謂的「嗅探」，通俗而言就是監視你的網路傳輸流量，如果你使用明文的 HTTP 上網，那麼監視者通過嗅探，就知道你在訪問哪些網站的哪些頁面。

嗅探是最低級的攻擊手法，除了嗅探，HTTPS 還需要能對抗其它一些稍微高級的攻擊手法——比如「重放攻擊」（後面講協議原理的時候，會再聊）。

（4）、完整性（防篡改）

除了「保密性」，還有一個同樣重要的目標是「確保完整性」。

在發明 HTTPS 之前，由於 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

舉個例子：比如咱們的網路運營商（ISP）都比較流氓，經常有網友抱怨說訪問某網站（本來是沒有廣告的），竟然會跳出很多中國電信的廣告，為啥會這樣呢？因為你的網路流量需要經過 ISP 的線路才能到達公網，如果你使用的是明文的 HTTP，ISP 很容易就可以在你訪問的頁面中植入廣告。

所以，當初設計 HTTPS 的時候，還有一個需求是「確保 HTTP 協議的內容不被篡改」。

（5）、真實性（防假冒）

在談到 HTTPS 的需求時，「真實性」經常被忽略，其實「真實性」的重要程度不亞於前面的「保密性」和「完整性」。

舉個例子：你因為使用網銀，需要訪問該網銀的 Web 站點，那麼，你如何確保你訪問的網站確實是你想訪問的網站？

有些天真的同學會說：通過看網址裡面的域名，來確保，為啥說這樣的同學是「天真的」？因為 DNS 系統本身是不可靠的（尤其是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明），由於 DNS 的不可靠（存在「域名欺騙」和「域名劫持」），你看到的網址裡面的域名未必是真實滴！

所以，HTTPS 協議必須有某種機制來確保「真實性」的需求（至於如何確保，後面會細聊）。

9、HTTPS和HTTP的區別

超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站伺服器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站伺服器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協議不適合傳輸一些敏感信息，比如信用卡號、密碼等。

為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS。

為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通信加密。

一般來說，HTTPS和HTTP的區別主要為以下四點：

（1）、https協議需要到ca申請證書，一般免費證書很少，需要交費。

（2）、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。

（3）、http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。

（4）、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全（具體可查看馬海祥博客《HTTP與HTTPS的區別》的相關介紹）。

10、HTTPS和HTTP的性能比較

再來說最後一個需求——性能。

本來簡單的http協議，一個get一個response，由於https要還密鑰和確認加密演算法的需要，單握手就需要6、7個往返，任何應用中，過多的round trip肯定影響性能，接下來才是具體的http協議，每一次響應或者請求，都要求客戶端和服務端對會話的內容做加密/解密。

盡管對稱加密/解密效率比較高，可是仍然要消耗過多的CPU，為此有專門的SSL晶元，如果CPU信能比較低的話，肯定會降低性能，從而不能serve更多的請求，加密後數據量的影響，所以，才會出現那麼多的安全認證提示（具體可查看馬海祥博客《HTTPS對網站性能優化的影響》的相關介紹）。

一般來說，引入HTTPS之後，不能導致性能變得太差，否則的話，誰還願意用？

為了確保性能，SSL 的設計者至少要考慮如下幾點：

（1）、如何選擇加密演算法（「對稱」or「非對稱」）？

（2）、如何兼顧 HTTP 採用的「短連接」TCP 方式？

SSL 是在1995年之前開始設計的，那時候的 HTTP 版本還是 1.0，默認使用的是「短連接」的 TCP 方式——默認不啟用 Keep-Alive。

HTTPS的關鍵性能影響是CPU和往返，如果CPU很強的話，性能可能就是有人講的80%；如果cpu是瓶頸的話，有人講原來可以server330-500個請求每秒，現在只有30-50%，因此在使用https請求數據的時候要注意看看你的項目裡面是否真的需要。

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

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

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

(10)tls加密後數據包變大擴展閱讀：

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

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

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

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

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

參考資料來源：網路-TLS