HTTPS的安全性

1、Https介紹

1. 什麼是Https

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

2. Https的做用

• 內容加密 創建一個信息安全通道，來保證數據傳輸的安全；
• 身份驗證 確認網站的真實性；
• 數據完整性 防止內容被第三方冒充或者篡改

3. Https的劣勢

對數據進行加密決定了它比http慢

須要進行非對稱的加解密，且須要三次握手。首次鏈接比較慢，固然如今也有不少的優化。
出於安全考慮，瀏覽器不會在本地保存HTTPS緩存。實際上，只要在HTTP頭中使用特定命令，HTTPS是能夠緩存的。Firefox默認只在內存中緩存HTTPS。可是，只要頭命令中有Cache-Control: Public，緩存就會被寫到硬盤上。IE只要http頭容許就能夠緩存https內容，緩存策略與是否使用HTTPS協議無關。

4. HTTPS和HTTP的區別

• https協議須要到CA申請證書
• http是超文本傳輸協議，信息時明文傳輸；https則是具備安全性的ssl加密傳輸協議
• http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443
• http的鏈接很簡單，是無狀態的；https協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全
  下面就是https的整個構架，如今的https基本都使用TLS了，由於更加安全，因此下圖中SSL應該換成SSL/TLS。

 

下面就上圖中的知識點進行一個大概的介紹。

2、加解密相關知識

1. 對稱加密

對稱加密（也叫私鑰加密）指加密和解密使用相同密鑰的加密算法。有時又叫傳統密碼算法，就是加密密鑰可以從解密密鑰中推算出來，同時解密密鑰也能夠從加密密鑰中推算出來。而在大多數的對稱算法中，加密祕鑰和解密密鑰是相同的，因此也稱這種加密算法爲祕密密鑰算法或者單密鑰算法。
常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC四、IDEA

2. 非對稱加密

與對稱加密算法不一樣，非對稱加密算法須要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）；而且加密密鑰和解密密鑰是成對出現的。非對稱加密算法在加密和解密過程使用了不一樣的密鑰，非對稱加密也稱爲公鑰加密，在密鑰對中，其中一個密鑰是對外公開的，全部人均可以獲取到，稱爲公鑰，另外一個密鑰是不公開的稱爲私鑰。

非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。好比如今經常使用的公鑰長度是2048位，意味着加密內容不能超過256個字節。

3. 摘要算法

數字摘要是採用單項Hash函數將須要加密的明文「摘要」成一串固定長度（128位）的密文，這一串密文又稱爲數字指紋，它有固定的長度，並且不一樣的明文摘要成密文，其結果老是不一樣的，而一樣的明文其摘要一定一致。「數字摘要」是https能確保數據完整性和防篡改的根本緣由。

4. 數字簽名

數字簽名技術就和對「非對稱密鑰加解密」和「數字摘要」兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一塊兒傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，而後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。若是相同，則說明收到的信息是完整的，在傳輸過程當中沒有被修改，不然說明信息被修改過，所以數字簽名可以驗證信息的完整性。

數字簽名的過程以下：
明文 ——> hash算法 ——> 摘要 ——> 私鑰加密 ——> 數字簽名

數字簽名有兩種功效：
1、能肯定消息確實是由發送方簽名併發出來的，由於別人假冒不了發送方的簽名。
2、數字簽名能肯定消息的完整性。

注意：
數字簽名只能驗證數據的完整性，數據自己是否加密不屬於數字簽名的控制範圍

5. 數字證書

1）爲何要有數字證書？

對於請求方來講，它怎麼能肯定它所獲得的公鑰必定是從目標主機那裏發佈的，並且沒有篡改過呢？亦或這請求的目標主機自己就從事竊取用戶信息的不正當行爲呢？這時候，咱們須要有一個權威的值得信賴的第三方機構（通常由政府審覈並受權的機構）來統一對外發放主機機構的公鑰，只要請求方這種機構獲取公鑰，就避免了上述問題的發生。

2）數字證書的頒發過程

