Https的前世此生

一、年前會議

立刻要過年了,公司業務上的需求也少了不少,這不,王小二他們召開了一場技術會議,盤點年前能幹點啥。nginx

只見C哥寫了一份清單,其中一項是全站升級https。ajax

C哥說:https是一種趨勢,但目前咱們接口仍是http的。appstore也一直要求使用https,從安全性以及appstore審覈的角度來看,咱們年前得全站升級https。有誰挺身而出嗎?算法

小二想了一下:我來作吧C哥,正好了解下https。瀏覽器

C哥:好,小二,那你接下來研究下https,而後有時間再給咱們分享下。安全

小二:好的C哥,保證完成!服務器

二、深藏不露張三胖

據說小二要作https,運維張三胖走到小二身旁。網絡

張三胖:小二,據說你要作https?app

小二:是啊,三胖哥,咱們得全站升級https。你以前瞭解過嗎?運維

張三胖:哈哈,我還真瞭解過,升級https是個不錯的注意。工具

小二:三胖哥,那太好了,你有時間給我講講?我就不用花時間去查資料了。

張三胖:好,我如今正有時間,給你講講,也正好複習下。

小二:多謝三胖哥,今中午請你吃飯啊。

三、對稱加密不足夠

三胖:小二,假設你用http協議給你女友發一封私密消息。這樣有沒有泄密的風險呢?

小二:固然有了,http協議是明文傳輸,傳輸數據過程當中的任何第三方均可以截獲並篡改該明文。

三胖微微一笑:是的,咱們畫幅圖表示下,你就知道信息被篡改多尷尬了,哈哈。

image_1c53cjed6t3s3ji108819b81r4sa5.png-28.6kB

小二:啊?確實是,那這樣太尷尬了。我女友不打死我...

三胖:其實用https就能夠規避。

三胖:小二,你瞭解對稱加密與非對稱加密嗎?

小二:瞭解一些。對稱加密就是加密與解密的祕鑰是相同的。而非對稱加密就是公鑰加密的內容,必須用私鑰才能解密,私鑰加密的內容,必須用公鑰才能解密。

三胖:小二瞭解的還挺多嘛,其實https就是利用了對稱加密與非對稱加密的特性。但你要注意,對稱加密的速度是非對稱加密速度的100倍左右。

小二:三胖哥我明白了,那你用剛纔的例子給我講講https的原理吧。

三胖:好,就用剛纔的例子。對稱加密速度很快,因此你跟你女友的數據傳輸最好用對稱加密。

小二:能夠啊,那我跟我女友就先約定好一個祕鑰唄?

三胖:是的,咱們再畫張圖表示大家的數據傳輸過程。

image_1c53d58gq1ri1tnotk91j071dcub2.png-46.8kB

小二:是啊,胖哥,這樣別人就無法截獲個人信息了。

三胖:對。而且由於對稱加解密的速度很快,對大家數據傳輸速度的影響微乎其微。可是,你怎麼跟你女友溝通協商祕鑰呢?

小二:這還不簡單,我直接網上告訴他就能夠啊。

三胖:哈哈,不能夠。你明文經過網絡傳輸的祕鑰被人截取了怎麼辦?

小二:啊?確實是,別人截取祕鑰後又能夠篡改個人信息了。

三胖:這時候就須要用到咱們的非對稱加密來協商大家對稱加密的祕鑰了。

四、非對稱加密解憂愁

image_1c53dev3118a91btb1c26m6m1o3ibf.png-26.1kB

三胖:小美生成本身的公鑰和私鑰,通訊以前,她告訴你她的公鑰就能夠了,這個公鑰由於是公開的,因此能夠隨意在網絡中傳輸了。

小二:這樣啊,我明白了C哥。我獲得小美的公鑰後,而後用小美的公鑰,對對稱加密的密碼進行非對稱加密後發給小美。小美再經過他的私鑰解密後,就獲取了我生成的對稱加密的密碼了。是否是?

image_1c53fp98maga1s40okg1v098r9bs.png-27.6kB

三胖:對,就是這樣的。可是還有一個頭疼的問題,你怎麼確保你獲得的就是小美的公鑰呢?假設中間人給你截獲篡改了呢?

小二:嗯...這確實是個問題。中間人把他的公鑰發給我,這樣我就使用中間人的公鑰加密咱們對稱加密的密碼了,而後中間人再用他的私鑰解密出咱們對稱加密的密碼。這時候中間人已經截取了小美的公鑰,而後再把咱們對稱加密的密碼經過小美的公鑰加密後發給小美...太可怕了,咱們對稱加密的祕鑰就這樣被竊取了。

三胖:其實抓包工具charles之因此能抓https的包,就是利用的你說的這個原理,一會咱們再細說。那如今問題就變成了,你怎麼確保你獲得的公鑰就是小美的。

小二:哎,真讓人頭疼...

三胖:你知道咱們平時都有公證處吧?這個公證處是一個可信的結構,經他公證的東西,都是具備可信力度的。

小二:知道啊,前幾天還看新聞說一個老太把他在帝都的一套房產經過公證處公證給了一個沒有血緣關係的小夥。

