https的那些事

以前看了一些網上關於https的文章，感受都講的不夠完善，整篇看下來仍是以爲有幾個疑問點，最近學習了極客時間《透視HTTP協議》，稍微能摸清楚https的工做，寫一寫增強印象。

什麼是安全

一般認爲，通訊過程具有了如下4個特性，能夠認爲安全：機密性，完整性，身份認證，不能否認。

• 機密性
  指數據保密的，只有通訊的對方能知道數據的內容，數據對其餘方是不可見的
• 完整性
  機密性雖然保證了數據不可被竊取，可是不能防止被篡改，若是通訊過程數據直接被調包或者被修改，那麼也是不安全的
• 身份驗證
  指能確認對方的身份，保證「我」在和「你」在通訊而不是「他」，沒有身份驗證，通訊的是「他」，那麼再怎麼機密的數據也是白搭
• 不能否認
  「我」經過只有「你」知道的事情迴應「你」，那麼「你」就是正確的「你」

什麼是HTTPS

HTTPS是運行在SSL/TLS上的HTTP，只要弄懂了SSL/TSL就弄懂了HTTPS，而SSL/TLS是在OSI模型中處於第5層會話層中，目前運用最普遍的TLS是v1.2版本，最新的v1.3兼容了v1.2，且強大了不少。
TLS由記錄協議，握手協議，警告協議，變動密碼協議，擴展協議等幾個子協議組成，綜合使用了對稱加密，非對稱加密，身份驗證等多個前沿密碼學技術。

加密

對稱加密

安全的第1個特性是機密性，那麼實現機密性最經常使用的手段就是對數據進行「加密」，把數據經過某種形式轉化爲誰都看不懂的亂碼，只有特定的「鑰匙」的人才能解密數據。加密能夠分爲兩大類：對稱加密和非對稱加密。

對稱加密的加密和解密的密鑰都是同一個，因此是「對稱」的，只要保證了密鑰只有通訊雙方持有，那麼整個通訊過程就具備了機密性。
目前最經常使用的對稱加密算法是AES（advanced encryption standard），安全強度高，性能也很好，因此最流行。

分組模式

對稱加密還有個分組模式的概念，他可讓加密算法用固定長度的密鑰加密任意長度的明文，即小祕密轉化爲大祕密，將明文按照必定的規則切分，而後分別對明文片斷進行加密，再整合成一塊兒。如今最多見的分組模式是GCM/CCM/Poly1305，

非對稱加密

對稱加密最大的問題就是如何讓通訊兩方都知道一個密鑰，總不能爲了傳輸這個密鑰再用另外一個密鑰進行加密吧，那就是「雞生蛋，蛋生雞」的問題沒完沒了了。
因此非對稱加密就出來了。它有兩個密鑰，一個是「公鑰」，一個是「私鑰」，兩個密鑰不一樣，因此「不對稱」，私鑰必須嚴格保密，公鑰能夠公開給任何人使用。
這裏有個特別的「單向性」，公鑰加密的數據只能夠用私鑰解密，反之私鑰加密的數據只能夠用公鑰解密，常見算法有RSA/ECC。

RSA

在TLS1.2版本里最經常使用的非對稱加密算法，因爲不具備「向前安全」，因此在1.3版本中被棄用了。

ECC

是非對稱加密算法的後起之秀，他基於「橢圓曲線離散對數」的數學難題，用特定的曲線方程和基點生成一個公鑰和一個私鑰。子算法ECDHE用於密鑰交換，ECDSA用於數字簽名。

混合加密

爲何TLS不直接使用非對稱加密呢

1. 由於非對稱加密和解密的過程比對稱加密慢太多，致使在通訊的過程中須要很是長的時間，通訊龜速，實用性爲0，RSA2048的加解密大約是15KB/s，而AES128則是13MB/s,相差了差很少一千倍。
2. 因爲公鑰是公開的，那麼客戶端的數據被竊取修改，第三方同樣能夠用公鑰加密篡改後的數據，因此要用非對稱加密進行通訊，客戶端須要驗證服務端的身份的同時，服務端也須要驗證客戶端的身份，這是不現實的，要海量的客戶端的身份談何容易。

因此TLS只是用非對稱加密算法讓雙方得到一個對稱加密算法的密鑰，後續的通訊使用該密鑰進行。

數字簽名和證書

雖然有了機密性，可是離安全還差很遠
黑客雖然拿不到密鑰，可是能夠經過竊聽收集足夠多的密文，嘗試修改/重組後發給服務器，由於沒有完整性檢查，服務器正常返回，黑客能夠經過服務器的響應獲取進一步線索，最終破解密鑰。
另外，黑客也能夠僞造公鑰發佈，若是客戶端拿到了假的公鑰匙，那麼再怎麼加密都沒有用了，被黑客直接攔截，直接裸奔。。