用戶首先產生本身的密鑰對，並將公鑰及部分我的身份信息傳送給認證中心。認證中心在覈實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，而後認證中心將發給用戶一個數字證書，該證書包含用戶的我的信息和他的公鑰信息，同時還附有認證中心的簽名信息（根證書私鑰簽名）。用戶就可使用該證書進行相關的各類活動。數字證書由獨立的證書頒發機構發佈，數字證書各不相同，每種證書可提供不一樣級別的可信度。

3）證書包含哪些內容

• 證書頒發機構的名稱
• 證書自己的數字簽名
• 證書持有者公鑰
• 證書籤名用到的Hash算法（轉載者理解：原文轉摘要用到，參見下面驗證證書的有效性第3條）

4）驗證證書的有效性

瀏覽器默認都會內置CA根證書，其中根證書包含了CA的公鑰

1. 證書頒發的機構是僞造的：瀏覽器不認識，直接認爲是危險證書
2. 證書頒發的機構確實存在，因而根據CA名，找到對應內置的CA根證書、CA的公鑰。用CA的公鑰，對僞造的證書的摘要進行解密，發現解不了，認爲是危險證書。
3. 對於篡改的證書，是用CA的公鑰對數字簽名進行解密獲得摘要A，而後再根據簽名的HASH算法計算出證書的摘要B，對比A與B，若相等則正常，不然就是被篡改過的。
4. 證書可在其過時前被吊銷，一般狀況是該證書的私鑰已經失密。較新的瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實現了在線證書狀態協議（OCSP）以排除這種狀況：瀏覽器將網站提供的證書的序列號經過OCSP發送給證書頒發機構，後者會告訴瀏覽器證書是否仍是有效的。

3、SSL與TLS

1. SSL（Secure Socket Layer，安全套接字層）

SSL爲Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密技術，可確保數據在網絡上傳輸過程當中不會被截取，當前爲3.0版本。

SSL協議可分爲兩層：SSL記錄協議（SSL Recore Protocol）：它創建在可靠地傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議（SSL Handshake Protocol）：它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

2. TLS（Transport Layer Security，傳輸層安全協議）

用於兩個應用程序之間提供保密性和數據完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它創建在SSL 3.0協議規範之上，是SSL 3.0的後續版本，能夠理解爲SSL 3.1，它是寫入了RFC的。該協議由兩層組成：TLS記錄協議（TLS Recore）和TLS握手協議（TLS Handshake）。較低的層爲TLS記錄協議，位於某個可靠的傳輸協議（例如TCP）上面。

3. SSL/TLS協議做用：

• 認證用戶和服務器，確保數據發送到正確的客戶機和服務器；（意思是HTTP的可能會發送到不正確的客戶機和服務器）
• 加密數據以防止數據中途被竊取；
• 維護數據的完整性，確保數據在傳輸過程當中不被改變。

4. TLS比SSL的優點

1. 對於消息認證使用密鑰散列法：TLS使用「消息認證代碼的密鑰散列法」（HMAC），當記錄在開放的網絡（如因特網）上傳送時，該代碼確保記錄不會被變動。SSLv3.0使用的是鍵控消息認證（MAC），但HMAC比MAC功能更安全。

2. 加強的僞隨機功能（PRF）：PRF生成密鑰數據。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。若是任一算法暴露了，只要第二種算法未暴露，則數據仍然是安全的。

3. 改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變動。然而，TLS將此已完成消息基於PRF和HMAC值之上，這也比SSLv3.0更安全。

4. 一致證書處理：與SSLv3.0不一樣，TLS試圖指定必須在TLS之間實現交換的證書類型。

5. 特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對什麼時候應該發送某些警報進行記錄。

5. SSL、TLS的握手過程

SSL與TLS握手整個過程以下圖所示，下面會詳細介紹每一步的具體內容：

1）客戶端首次發出請求

因爲客戶端（如瀏覽器）對一些加密算法的支持程度不同，但在TLS協議傳輸過程當中必須使用同一套加解密算法才能保證數據可以正常的加解密。在TLS握手階段，客戶端首先要告知服務器端，本身支持哪些加密算法，因此客戶端須要將本地支持的加密套件（Cipher Suite）的列表傳送給服務端。除此以外，客戶端還要產生一個隨機數，這個隨機數一方面須要在客戶端保存，另外一方面須要傳送給服務端，客戶端的隨機數須要跟服務端產生的隨機數結合起來產生後邊要講的Master Secret。

