HTTPS中的對稱密鑰加密，公開密鑰加密，數(shù)字證書 密鑰

我們將未加密的內(nèi)容稱為明文，加密之后的內(nèi)容稱為密文。

簡單來說，要加密一段明文，可以將這段內(nèi)容輸入到一個加密函數(shù)中，輸出密文。但這種簡單的加密方式存在被人盜取到加密函數(shù)從而破解明文的危險，且加密函數(shù)一般構(gòu)成復雜，一旦被盜取更換成本較高。

于是人們想出了一個辦法，在加密函數(shù)中再添加一個參數(shù)，這個參數(shù)只有通信雙方知道，沒有參數(shù)則無法正確解密出明文。這個參數(shù)被稱為密鑰。對于同一個加密函數(shù)而言，密鑰值的不同則加密方式也不同，得出的密文也就不同。這樣加密系統(tǒng)的安全性提高了，被盜取密鑰之后更換密鑰的成本也低了很多。常見的情景是加密函數(shù)都是使用公開的算法，用戶需要保存的僅僅是自己的密鑰。

對稱密鑰加密

對稱密鑰加密就是加密與解密使用相同的是密鑰值。

流行的對稱密鑰加密包括：

DES TRiple-DES RC2 RC4

對稱密鑰需要通信雙方共享密鑰。對互聯(lián)網(wǎng)通信而言，不同的通信雙方需要不同的對稱密鑰，如果有N個用戶需要相互通信，總共需要密鑰數(shù)N*(N-1)。

公開密鑰加密

對稱密鑰加密存在需要密鑰數(shù)太多以及傳遞密鑰不方便的缺點，于是人們研究出非對稱的密鑰加密技術，即加密和解密的密鑰不需要一樣。常見的一種稱為公開密鑰加密。

公開密鑰加密將通信一端的加密和解密密鑰分成兩個，其中加密密鑰可以公開發(fā)布，也就是隨便誰都可以使用該加密密鑰為明文加密，但要解密這段密文只能靠該端私有的解密密鑰。這解決了對稱密鑰加密中的缺點。其中公開的加密密鑰稱為公開密鑰，私有的解密密鑰稱為私有密鑰。

要保證公開密鑰加密的可用性必須確保以下情況無法計算出私有密鑰：

有公開密鑰； 一段密文； 一段明文和使用公開密鑰加密過的密文；

流行的公開密鑰加密包括：

RSA DH ECDHE ECDH DHE

公開密鑰加密雖然更加簡單安全但其加密算法運算比較慢，所以一般混合使用公開密鑰加密和對稱密鑰加密的使用方式，即先通過公開密鑰加密獲取到對稱密鑰加密的密鑰，再通過對稱密鑰加密傳輸數(shù)據(jù)。這種情況在后文說明。

數(shù)字簽名

對稱密鑰加密和公開密鑰加密都是將報文加密的技術。但加密能做的不止如此，還可以用加密算法來證明報文是誰編寫的以及中途沒有被篡改。數(shù)字簽名就是這種技術。

數(shù)字簽名是附加在報文上的特殊加密校驗碼。其使用了私有密鑰加密生成校驗碼，除發(fā)送者外其他人都無法重新生成對應的校驗碼，這樣就證明了報文的身份以及中途沒有被人篡改過。

數(shù)字簽名通常通過公開密鑰技術產(chǎn)生，但使用方式相反。發(fā)送者首先為要簽名內(nèi)容生成報文摘要，使用簽名函數(shù)并輸入私有密鑰作為參數(shù)，對報文摘要進行加密，生成簽名并隨報文一起發(fā)送出去。接收者通過附加了公開密鑰參數(shù)的簽名函數(shù)反函數(shù)將簽名解密，并與生成的報文摘要進行對比，如果結(jié)果一致則代表報文無誤。

常見的RSA加密系統(tǒng)可以同時用于公開密鑰加密和數(shù)字簽名。RSA加密系統(tǒng)將解碼函數(shù)D作為簽名函數(shù)使用，編碼函數(shù)E作為解簽名函數(shù)。

數(shù)字證書

單純的公開密鑰加密只適合對等的兩端通信，對于常用的服務器-客戶端通信模式仍存在一些問題。1是公開密鑰加密只能證明報文確實是發(fā)送方發(fā)送的且沒有篡改，但發(fā)送方本身是誰則無從得知，因為誰都可以生成公鑰私鑰對。如果把所有需要訪問的網(wǎng)站的公鑰都事先保存下來，數(shù)量巨大不說，如何發(fā)送這些公鑰且如何證明保存的公鑰確實是這個網(wǎng)站的公鑰也是個問題。數(shù)字證書則可以解決這些問題。

數(shù)字證書是網(wǎng)絡上的身份證明。一般包括如下內(nèi)容：

證書格式版本號 證書序列號； 證書簽名算法； 證書頒發(fā)者； 有效期； 對象名稱； 對象公開密鑰； 證書頒發(fā)者的數(shù)字簽名；

其中頒發(fā)者的數(shù)字簽名是通過數(shù)字證書的其余部分的報文摘要經(jīng)證書簽名算法及證書頒發(fā)者的私有密鑰計算出的，用于驗證數(shù)字證書的真實性。

任何人都能自行生成一個數(shù)字證書，但只有值得信任的組織（CA）生成的數(shù)字證書才會默認被瀏覽器信任。具體原因在下一節(jié)說明。

詳解數(shù)字證書驗證流程

