準(zhǔn)確的說(shuō)饮戳，HTTPS 不是一種協(xié)議，而是 HTTP 和 SSL 兩種技術(shù)的組合测蹲，HTTP 本身所有的數(shù)據(jù)都是不加密的。
SSL ( Secure Socket Layer ) 鬼吵，有時(shí)也稱(chēng)為 TLS ( Transport Layer Security ) 扣甲，是介于傳輸層和應(yīng)用層的拓展層，可以將應(yīng)用層數(shù)據(jù)加密后送入傳輸層。因此琉挖，使用了 SSL 傳輸?shù)?HTTP 報(bào)文整體都是被加密的启泣。
真的安全嗎？
為什么 HTTPS 比 HTTP 安全示辈？下面來(lái)逐步分析其加密過(guò)程寥茫。
對(duì)稱(chēng)加密算法
對(duì)稱(chēng)加密算法：又稱(chēng)單鑰加密，是指加密和解密使用相同的密鑰矾麻。
因?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ì)稱(chēng)加密算法
非對(duì)稱(chēng)加密算法：又稱(chēng)雙鑰加密，包括公鑰和私鑰贬派。公鑰/私鑰一一對(duì)應(yīng)急但，有一把公鑰就必然有一把與之對(duì)應(yīng)的、獨(dú)一無(wú)二的私鑰搞乏，反之亦成立波桩。公鑰可以解開(kāi)私鑰加密的信息，反之亦成立查描；
借助非對(duì)稱(chēng)加密算法突委，服務(wù)端生成自己的密鑰對(duì)，私鑰自己保存冬三，公鑰對(duì)外公開(kāi)匀油。
這樣的話，客戶端就可以使用服務(wù)端返回的公鑰來(lái)加密自己的密鑰 ( 對(duì)稱(chēng)加密算法 ) 發(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ó)際通稱(chēng)，它是對(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ū)可靠。
以此類(lèi)推呈野，每級(jí)證書(shū)都是使用上一級(jí)證書(shū)的非對(duì)稱(chēng)密鑰進(jìn)行簽名和驗(yàn)證的低矮，我們稱(chēng)這一系列證書(shū)的關(guān)系為證書(shū)鏈。而在證書(shū)鏈的最頂層的是根證書(shū)被冒，那根證書(shū)的可靠性是由誰(shuí)保證的军掂？
根證書(shū)是由他自己進(jìn)行簽名和驗(yàn)證的，我們又稱(chēng)他為自簽名根證書(shū)昨悼。他的可靠性是不需要被證明的蝗锥，或者說(shuō)需要使用者去證明。
所以幔戏，只要我們系統(tǒng)中安裝了一個(gè)機(jī)構(gòu)的自簽名根證書(shū)玛追，就代表信任該證書(shū)下的所有證書(shū)。一旦根證書(shū)出了問(wèn)題闲延，我們的整個(gè)證書(shū)體系的安全就不再可信痊剖。
證書(shū)撤銷(xiāo)
證書(shū)吊銷(xiāo)列表 ( 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ì)稱(chēng)算法在性能上比對(duì)稱(chēng)算法要慢太多态坦。
采用對(duì)稱(chēng)算法已經(jīng)能確保整個(gè)通信的安全盐数，其加密/解密帶來(lái)的消耗可以忽略不計(jì)，而且理論上來(lái)說(shuō)對(duì)稱(chēng)算法比非對(duì)稱(chēng)算法甚至更難破解伞梯。
CA 為什么不使用自己的私鑰直接對(duì)證書(shū)加密玫氢，而采用數(shù)字簽名的方式？
其實(shí)這個(gè)問(wèn)題跟上一個(gè)類(lèi)似谜诫，因?yàn)?code>非對(duì)稱(chēng)加密的方式效率低下琐旁，比起加密原信息，不如去加密他的 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ū)吊銷(xiāo)列表，以及簽署新的二級(jí)證書(shū)懊蒸。
那么二級(jí)證書(shū)就可以用來(lái)做在線簽名荣倾，即使二級(jí)證書(shū)的私鑰被盜 ( 可能性很小 ) ，只要根證書(shū)是安全的骑丸，那么我就可以去更新證書(shū)的吊銷(xiāo)列表逃呼，來(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)銷(xiāo)。
為了避免重新握手而造成的訪問(wèn)效率低下欲鹏，這時(shí)候引入了Session ID的概念机久。出于某種原因，如果對(duì)話中斷且在短時(shí)間內(nèi)重連赔嚎，只要客戶端給出之前的Session ID膘盖，且服務(wù)器有這個(gè)Session ID的記錄，雙方就可以重新使用已有的對(duì)稱(chēng)密鑰尤误，而不必重新生成一把侠畔。
上述方式可以緩解單個(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ì)稱(chēng)加密算法。相對(duì)前面 SSL 建立連接時(shí)的非對(duì)稱(chēng)加密方式揖盘，對(duì)稱(chēng)加密方式對(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