三胖:那你想一想,若是小美的公鑰通過公證後,是否是就能證實這個公鑰是小美的呢?

小二:固然可以證實。只是網絡中存在這樣的公證處嗎?

三胖:還真存在這樣的公證處,咱們把網絡中的公證處稱爲CA吧。不得不佩服前輩們,他們把一些可信的CA的證書都預先存在咱們的電腦裏了,證書包括CA的信息和CA的公鑰。只要你電腦安裝了系統,就安裝了這些證書。來,你看看我電腦裏默認安裝的證書。

image_1c50cl34t71k13ke7651a2b84im.png-219kB

小二:哦哦,明白了,意思就說這些默認的CA證書是絕對可信的。

三胖:對,就是這個意思。因此,只要CA同時給小美頒發一個證書證實是小美就能夠了。CA給小美頒發的證書中,含有小美的我的信息以及小美的公鑰。同時,CA也會給小美頒發一個私鑰。

你先把小美想象成百度,咱們先來看CA給百度頒發的證書。

image_1c53gega513991vgv64l14vfdv3c9.png-118.7kB

小二:也就是說,只要保證CA給小美頒發的證書可以安全傳輸到我這裏來就能夠了。

三胖:對,如今的問題就轉換成了。小美的證書如何可以安全的傳輸到你這裏?其實,CA給小美頒發的證書中,包含【小美的信息+公鑰】、以及數字簽名。 數字簽名的內容是:使用CA私鑰加密過的【小美的信息+公鑰】的hash值。

image_1c52jnccmf5g183hbdeo7782143.png-45.6kB

小二:哦哦,我好像明白了。CA的證書包含CA的公鑰以及CA的一些信息,而且CA的證書默認存儲在個人電腦裏了,那我就可使用CA的公鑰進行解密操做,從而驗證小美的證書是不是正確的了。

三胖:對的。咱們可使用你電腦裏CA的公鑰解密小美證書裏的數字簽名,從而獲得簽名的hash值。而後,你再用一樣的hash算法對【小美的信息+公鑰】進行hash計算。若是小美證書裏簽名的hash值與你本身計算出來的hash值一致,就說明這個證書確實是小美的,不然就不是小美的證書。

image_1c52ks5du47j1ogr1l5g2221kmv5j.png-79kB

小二:三胖哥,我算是明白了。https還真是麻煩,但也確實保護了咱們的隱私。

三胖:對,有失必有得嘛!

小二:嗯嗯。我如今經過小美的證書安全的獲取了小美的公鑰。那我這兒隨機生成一個對稱加密的祕鑰,這個對稱加密的祕鑰再經過小美的公鑰加密後,就能安全的傳輸給小美了。

三胖:是,小美再用他的私鑰解密,就獲取了大家約定的對稱加密的密碼了。之後,大家就可使用對稱加密來傳輸數據,暗送秋波了,哈哈~

小二:三胖哥真是太厲害了,今後不再用擔憂跟我女友聊天被惡搞了。

三胖:哈哈。你把你本身想成瀏覽器,把小美想成服務器。這就是整個https的傳輸流程。

小二:明白了,我畫一下https在瀏覽器與服務器之間的運行流程,三胖哥你看下對不對。

image_1c53h99r81cpl2fp142b1ir5sc6d3.png-65.3kB

三胖:不錯不錯,小二很厲害嘛,基本就是這個流程。

小二:沒有沒有,還得多謝三胖哥的指教啊,哈哈。

五、Charles抓取https包的原理

image_1c53j78831ffh1q829cboukbeqdg.png-133.7kB
三胖:小二,咱們知道charles抓包工具可以抓取https的包,你知道這是什麼原理嗎?

小二:這我還真不知道,按理說https是絕對安全的協議,內容不會被charles抓取啊。

三胖:你記不記得,使用charles抓https包的時候,須要在你手機上安裝charles證書而且信任該證書

小二:對對,是有這一步操做。

三胖:就是這一步操做,可使Charles抓取你的https包。我給你畫個流程圖你就明白了。

image_1c53apjmvi601p3hq7u5jb6t9o.png-82kB

小二:原來是這樣,這不就是我剛纔說的問題嘛。那麼就說明https不是安全的協議了?

三胖:不是的。由於你安裝並信任charles證書,是你本身主動的操做,也能夠說是你本身主動泄密的結果。若是你不信任該charles證書,那麼數據就不會被傳輸,鏈接會被直接中斷。因此https仍是安全的協議。

小二:我明白了,確實是這樣,多謝三胖哥。

Happy Done

https的原理明白了,接下來的事情天然就水到渠成了。

小二列出了接下來要作的事情: 一、向CA(公證處)申請本身網站的證書; 二、修改代碼裏靜態資源的http連接爲https連接; 三、修改ajax裏面的http連接爲https連接; 四、將證書部署在nginx上; 五、自測完成。

按照這個列表,小二一步步的順利完成了。

最終,https上線完成,愜意的享受午後的陽光吧,happy done~


image_1c5582vev1mql1lrpbm3198i1pkop.png-127.1kB
相關文章
相關標籤/搜索