關于瀏覽器驗證網(wǎng)站數(shù)字證書的流程網(wǎng)上的資料一般講的都不是很清楚。在查閱了不少資料后終于搞清楚這部分。

CA下發(fā)給網(wǎng)站的證書都是一個證書鏈，也就是一層一層的證書，從根證書開始，到下級CA，一層一層，最后一層就是網(wǎng)站證書。

瀏覽器收到服務器發(fā)送的證書后，需要驗證其真實性。而證書的簽名是通過簽名算法和上級CA的私鑰生成的，并非很多文章里簡單說的靠CA私鑰生成。瀏覽器需要用上級CA的公鑰才能解密簽名，并與生成的指紋對比，那么問題來了，這個上級CA的公鑰從哪來呢？

答案是此公鑰來自于證書鏈該層的上級CA的證書明文內(nèi)。單個X509v3證書由以下部分組成：

X.509v3證書由三部分組成：

tbsCertificate (to be signed certificate)，待簽名證書。 SignatureAlgorithm，簽名算法。 SignatureValue，簽名值。

tbsCertificate又包含10項內(nèi)容，在HTTPS握手過程中以明文方式傳輸：

Version Number，版本號。 Serial Number，序列號。 Signature Algorithm ID，簽名算法ID。 Issuer Name，發(fā)行者。 Validity period，有效時間。 Subject name ，證書主體名稱。 Subject Public Key Info ，證書主體公鑰信息，包含公鑰算法和公鑰值。 Issuer Unique Identifier (optional)，發(fā)行商唯一ID。 Subject Unique Identifier (optional)，主體唯一ID。 Extensions (optional)，擴展。

證書鏈由多個證書一層一層組成的，除了最底層的網(wǎng)站證書的公鑰是給用戶加密報文外，其他層證書中的公鑰均用于解密底層的證書指紋簽名。最高層的根證書是自簽名的，也就是自己頒發(fā)給自己，所以它的公鑰不僅用來解密下層的簽名，也用來給自己的簽名解密。

驗證證書是否真實的任務完成了，那么證書是否可靠如何驗證呢？一句話，只要根證書可靠，整個證書鏈就可靠，而根證書是否可靠要看這個根證書是否在操作系統(tǒng)或瀏覽器內(nèi)置的可信根證書內(nèi)，在的話就可信。

HTTPS

HTTPS是在HTTP報文發(fā)送給TCP之前對報文進行加密的安全協(xié)議。使用443端口進行通信。

普通的HTTP有如下四層：

應用層HTTP 傳輸層TCP 網(wǎng)絡層IP 數(shù)據(jù)鏈路層

HTTPS多了一個安全層：

應用層HTTP 安全層SSL/TLS 傳輸層TCP 網(wǎng)絡層IP 數(shù)據(jù)鏈路層

證書密鑰驗證都是在安全層驗證。常用的SSL/TLS編程實現(xiàn)庫是OPENSSL。

HTTPS實際驗證過程

此部分內(nèi)容主要參考《SSL/TLS協(xié)議運行機制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

實際的HTTPS驗證過程如下：

ClientHello階段 支持的協(xié)議版本，比如TLS 1.0版； 一個客戶端生成的隨機數(shù)，稍后用于生成”對話密鑰”； 支持的加密方法，比如RSA公鑰加密； 支持的壓縮方法； ServerHello階段 確認使用的加密通信協(xié)議版本； 一個服務器生成的隨機數(shù)，稍后用于生成”對話密鑰”； 確認使用的加密方法，比如RSA公鑰加密； 服務器證書；

對于需要驗證用戶證書的還會包含請求要求用戶提供證書。

客戶端回應

客戶端收到回應后首先驗證服務器證書：

是否由可信CA頒布； 證書中域名是否與實際域名一致； 是否在有效期內(nèi)；

證書沒問題的話客戶端會回應以下內(nèi)容：

一個隨機數(shù)（pre-master key)。該隨機數(shù)用服務器公鑰加密，防止被竊聽； 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送； 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務器校驗；

此時通信雙方都有了這三個隨機數(shù)。通過商定的加密方法根據(jù)三個隨機數(shù)生成一個相同的會話密鑰SessionSecret，用于之后的對稱加密。

服務器回應

服務器收到回應后計算出SessionSecret，并發(fā)送以下內(nèi)容給客戶端：

編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送； 服務器握手結(jié)束通知，表示服務器的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗

這樣HTTPS握手過程就結(jié)束了，之后就是通過HTTP發(fā)送經(jīng)過對稱加密的報文。

參考資料：

《HTTP權(quán)威指南》一書 《數(shù)字證書原理》http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html 《數(shù)字簽名是什么？》http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html 《HTTPS通信中的身份認證機制》https://cnodejs.org/topic/56eb698ec95e8f992473c5a3 《SSL證書必知必會：數(shù)字證書及CA基礎知識》http://liuqunying.blog.51cto.com/3984207/1664246 《SSL/TLS協(xié)議運行機制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html 《大型網(wǎng)站的 HTTPS 實踐（一）—— HTTPS 協(xié)議和原理》http://op.baidu.com/2015/04/https-s01a01/ 《理解 HTTPS 原理，SSL/TLS 協(xié)議》https://hacpai.com/article/1447920990604 《HTTPS證書生成原理和部署細節(jié)》http://www.barretlee.com/blog/2015/10/05/how-to-build-a-https-server/ 《HTTPS原理學習筆記》http://www.kevenwu.com/blogs/14/