當(dāng)我們在談?wù)?HTTPS 的時(shí)候竭恬，我們在談?wù)撌裁矗?br> 我覺得跛蛋，這些方面必不可少——
- https 是什么？
- https 與 http 的區(qū)別
- https 設(shè)計(jì)原理
- https 密鑰互換過程
https 是什么痊硕？
（此處已假設(shè)你熟悉并理解 http 協(xié)議赊级，如不懂可以參考我另一篇文章）
https 是我們?nèi)粘＞幊坛Ｓ玫降呐c安全有關(guān)的網(wǎng)絡(luò)協(xié)議， https 俗稱是基于 SSL/TLS 的 http 協(xié)議岔绸。
SSL/TLS 是什么呢理逊？
可以理解為是一種安全協(xié)議，相當(dāng)于網(wǎng)絡(luò)協(xié)議的安全套接層盒揉。
那 https 協(xié)議其實(shí)就相當(dāng)于是在 http 協(xié)議外面套了一層安全協(xié)議晋被，這就是 https 協(xié)議。
為什么要套這層SSL/TLS安全協(xié)議呢刚盈？因?yàn)?http 是不安全的羡洛。
了解過web安全應(yīng)該知道 http 協(xié)議是明文通信的，那么就會帶來3個(gè)安全問題：
- 竊聽風(fēng)險(xiǎn)：第三方可以獲知通信內(nèi)容
- 篡改風(fēng)險(xiǎn)：第三方可以修改通信內(nèi)容
- 冒充風(fēng)險(xiǎn)：第三方可以冒充他人身份參與通信
而 https 的誕生就恰好是為了解決這3個(gè)問題的藕漱。在 tcp 層與 http 層之間加入了 SSL/TLS 欲侮，來為通信提供網(wǎng)絡(luò)安全信道。
https 與 http 的區(qū)別
- http 是由“
http://”起始與默認(rèn)使用80端口肋联，而https的URL則是由“https://”起始與默認(rèn)使用443端口 - http 是明文傳輸信息的威蕉，https 是加密（對稱加密+非對稱加密）傳輸信息的。
- http不是安全的牺蹄，而且攻擊者可以通過監(jiān)聽和中間人攻擊等手段忘伞，獲取網(wǎng)站帳戶和敏感信息等薄翅。https 的設(shè)計(jì)可以防止前述攻擊沙兰，在正確配置時(shí)是安全的
- https 需要到 CA 申請證書，http 不需要證書
暫時(shí)我能想到的區(qū)別就這么多翘魄，歡迎補(bǔ)充：）
https 設(shè)計(jì)原理
我在網(wǎng)上看到過一篇文章鼎天，采用信鴿傳信的例子來形象生動的說明了 https 的設(shè)計(jì)原理。
主人公愛麗絲暑竟、鮑勃是一對情侶斋射，馬洛里是第三者育勺，現(xiàn)在處在愛麗絲和鮑勃需要用信鴿傳密信。
最初罗岖，愛麗絲和鮑勃是采用最簡陋的通信傳輸方式涧至，就是信件內(nèi)容不加密也不做任何處理。這時(shí)候他們發(fā)現(xiàn)桑包，他們的信件內(nèi)容經(jīng)常被人竊聽南蓬、篡改甚至被冒充的人發(fā)信件。原來哑了，他們的信鴿中途被馬洛里偷偷抓住了赘方，因此他們的通信其實(shí)是不可靠的。
類比過來弱左，這大概就是 http 協(xié)議實(shí)現(xiàn)的過程窄陡。
后來，聰明的鮑勃將信的內(nèi)容進(jìn)行加密拆火，即他們事前約定好怎么解密（如將每個(gè)字母如 a 均向后移動3位跳夭，此時(shí)變成 d）。 于是馬洛里截獲的就是加密過的內(nèi)容们镜，馬洛里就不知道他們的通信內(nèi)容了优妙。
但是馬洛里也非常聰明，他慢慢發(fā)現(xiàn)了信件被加密了憎账，不知道從哪里就弄到了解密的方法套硼，于是他們的通信方式再一次變得不可靠。
于是愛麗絲他倆又發(fā)明了新的通信方法：愛麗絲先用信鴿寄一個(gè)空的帶鎖的匣子給鮑勃胞皱，而且這個(gè)匣子也沒有鎖上邪意，這個(gè)鎖有且只有一把鑰匙，這時(shí)候是在愛麗絲手上反砌。鮑勃拿到空匣子之后將加密過的內(nèi)容放入匣子中雾鬼，然后鎖上一并寄給愛麗絲。
這時(shí)候馬洛里再截獲信鴿也沒有用了宴树，因?yàn)榫退闼佬偶锩鎯?nèi)容的解密方法策菜，但是他打不開這個(gè)盒子，因?yàn)橹挥袗埯惤z有鑰匙能夠打開這個(gè)裝信件的匣子酒贬。這便是 https 通信中非對稱加密的精髓了又憨。
但是怎么保障這個(gè)匣子就一定是最初愛麗絲寄給鮑勃的那個(gè)匣子呢？愛麗絲決定簽名標(biāo)記一下盒子锭吨，這樣鮑勃收到盒子的時(shí)候就可以檢查簽名來確定是愛麗絲送出的盒子了蠢莺。
村里比較有名望的泰德給人簽名，且他簽過的名他一定是可以認(rèn)出來的零如，所有人可以信任他躏将。這就是 https 原理設(shè)計(jì)中的向 CA 申請證書锄弱，泰德就相當(dāng)于是 CA 機(jī)構(gòu)。
這時(shí)候愛麗絲寄的匣子可以先找泰德簽名祸憋，然后鮑勃收到匣子也跟泰德確認(rèn)是不是愛麗絲的匣子会宪，最后匣子回到愛麗絲手中的時(shí)候她再跟泰德確認(rèn)一遍該簽名。這樣就完全保證了愛麗絲蚯窥、鮑勃的信鴿通信是完全可靠的狈谊。
這邊是 https 協(xié)議設(shè)計(jì)的大致過程。
其中沟沙，愛麗絲-鮑勃就是我們開發(fā)中的服務(wù)端和客戶端模型河劝， 馬洛里可以想象成網(wǎng)絡(luò)黑客，匣子是公鑰矛紫，匣子的鑰匙是私鑰赎瞎，然后泰德就是證書認(rèn)證機(jī)構(gòu) CA。
信件加密采用的是對稱加密颊咬，寄匣子然后自己留唯一鑰匙的方式采用的是非對稱加密务甥。這樣他們的通信方式就兼具非對稱加密的可靠性和對稱加密的高效性了。
“非對稱加密算法”：從數(shù)學(xué)上確保了——即使你知道某個(gè)公鑰喳篇，也很難（不是不可能敞临，是很難）根據(jù)此公鑰推導(dǎo)出對應(yīng)的私鑰。
“對稱加密”：只要知道了加密算法麸澜，人人都可以用這個(gè)加密算法解開經(jīng)過對稱加密的內(nèi)容挺尿。
https 密鑰互換過程
了解了https協(xié)議的設(shè)計(jì)原理，https 的通信過程就比較好理解了炊邦。唯一需要重點(diǎn)注意的编矾，就是 https 密鑰交換 的過程（這個(gè)很多大廠前端面試會考到哦）。
https 密鑰交換過程大致如下圖所示：
客戶端發(fā)起HTTPS請求
這個(gè)沒什么好說的馁害，就是用戶在瀏覽器里輸入一個(gè)https網(wǎng)址窄俏，然后連接到server的443端口。服務(wù)端的配置
采用HTTPS協(xié)議的服務(wù)器一般會向 CA 申請一套數(shù)字證書碘菜。這套證書其實(shí)就是一對公鑰和私鑰凹蜈，即公鑰加密過的內(nèi)容，只有私鑰才能解密忍啸。如果覺得這不太好理解仰坦，公鑰和私鑰可以想象成上面例子中的那個(gè)匣子和開匣子的鑰匙。傳送證書
這個(gè)證書其實(shí)就是公鑰吊骤，只是包含了很多信息缎岗，如證書的頒發(fā)機(jī)構(gòu)，過期時(shí)間等等白粉。客戶端解析證書
這部分工作是由客戶端的TLS來完成的传泊，首先會驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)鸭巴，過期時(shí)間等等眷细，如果發(fā)現(xiàn)異常，則會彈出一個(gè)警告框鹃祖，提示證書存在問題溪椎。如果證書沒有問題，那么就生成一個(gè)隨即值（如上圖的 k）恬口。然后用證書的公鑰 k2 對該隨機(jī)值k進(jìn)行加密 得到 k‘校读。就好像上面說的，把隨機(jī)值用鎖頭鎖起來祖能，這樣除非有鑰匙歉秫，不然看不到被鎖住的內(nèi)容。傳送加密信息
這部分傳送的是用證書加密后的隨機(jī)值k’养铸，目的就是讓服務(wù)端也得到這個(gè)隨機(jī)值雁芙，以后客戶端和服務(wù)端的通信就可以通過這個(gè)隨機(jī)值來進(jìn)行加密解密了。服務(wù)端解密信息
服務(wù)端用私鑰k1解密k‘后钞螟，得到了客戶端傳過來的隨機(jī)值k(私鑰)兔甘，然后把內(nèi)容通過該值進(jìn)行對稱加密。所謂對稱加密就是鳞滨，將信息和私鑰通過某種算法混合在一起洞焙，這樣除非知道私鑰，不然無法獲取內(nèi)容拯啦，而正好客戶端和服務(wù)端都知道這個(gè)私鑰闽晦，所以只要加密算法夠彪悍，私鑰夠復(fù)雜提岔，數(shù)據(jù)就夠安全仙蛉。傳輸加密后的信息
這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原碱蒙。客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)端傳過來的信息荠瘪，于是獲取了解密后的內(nèi)容。整個(gè)過程第三方即使監(jiān)聽到了數(shù)據(jù)赛惩，也束手無策哀墓。
需要注意的是，客戶端和服務(wù)器端雙方最終采用 "對話密鑰"（上圖中的 k喷兼，通過雙方協(xié)商生成） 進(jìn)行加密通信的篮绰，而非最開始從從 CA 那里申請得到的公鑰或私鑰。