摘要

實現完整性的手段主要是摘要算法，摘要意思就是原文的總結，歸納，一個原文經過一種摘要算法只有一個摘要，因此摘要能夠認爲是原文的「指紋」，MD5和SHA-1是以前常見的摘要算法，可是因爲安全性不足，被棄用了，如今經常使用的是SHA-2。

數字簽名

現實生活中解決身份認證的常見的有蓋章，簽名。一樣的，在通訊中要想實現身份認證，首先得有個惟一的東西只要你擁有——那就是非對稱加密中的私鑰。使用私鑰加密摘要，就可以實現數字簽名，實現了身份認證的同時也實現了不能否認。

數字證書和CA

綜合上述，咱們已經實現了安全的4大特性，是否是ok了？
不是。
這樣還有公鑰的信任，由於誰均可以發佈公鑰，咱們怎麼證實這個公鑰就是通訊對方的公鑰呢？
只能引入「可信的第三方」，這個第三方就是咱們常說的CA，由他來給各個公鑰簽名，用自身的信譽作擔保，構建起公鑰的信任鏈。
CA對公鑰的簽名認證也是由必定格式的，包括序列號，用途，頒發者，有效時間，公鑰等等，再打一個包再簽名，造成一個數字證書。

HTTPS創建鏈接

圖上的每個直線表明的是一個記錄協議，多個記錄協議會在一個tcp包中一同送出。

ECDHE握手過程

1. 在tcp創建鏈接後，瀏覽器會先發一個client hello，包含由TLS支持的版本號，支持的密碼套件，還有一個隨機數client random，用於後續生成會話密鑰。
2. 服務端收到後，會返回一個server hello，包含肯定TLS版本號，選取其中一組密碼套件，好比TLS_ECHDHE_RSA_WITH_AES256_GCM_SHA384，意思是非對稱加密算法選取ECHDHE+RSA，對稱加密算法AES256，分組模式GCM，摘要加密算法SHA384，還有一個隨機數server random，這個一樣用於後續生成會話密鑰。
   而後，服務器發送證書，因爲服務器選擇的是橢圓曲線ECHDHE的加密算法，因此又發送來一個server key exchanges，裏面是橢圓曲線的公鑰server params，再加上本身的私鑰簽名，防止server params被篡改。
3. 客戶端拿到了服務端的響應，這時開始驗證服務端發送過來的證書是否可信，開始走證書鏈逐級驗證：
   證書是被CA簽名了的，因此此時根據該證書的頒發者，拿到頒發者的公鑰，解密出摘要，再根據摘要算法對證書內容進行摘要計算，若是計算結果跟證書上的摘要一致，則驗證了完整性和不能否認。若是該頒發者不是1級CA，那麼須要驗證該頒發者的身份，根據上述一樣的操做驗證頒發者的證書，直到根級證書。若是在此過程都驗證正確，那麼該頒發者可信，從而該服務器的證書可信，達到身份驗證。
   驗證完成後，客戶端根據服務器證書上的公鑰，解密出server key exchange的摘要，確認無誤後，獲得了server params。而後客戶端按照密碼套件，也生成了一個橢圓曲線的公鑰(client params)和私鑰，用client key exchange發送client params給服務端。
4. 如今兩方都有橢圓曲線本身的私鑰和對方的公鑰，生成一個叫作pre-master的隨機數，神奇的算法讓雙發生成的隨機數是一致的，因爲私鑰並無在通訊中公開，因此pre-master也沒有在通訊中公開，因此這個隨機數在本次通訊中只要雙發知道。
5. 雙方根據client random , server random, pre-master三個隨機數計算獲得master secret，這個就是用於後面通訊的對稱密鑰。

6. 客戶端發送一個change cipher spec和finished。再將以前發送的全部數據作個摘要，再用密鑰加密一下，讓服務器驗證一下。

   • 這裏客戶端能夠立刻進行https的通訊，就是搶跑，無需等待服務器的迴應，由於雙方都已經在以前的握手中肯定能夠知道主密鑰了。減小0.5個rtt。
7. 服務器驗證完成後，發送一個change cipher spec和finished，以後的通訊就開始密文交流。

RSA握手過程

大致流程跟上述一致，只是pre-master再也不經過算法生成，而是客戶端直接生成隨機數，而後用服務器的公鑰加密，經過發送一個client key exchange發送給服務器，那此時雙方也實現了共享3個隨機參數。