客戶端須要提供以下信息：

• 支持的協議版本，好比TLS 1.0版本
• 一個客戶端生成的隨機數，稍後用於生成「對話密鑰」
• 支持的加密方法，好比RSA公鑰加密
• 支持的壓縮方法

2）服務端首次迴應

服務端在接收到客戶端的Client Hello以後，服務端須要肯定加密協議的版本，以及加密的算法，而後也生成一個隨機數，以及將本身的證書發送給客戶端，這裏的隨機數是整個過程的第二個隨機數。

服務端須要提供的信息：

• 協議的版本
• 加密的算法
• 隨機數
• 服務器證書

 

3）客戶端再次迴應

客戶端首先會對服務器下發的證書進行驗證，驗證經過後，則會繼續下面的操做，客戶端再次產生一個隨機數（第三個隨機數），而後使用服務器證書中的公鑰加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面全部消息的hash值，進行服務器驗證，而後用新密鑰（轉載者的理解：使用第二次握手後服務器端返回的支持的加密算法隨機生成的對稱密鑰）加密一段數據一併發送到服務器，確保正式通訊前無誤。
客戶端使用前面的兩個隨機數以及剛剛生成的新隨機數，使用與服務器肯定的加密算法，生成一個Session Secret。

ChangeCipherSpec是一個獨立的協議，體如今數據包中就是一個字節的數據，用於告知服務端，客戶端已經切換到以前協商好的加密套件（Cipher Suite）的狀態，準備使用以前協商好的加密套件加密數據並傳輸了。

4）服務器再次響應

服務端在接收到客戶端傳過來的第三個隨機數的加密數據後，使用私鑰對解密這段加密數據，並對數據進行驗證，也會使用和客戶端一樣的方式生成密鑰。一切準備好後，也會給客戶端發送一個ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，準備使用加密套件和Session Secret加密數據了。以後，服務端也會使用Session Secret加密一段Finish消息發送給客戶端，以驗證以前經過握手創建起來的加解密通道是否成功。

轉載者疑問：這裏的Session Secret是否是就是對稱密鑰？
會話密鑰：https://baike.baidu.com/item/%E4%BC%9A%E8%AF%9D%E5%AF%86%E9%92%A5/8831495?fr=aladdin

5）後續客戶端與服務期間通訊

肯定密鑰後，服務器與客戶端之間就會經過商定的密鑰加密數據，進行通信了。這個握手過程也就基本完成了。

6. 其餘補充

對於很是重要的保密數據，服務端還須要對客戶端進行驗證，以保證數據傳送給了安全的合法客戶端。服務端能夠向客戶端發出Cerficate Request消息，要求客戶端發送證書對客戶端的合法性進行驗證。好比，金融機構每每只容許認證客戶連入本身的網絡，就會向正式客戶提供USB密鑰，裏面就包含了一張客戶端證書。

PreMaster Secret前兩個字節是TLS的版本號，這是一個比較重要的用來覈對握手數據的版本號，由於在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，並且是使用明文傳送的，若是握手的數據包被破解以後，攻擊者頗有可能篡改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。因此，服務端須要對密文中解密出來的PreMaster版本號跟以前Client Hello階段的版本號進行對比，若是版本號變低，則說明被篡改，則當即中止發送任何消息。

session的恢復

有兩種方法能夠恢復原來的session：一種叫作session ID，另外一種叫作session ticket。

1）session ID

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。若是對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就能夠從新使用已有的「對話密鑰」，而沒必要從新生成一把。

session ID是目前全部瀏覽器都支持的方法，可是它的缺點在於session ID每每只保留在一臺服務器上。因此，若是客戶端的請求發送到另外一臺服務器，就沒法恢復對話。

2）session ticket

客戶端發送一個服務器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有服務器才能解密，其中包括本次對話的主要信息，好比對話密鑰和加密方法。當服務器收到session ticket之後，解密後就沒必要從新生成對話密鑰了。

目前只有Firefox和Chrome瀏覽器支持。

總結

https實際上就是在TCP層與http層之間加入了SSL/TLS來爲上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書等技術進行客戶端與服務器的數據加密傳輸，最終達到保證整個通訊的安全性。