HTTPS中的對(duì)稱密鑰加密，公開(kāi)密鑰加密，數(shù)字證書(shū)

HTTPS中的對(duì)稱密鑰加密，公開(kāi)密鑰加密，數(shù)字證書(shū) 密鑰

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

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

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

對(duì)稱密鑰加密

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

流行的對(duì)稱密鑰加密包括：

DES TRiple-DES RC2 RC4

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

公開(kāi)密鑰加密

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

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

要保證公開(kāi)密鑰加密的可用性必須確保以下情況無(wú)法計(jì)算出私有密鑰：

有公開(kāi)密鑰； 一段密文； 一段明文和使用公開(kāi)密鑰加密過(guò)的密文；

流行的公開(kāi)密鑰加密包括：

RSA DH ECDHE ECDH DHE

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

數(shù)字簽名

對(duì)稱密鑰加密和公開(kāi)密鑰加密都是將報(bào)文加密的技術(shù)。但加密能做的不止如此，還可以用加密算法來(lái)證明報(bào)文是誰(shuí)編寫(xiě)的以及中途沒(méi)有被篡改。數(shù)字簽名就是這種技術(shù)。

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

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

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

數(shù)字證書(shū)

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

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

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

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

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

詳解數(shù)字證書(shū)驗(yàn)證流程

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

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

瀏覽器收到服務(wù)器發(fā)送的證書(shū)后，需要驗(yàn)證其真實(shí)性。而證書(shū)的簽名是通過(guò)簽名算法和上級(jí)CA的私鑰生成的，并非很多文章里簡(jiǎn)單說(shuō)的靠CA私鑰生成。瀏覽器需要用上級(jí)CA的公鑰才能解密簽名，并與生成的指紋對(duì)比，那么問(wèn)題來(lái)了，這個(gè)上級(jí)CA的公鑰從哪來(lái)呢？

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

X.509v3證書(shū)由三部分組成：

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

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

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

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

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

HTTPS

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

普通的HTTP有如下四層：

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

HTTPS多了一個(gè)安全層：

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

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

HTTPS實(shí)際驗(yàn)證過(guò)程

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

實(shí)際的HTTPS驗(yàn)證過(guò)程如下：

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

對(duì)于需要驗(yàn)證用戶證書(shū)的還會(huì)包含請(qǐng)求要求用戶提供證書(shū)。

客戶端回應(yīng)

客戶端收到回應(yīng)后首先驗(yàn)證服務(wù)器證書(shū)：

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

證書(shū)沒(méi)問(wèn)題的話客戶端會(huì)回應(yīng)以下內(nèi)容：

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

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

服務(wù)器回應(yīng)

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

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

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

參考資料：

《HTTP權(quán)威指南》一書(shū) 《數(shù)字證書(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通信中的身份認(rèn)證機(jī)制》https://cnodejs.org/topic/56eb698ec95e8f992473c5a3 《SSL證書(shū)必知必會(huì)：數(shù)字證書(shū)及CA基礎(chǔ)知識(shí)》http://liuqunying.blog.51cto.com/3984207/1664246 《SSL/TLS協(xié)議運(yùn)行機(jī)制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html 《大型網(wǎng)站的 HTTPS 實(shí)踐（一）—— HTTPS 協(xié)議和原理》http://op.baidu.com/2015/04/https-s01a01/ 《理解 HTTPS 原理，SSL/TLS 協(xié)議》https://hacpai.com/article/1447920990604 《HTTPS證書(shū)生成原理和部署細(xì)節(jié)》http://www.barretlee.com/blog/2015/10/05/how-to-build-a-https-server/ 《HTTPS原理學(xué)習(xí)筆記》http://www.kevenwu.com/blogs/14/