HTTPS中的對(duì)稱密鑰加密，公開(kāi)密鑰加密，數(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í)編寫的以及中途沒(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ù)字證書單純的公開(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ù)字證書則可以解決這些問(wèn)題。
數(shù)字證書是網(wǎng)絡(luò)上的身份證明。一般包括如下內(nèi)容：
證書格式版本號(hào) 證書序列號(hào)； 證書簽名算法； 證書頒發(fā)者； 有效期； 對(duì)象名稱； 對(duì)象公開(kāi)密鑰； 證書頒發(fā)者的數(shù)字簽名；其中頒發(fā)者的數(shù)字簽名是通過(guò)數(shù)字證書的其余部分的報(bào)文摘要經(jīng)證書簽名算法及證書頒發(fā)者的私有密鑰計(jì)算出的，用于驗(yàn)證數(shù)字證書的真實(shí)性。
任何人都能自行生成一個(gè)數(shù)字證書，但只有值得信任的組織（CA）生成的數(shù)字證書才會(huì)默認(rèn)被瀏覽器信任。具體原因在下一節(jié)說(shuō)明。
詳解數(shù)字證書驗(yàn)證流程關(guān)于瀏覽器驗(yàn)證網(wǎng)站數(shù)字證書的流程網(wǎng)上的資料一般講的都不是很清楚。在查閱了不少資料后終于搞清楚這部分。
CA下發(fā)給網(wǎng)站的證書都是一個(gè)證書鏈，也就是一層一層的證書，從根證書開(kāi)始，到下級(jí)CA，一層一層，最后一層就是網(wǎng)站證書。
瀏覽器收到服務(wù)器發(fā)送的證書后，需要驗(yàn)證其真實(shí)性。而證書的簽名是通過(guò)簽名算法和上級(jí)CA的私鑰生成的，并非很多文章里簡(jiǎn)單說(shuō)的靠CA私鑰生成。瀏覽器需要用上級(jí)CA的公鑰才能解密簽名，并與生成的指紋對(duì)比，那么問(wèn)題來(lái)了，這個(gè)上級(jí)CA的公鑰從哪來(lái)呢？
答案是此公鑰來(lái)自于證書鏈該層的上級(jí)CA的證書明文內(nèi)。單個(gè)X509v3證書由以下部分組成：
X.509v3證書由三部分組成：
tbsCertificate (to be signed certificate)，待簽名證書。 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 ，證書主體名稱。 Subject Public Key Info ，證書主體公鑰信息，包含公鑰算法和公鑰值。 Issuer Unique Identifier (optional)，發(fā)行商唯一ID。 Subject Unique Identifier (optional)，主體唯一ID。 Extensions (optional)，擴(kuò)展。證書鏈由多個(gè)證書一層一層組成的，除了最底層的網(wǎng)站證書的公鑰是給用戶加密報(bào)文外，其他層證書中的公鑰均用于解密底層的證書指紋簽名。最高層的根證書是自簽名的，也就是自己頒發(fā)給自己，所以它的公鑰不僅用來(lái)解密下層的簽名，也用來(lái)給自己的簽名解密。
驗(yàn)證證書是否真實(shí)的任務(wù)完成了，那么證書是否可靠如何驗(yàn)證呢？一句話，只要根證書可靠，整個(gè)證書鏈就可靠，而根證書是否可靠要看這個(gè)根證書是否在操作系統(tǒng)或?yàn)g覽器內(nèi)置的可信根證書內(nèi)，在的話就可信。
HTTPSHTTPS是在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ù)鏈路層證書密鑰驗(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ù)器證書；對(duì)于需要驗(yàn)證用戶證書的還會(huì)包含請(qǐng)求要求用戶提供證書。
客戶端回應(yīng)客戶端收到回應(yīng)后首先驗(yàn)證服務(wù)器證書：
是否由可信CA頒布； 證書中域名是否與實(shí)際域名一致； 是否在有效期內(nèi)；證書沒(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ù)字證書原理》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證書必知必會(huì)：數(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證書生成原理和部署細(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/
下載文檔
