準(zhǔn)確的說(shuō)，HTTPS 不是一種協(xié)議，而是 HTTP 和 SSL 兩種技術(shù)的組合，HTTP 本身所有的數(shù)據(jù)都是不加密的。
SSL ( Secure Socket Layer ) ，有時(shí)也稱為 TLS ( Transport Layer Security ) ，是介于傳輸層和應(yīng)用層的拓展層，可以將應(yīng)用層數(shù)據(jù)加密后送入傳輸層。因此，使用了 SSL 傳輸?shù)?HTTP 報(bào)文整體都是被加密的。
真的安全嗎？
為什么 HTTPS 比 HTTP 安全？下面來(lái)逐步分析其加密過(guò)程。
對(duì)稱加密算法
對(duì)稱加密算法：又稱單鑰加密，是指加密和解密使用相同的密鑰。
因?yàn)?HTTP 所有數(shù)據(jù)都沒(méi)有被加密，一旦中間人攔截到客戶端請(qǐng)求，就可以看到具體的報(bào)文內(nèi)容。如果客戶端和服務(wù)端約定好同一密鑰進(jìn)行通信，則中間人無(wú)法破解。
但是服務(wù)端在通信之前不知道客戶端的密鑰，如何安全地進(jìn)行密鑰傳遞就是接下來(lái)要解決的問(wèn)題。
非對(duì)稱加密算法
非對(duì)稱加密算法：又稱雙鑰加密，包括公鑰和私鑰。公鑰/私鑰一一對(duì)應(yīng)，有一把公鑰就必然有一把與之對(duì)應(yīng)的、獨(dú)一無(wú)二的私鑰，反之亦成立。公鑰可以解開(kāi)私鑰加密的信息，反之亦成立；
借助非對(duì)稱加密算法，服務(wù)端生成自己的密鑰對(duì)，私鑰自己保存，公鑰對(duì)外公開(kāi)。
這樣的話，客戶端就可以使用服務(wù)端返回的公鑰來(lái)加密自己的密鑰 ( 對(duì)稱加密算法 ) 發(fā)送給服務(wù)端。即使中間人攔截，由于能解密公鑰的私鑰只有服務(wù)端才有，所以不能解密，保證了數(shù)據(jù)傳輸?shù)陌踩?/p>
那么問(wèn)題來(lái)了，任何人都可以生成一對(duì)公鑰/私鑰，如果中間人在攔截請(qǐng)求時(shí)，把自己的公鑰返回給客戶端，客戶端不能分辨出公鑰的擁有者，只會(huì)按照之前的邏輯，使用接收到的公鑰去加密自己的密鑰來(lái)和服務(wù)端通信。
由于客戶端使用中間人的公鑰進(jìn)行加密，所以中間人可以使用自己的私鑰對(duì)客戶端的請(qǐng)求進(jìn)行解密，拿到請(qǐng)求的所有內(nèi)容，然后再用服務(wù)端的公鑰對(duì)請(qǐng)求進(jìn)行加密并轉(zhuǎn)發(fā)給服務(wù)端。整個(gè)過(guò)程“天衣無(wú)縫”，你幾乎覺(jué)察不到中間人的存在，但是你的信息已經(jīng)實(shí)實(shí)在在地被盜取了。
如果客戶端能辨別服務(wù)端公鑰真?zhèn)?/code>，那么我們的信息又安全了。
數(shù)字證書(shū)
CA ( Certification Authority ) 是認(rèn)證機(jī)構(gòu)的國(guó)際通稱，它是對(duì)數(shù)字證書(shū)的申請(qǐng)者發(fā)放、管理、取消數(shù)字證書(shū)的機(jī)構(gòu)。CA的作用是檢查證書(shū)持有者身份的合法性，并簽發(fā)證書(shū)，以防證書(shū)被偽造或篡改。
服務(wù)端將自己的公鑰以及相關(guān)注冊(cè)信息發(fā)送給 CA 申請(qǐng)認(rèn)證，來(lái)獲得數(shù)字證書(shū)，其中就包含了服務(wù)端的公鑰。這樣服務(wù)端就可以返回?cái)?shù)字證書(shū)給客戶端，因?yàn)橥ㄟ^(guò)了國(guó)際權(quán)威機(jī)構(gòu)的認(rèn)證，數(shù)字證書(shū)將持有者的公鑰和持有者的身份綁定起來(lái)，我們這次可以放心地使用公鑰去和服務(wù)端進(jìn)行通信了。
這時(shí)候中間人又出來(lái)搞事情了，我能偽造公鑰，我難道不能偽造證書(shū)嗎？證書(shū)沒(méi)有加密，那我把證書(shū)中的公鑰換成我自己 ( 中間人 ) 的不就得了？
可以，沒(méi)毛病。不過(guò)中間者還是 SOMETIME NAIVE，CA 比他們不知道高到哪里去了，自然有應(yīng)對(duì)證書(shū)被篡改的辦法。
數(shù)字簽名
CA 首先對(duì)證書(shū)進(jìn)行 HASH，拿到摘要后使用 CA 的私鑰對(duì)其加密，并把加密后的結(jié)果 ( 簽名 ) 附在證書(shū)后面，這個(gè)過(guò)程就叫數(shù)字簽名。客戶端拿到證書(shū)后，會(huì)使用 CA 的公鑰對(duì)簽名解密，然后把證書(shū) HASH 后跟解密后的結(jié)果進(jìn)行對(duì)比，一致的話說(shuō)明確實(shí)是原廠出品，不一致的話說(shuō)明被纂改過(guò)，直接丟掉。
這次中間人發(fā)現(xiàn)沒(méi)招了，即使修改了證書(shū)，由于沒(méi)有 CA 的私鑰，就不能對(duì)證書(shū)的 HASH 結(jié)果進(jìn)行加密，這個(gè)數(shù)字簽名改不了是不會(huì)有客戶端認(rèn)的。正打算放棄時(shí)，他忽然想到，CA 的公鑰這里貌似可以做文章，如果能偽造 CA 的公鑰，那么就可以偽造證書(shū)，從而摧毀這套信任鏈體系。
那客戶端怎么保證 CA 的公鑰 ( 或者說(shuō)用于驗(yàn)證證書(shū)簽名的公鑰 ) 的可靠性？
證書(shū)鏈
其實(shí)，一個(gè)證書(shū)的公鑰是放在他上一級(jí)證書(shū)，只要能保證他上一級(jí)證書(shū)可靠，我們就能保證本級(jí)證書(shū)可靠。
以此類推，每級(jí)證書(shū)都是使用上一級(jí)證書(shū)的非對(duì)稱密鑰進(jìn)行簽名和驗(yàn)證的，我們稱這一系列證書(shū)的關(guān)系為證書(shū)鏈。而在證書(shū)鏈的最頂層的是根證書(shū)，那根證書(shū)的可靠性是由誰(shuí)保證的？
根證書(shū)是由他自己進(jìn)行簽名和驗(yàn)證的，我們又稱他為自簽名根證書(shū)。他的可靠性是不需要被證明的，或者說(shuō)需要使用者去證明。
所以，只要我們系統(tǒng)中安裝了一個(gè)機(jī)構(gòu)的自簽名根證書(shū)，就代表信任該證書(shū)下的所有證書(shū)。一旦根證書(shū)出了問(wèn)題，我們的整個(gè)證書(shū)體系的安全就不再可信。
證書(shū)撤銷
證書(shū)吊銷列表 ( Certificate Revocation List，CRL ) ，一個(gè)被簽署的列表，它指定了一套證書(shū)發(fā)布者認(rèn)為無(wú)效的證書(shū)。
當(dāng)我們從服務(wù)端拿到數(shù)字證書(shū)時(shí)，會(huì)根據(jù)證書(shū)上的CRL分發(fā)點(diǎn)從指定的 URL 下載 CRL 來(lái)檢查證書(shū)的有效性，CRL 包含了其下一次的更新日期。
Q&A
客戶端通過(guò)證書(shū)拿到服務(wù)端的公鑰后，為什么不采用雙鑰加密，而轉(zhuǎn)用單鑰加密？
這是個(gè)好問(wèn)題。確實(shí)，如果客戶端拿到服務(wù)端公鑰的時(shí)候，生成自己的公鑰/私鑰，然后把自己的公鑰發(fā)給服務(wù)端，采用兩對(duì)密鑰進(jìn)行通信也是可以的。
但是，非對(duì)稱算法在性能上比對(duì)稱算法要慢太多。
采用對(duì)稱算法已經(jīng)能確保整個(gè)通信的安全，其加密/解密帶來(lái)的消耗可以忽略不計(jì)，而且理論上來(lái)說(shuō)對(duì)稱算法比非對(duì)稱算法甚至更難破解。
CA 為什么不使用自己的私鑰直接對(duì)證書(shū)加密，而采用數(shù)字簽名的方式？
其實(shí)這個(gè)問(wèn)題跟上一個(gè)類似，因?yàn)?code>非對(duì)稱加密的方式效率低下，比起加密原信息，不如去加密他的 HASH 來(lái)得劃算，其實(shí)這兩種給我們帶來(lái)的作用是等效的，都能防止證書(shū)被篡改。
為什么不可以直接用根證書(shū)去給其他所有證書(shū)簽名，而要設(shè)計(jì)證書(shū)鏈的概念？
這個(gè)問(wèn)題一開(kāi)始也困擾我很久，我就不闡述我錯(cuò)誤的思路了，只提醒大家一點(diǎn)：兩個(gè)父子證書(shū)間的映射關(guān)系是放在子證書(shū)，而不是父證書(shū)。
如果直接使用根證書(shū)去給各服務(wù)端簽署證書(shū)，那根證書(shū)的密鑰就不是足夠安全的，畢竟簽署的過(guò)程不是手動(dòng)進(jìn)行，而是放在服務(wù)端進(jìn)行的。一旦有人攻破 CA 的服務(wù)器，拿到根證書(shū)的密鑰，那他就可以偽造根證書(shū)，該 CA 下的所有證書(shū)都不可信了。
所以，為了保證根證書(shū)的絕對(duì)安全，根證書(shū)的私鑰都被保存在離線的金庫(kù)中。他一般被定期拿出來(lái)確保相關(guān)密碼設(shè)備的正常工作，簽署證書(shū)吊銷列表，以及簽署新的二級(jí)證書(shū)。
那么二級(jí)證書(shū)就可以用來(lái)做在線簽名，即使二級(jí)證書(shū)的私鑰被盜 ( 可能性很小 ) ，只要根證書(shū)是安全的，那么我就可以去更新證書(shū)的吊銷列表，來(lái)讓被盜的二級(jí)證書(shū)失效。
為什么要有多個(gè)二級(jí)證書(shū)？我們可以使用不同的證書(shū)去做不同的事情，例如 A 來(lái)簽署保證郵件安全的證書(shū)，B 來(lái)簽署 SSL 證書(shū)。畢竟多線程更高效，各自負(fù)責(zé)自己的業(yè)務(wù)場(chǎng)景，一定程度上也能分散風(fēng)險(xiǎn) ( 我是這么想的，不一定對(duì) ) 。
缺點(diǎn)
HTTPS 相比于 HTTP 更加安全自不必說(shuō)，那他都有哪些缺點(diǎn)呢？
建立連接
HTTP 使用 TCP 三次握手建立連接，客戶端和服務(wù)端需要交換 3 個(gè)包。 HTTPS 除了 TCP 的三個(gè)包，還需要加上 SSL 握手需要的 9 個(gè)包，一共是 12 個(gè)包。
這樣的話，HTTPS 在建立連接階段比 HTTP 多花費(fèi)的時(shí)間包括了多出的網(wǎng)絡(luò)延時(shí)和 SSL 本身加密/解密的開(kāi)銷。
為了避免重新握手而造成的訪問(wèn)效率低下，這時(shí)候引入了Session ID的概念。出于某種原因，如果對(duì)話中斷且在短時(shí)間內(nèi)重連，只要客戶端給出之前的Session ID，且服務(wù)器有這個(gè)Session ID的記錄，雙方就可以重新使用已有的對(duì)稱密鑰，而不必重新生成一把。
上述方式可以緩解單個(gè)連接的性能問(wèn)題，但對(duì)于并發(fā)訪問(wèn)用戶數(shù)極多的大型網(wǎng)站，如果頻繁的重建 SSL 的Session ID，對(duì)于服務(wù)器性能的影響將會(huì)是致命的。這時(shí)可以考慮在 Web 服務(wù)前配置 [SSL Termination Proxy] ( https://en.wikipedia.org/wiki/TLS_termination_proxy ) ，來(lái)將 SSL 處理轉(zhuǎn)移到另一起機(jī)器以減少主服務(wù)器的負(fù)載。
通信階段
當(dāng) SSL 建立連接后，之后的加密方式會(huì)使用客戶端傳輸?shù)?code>對(duì)稱加密算法。相對(duì)前面 SSL 建立連接時(shí)的非對(duì)稱加密方式，對(duì)稱加密方式對(duì) CPU 的負(fù)荷基本可以忽略不記。
總而言之
HTTPS 相比 HTTP 在建立連接階段確實(shí)會(huì)有性能的影響，但建立連接之后的通信速度跟 HTTP 差別不大。
好在 HTTPS 提供了Session ID這種優(yōu)化的方式，再加上服務(wù)端如果能夠進(jìn)行恰當(dāng)?shù)呐渲煤蛢?yōu)化，相對(duì)于 HTTPS 帶來(lái)的安全性，給客戶端以及服務(wù)端造成體驗(yàn)上和性能上微小的損失都是值得的。
參考
- 密碼學(xué)筆記
- HTTPS 要比 HTTP 多用多少服務(wù)器資源？
- 深入揭秘HTTPS安全問(wèn)題&連接建立全過(guò)程
- 怎么保證「CA 的公鑰」是真實(shí)的？
- TLS 過(guò)程中，為何不用證書(shū)提供的公鑰加密數(shù)據(jù)或者加密私鑰，而要設(shè)計(jì)秘鑰交換流程呢？
- 證書(shū)鏈-Digital Certificates
- What’s in a certificate chain and why?
- SSL certificate chain verification
