從http看https的誕生緣由
本文重點(diǎn)不在于http，所有對http的原理和過程不做過多仔細(xì)的說明蛀蜜。我們熟悉的http的大致請求過程如下：
- 客戶端連接到Web服務(wù)器
- 發(fā)送HTTP請求
- 服務(wù)器接受請求并返回HTTP響應(yīng)
由于HTTP協(xié)議采用明文傳輸，通過抓包很輕松的獲取到HTTP所傳輸?shù)臄?shù)據(jù)膊爪。因此蜒什，采用HTTP協(xié)議是不安全的。這才催生了HTTPS的誕生滨巴。HTTPS相對HTTP提供了更安全的數(shù)據(jù)傳輸保障。主要體現(xiàn)在三個方面：
內(nèi)容加密碰镜。客戶端到服務(wù)器的內(nèi)容都是以加密形式傳輸习瑰，中間者無法直接查看明文內(nèi)容绪颖。
身份認(rèn)證。通過校驗(yàn)保證客戶端訪問的是自己的服務(wù)器甜奄。
數(shù)據(jù)完整性柠横。防止內(nèi)容被第三方冒充或者篡改。
HTTPS的握手過程
客戶端發(fā)送開始請求课兄，包含一個隨機(jī)數(shù) random1牍氛。
服務(wù)端回復(fù)客戶端請求，包含一個隨機(jī)數(shù) random2烟阐，攜帶了證書公鑰 P搬俊。
客戶端接收到 random2 之后就能夠生成 premaster_secrect （對稱加密的密鑰）以及 master_secrect（用premaster_secret加密后的數(shù)據(jù)）。
客戶端使用證書公鑰 P 將 premaster_secrect 加密后發(fā)送給服務(wù)器 (用公鑰P對premaster_secret加密)蜒茄。
服務(wù)端使用私鑰解密得到 premaster_secrect唉擂。又由于服務(wù)端之前就收到了隨機(jī)數(shù) 1，所以服務(wù)端根據(jù)相同的生成算法檀葛，在相同的輸入?yún)?shù)下玩祟，求出了相同的 master secrect。
上面過程需要結(jié)合以下內(nèi)容加以理解屿聋。
加密方式
在分析HTTPS原理之前我們得先了解一下兩種加密方式： 對稱加密和非對稱加密空扎。
對稱加密
所謂的對稱加密算法就是指客戶端和服務(wù)端的密鑰是同一個藏鹊。比如客戶端A使用密鑰S對請求數(shù)據(jù)進(jìn)行加密，服務(wù)端收到請求后同樣使用密鑰S解密转锈。這就是對稱加密算法盘寡，其中密鑰S同時扮演加密和解密的角色。具體細(xì)節(jié)黑忱，本文以后添加宴抚。
對稱加密算法本事的破解難度很大，如果說這個密鑰S不公開給其他第三方甫煞，一般是無法破解的菇曲，也就能解決我們請求過程中加密的問題。但是實(shí)際情況中抚吠，服務(wù)器和客戶端是一對多的關(guān)系常潮，也就是說需要針對不同客戶端使用不同的加密密鑰：
由此引出兩個問題
1.服務(wù)器端怎么告訴客戶端該使用哪種對稱加密算法？
通過協(xié)商楷力，服務(wù)端告訴具體的客戶端它該使用哪種加密算法
要達(dá)到服務(wù)器針對每個客戶端使用不同的對稱加密算法喊式，同時，我們也不能讓第三者知道這個對稱加密算法是什么萧朝，怎么辦岔留？
使用隨機(jī)數(shù)，就是使用隨機(jī)數(shù)來生成對稱加密算法检柬。這樣就可以做到服務(wù)器和客戶端每次交互都是新的加密算法献联、只有在交互的那一該才確定加密算法。
也就是為什么HTTPS協(xié)議握手階段會有這么多的隨機(jī)數(shù)的原因了何址。
2.如果協(xié)商的過程被第三方截取怎么辦?
那就再對協(xié)商過程進(jìn)行加密好了唄里逆。那協(xié)商過程的加密的過程還是沒有加密啊。雞生蛋用爪，蛋生雞的問題出來了。
對稱加密的缺點(diǎn)就在于對稱加密需要在網(wǎng)絡(luò)上傳輸密鑰和密文诸衔，一旦被黑客截取很容就能被破解颇玷。
非對稱加密
在了解了對稱加密算法署隘，對非對稱加密應(yīng)該有個大概的概念了。非對稱加密 即加密和解密使用不同的密鑰亚隙，分別稱為公鑰和私鑰。用公鑰對數(shù)據(jù)進(jìn)行加密，但必須要用私鑰才能解密羞延。在網(wǎng)絡(luò)上只需要傳送公鑰，私鑰保存在服務(wù)端用于解密公鑰加密后的密文脾还。
同樣的引出一個問題
客戶端如何獲得服務(wù)端的公鑰呢伴箩？
如果客戶端在發(fā)送數(shù)據(jù)之前沒有得到公鑰，還怎么進(jìn)行加密呢嗤谚？所有怔蚌，客戶端在一開始就需要先持有公鑰。那客戶端獲取服務(wù)端公鑰的過程怎么保證是安全的呢桦踊？這里引用一張網(wǎng)上的圖來加以理解：
顯然讓客戶端保存所有網(wǎng)站的公鑰是不現(xiàn)實(shí)的。為了解決這個問題竟闪，引入了第三方機(jī)構(gòu)的概念杖狼，也就是指數(shù)字證書簽發(fā)機(jī)構(gòu)（CA）。第三方機(jī)構(gòu)使用它的私鑰對我們的公鑰進(jìn)行加密后蝶涩，再傳給客戶端“堤簦客戶端再使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密斜友。如果能解密垃它，就說明這個公鑰沒有被中間人調(diào)包。因?yàn)槿绻虚g人使用自己的私鑰加密后的東西傳給客戶端国拇，客戶端是無法使用第三方的公鑰進(jìn)行解密的。
數(shù)字證書
第三方機(jī)構(gòu)不可能只給你一家公司制作證書也殖，它也可能會給中間人這樣有壞心思的公司發(fā)放證書。這樣的忆嗜，中間人就有機(jī)會對你的證書進(jìn)行調(diào)包，客戶端在這種情況下是無法分辨出是接收的是你的證書闪湾，還是中間人的绩卤。因?yàn)椴徽撝虚g人，還是你的證書濒憋，都能使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密。
第三方機(jī)構(gòu)向多家公司頒發(fā)證書的情況：
客戶端能解密同一家第三機(jī)構(gòu)頒發(fā)的所有證書：
最終導(dǎo)致其它持有同一家第三方機(jī)構(gòu)證書的中間人可以進(jìn)行調(diào)包：
證書分類：
- CA機(jī)構(gòu)頒發(fā)的證書跋炕，受信任的證書
- 非CA機(jī)構(gòu)即是不受信任的機(jī)構(gòu)頒發(fā)的證書赖晶，理所當(dāng)然這樣的證書是不受信任的辐烂。
- 自簽名證書，就是自己給自己頒發(fā)的證書胳嘲。當(dāng)然自簽名證書也是不受信任的扣草。
數(shù)字簽名，解決同一機(jī)構(gòu)頒發(fā)的不同證書被篡改問題
要解決這個問題辰妙，我們首先要想清楚一個問題密浑，辨別同一機(jī)構(gòu)下不同證書的這個職責(zé)，我們應(yīng)該放在哪尔破？
只能放到客戶端了。意思是餐济，客戶端在拿到證書后胆剧，自己就有能力分辨證書是否被篡改了。如何才能有這個能力呢？
我們從現(xiàn)實(shí)中找靈感冤灾。比如你是HR辕近，你手上拿到候選人的學(xué)歷證書，證書上寫了持證人归粉，頒發(fā)機(jī)構(gòu)漏峰，頒發(fā)時間等等，同時證書上浅乔，還寫有一個最重要的：證書編號靖苇！我們怎么鑒別這張證書是的真?zhèn)文兀恐灰弥@個證書編號上相關(guān)機(jī)構(gòu)去查贤壁，如果證書上的持證人與現(xiàn)實(shí)的這個候選人一致，同時證書編號也能對應(yīng)上馒索，那么就說明這個證書是真實(shí)的名船。
我們的客戶端能不能采用這個機(jī)制呢？像這樣：
可是蜈块，這個“第三方機(jī)構(gòu)”到底是在哪呢渴邦？是一個遠(yuǎn)端服務(wù)拘哨？不可能吧？如果是個遠(yuǎn)端服務(wù)瓮床，整個交互都會慢了。所以隘庄，這個第三方機(jī)構(gòu)的驗(yàn)證功能只能放在客戶端的本地了丑掺。
客戶端本地怎么驗(yàn)證證書呢？
客戶端本地怎么驗(yàn)證證書呢街州？答案是證書本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書的真?zhèn)巍?br>
也就是證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號△⒄鳎客戶端拿到證書后根據(jù)證書上的方法自己生成一個證書編號面徽，如果生成的證書編號與證書上的證書編號相同，那么說明這個證書是真實(shí)的氮双。
同時霎匈，為避免證書編號本身又被調(diào)包，所以使用第三方的私鑰進(jìn)行加密唧躲。
這地方有些抽象，我們來個圖幫助理解：
證書的制作如圖所示饭入。證書中的“編號生成方法MD5”就是告訴客戶端：你使用MD5對證書的內(nèi)容求值就可以得到一個證書編號肛真。
當(dāng)客戶端拿到證書后，開始對證書中的內(nèi)容進(jìn)行驗(yàn)證乾忱，如果客戶端計(jì)算出來的證書編號與證書中的證書編號相同历极，則驗(yàn)證通過：
但是第三方機(jī)構(gòu)的公鑰怎么跑到了客戶端的機(jī)器中呢趟卸？
其實(shí)呢氏义，現(xiàn)實(shí)中图云，瀏覽器和操作系統(tǒng)都會維護(hù)一個權(quán)威的第三方機(jī)構(gòu)列表（包括它們的公鑰）。因?yàn)榭蛻舳私邮盏降淖C書中會寫有頒發(fā)機(jī)構(gòu)竣况，客戶端就根據(jù)這個頒發(fā)機(jī)構(gòu)的值在本地找相應(yīng)的公鑰丹泉。比如Android系統(tǒng)中已經(jīng)內(nèi)置了所有CA機(jī)構(gòu)的根證書，也就是只要是CA機(jī)構(gòu)頒發(fā)的證書嘀掸，Android是直接信任的。
總結(jié)
HTTPS要使客戶端與服務(wù)器端的通信過程得到安全保證泉蝌，必須使用的對稱加密算法揩晴，但是協(xié)商對稱加密算法的過程，需要使用非對稱加密算法來保證安全诅愚，然而直接使用非對稱加密的過程本身也不安全劫映，會有中間人篡改公鑰的可能性，所以客戶端與服務(wù)器不直接使用公鑰泳赋，而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來保證非對稱加密過程本身的安全祖今。這樣通過這些機(jī)制協(xié)商出一個對稱加密算法，就此雙方使用該算法進(jìn)行加密解密千诬。從而解決了客戶端與服務(wù)器端之間的通信安全問題。同時因?yàn)閔ttps請求過程中需要多次加密和解密邪驮，所有其性能比http差泵三。
