圖解https演變以及各種加密解密過程
HTTP->HTTPS原因
HHTP 訪問
HTTPS 訪問
· 直接原因，如上圖缓淹，使用http和https訪問網(wǎng)站，最明顯的差別就是 使用http進(jìn)行訪問的塔逃，瀏覽器直接標(biāo)志為“不安全”網(wǎng)站讯壶，平時(shí)上網(wǎng)遇到這樣的網(wǎng)站心里都會(huì)發(fā)毛，涉及到要支付錢的應(yīng)該沒人敢隨意支付吧湾盗。
· 主要原因伏蚊，瀏覽器也不是吃飽了沒事做逼著大家改協(xié)議，主要是因?yàn)閔ttp是明文傳輸淹仑，那就相當(dāng)于在網(wǎng)絡(luò)環(huán)境里面裸奔啊丙挽，這是相當(dāng)危險(xiǎn)的，試想一下你要支付匀借，銀行卡密碼什么的被別人劫持了颜阐，你可不就gg了。因此瀏覽器提醒的行為是對(duì)用戶負(fù)責(zé)吓肋，還不改變的網(wǎng)站要么是沒錢凳怨，要么是懶，要么這個(gè)網(wǎng)站是大爺客戶愛上不上~
試想一下，http這么不安全肤舞，讓你設(shè)計(jì)一個(gè)安全的紫新，大家肯定第一反應(yīng)就是數(shù)據(jù)加密嘛，那么怎么加密李剖，來看看演變過程芒率。
對(duì)稱加密
諜戰(zhàn)劇里面兩個(gè)電臺(tái)進(jìn)行通信，發(fā)的電報(bào)都是些毫無規(guī)律的密碼文篙顺，雙方就靠著密碼本來進(jìn)行破譯情報(bào)偶芍，密碼本都靠著地下工作的間諜特工們進(jìn)行傳遞，這個(gè)過程對(duì)應(yīng)到網(wǎng)絡(luò)傳遞消息就如下圖：
WechatIMG74
采用單鑰密碼系統(tǒng)的加密方法德玫，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密匪蟀，這種加密方法稱為對(duì)稱加密，也稱為單密鑰加密宰僧。我這里只講思路模型材彪，具體加密解密算法過程不做解釋。對(duì)應(yīng)到網(wǎng)絡(luò)應(yīng)用大家可以看圖參照琴儿，這是理想情況下段化，你好我好大家好，但是會(huì)出現(xiàn)兩個(gè)問題：
· 第一步的密碼本傳遞過程造成，如果特工里面出現(xiàn)了叛徒穗泵，叛徒得到了密碼本照抄一份給他的組織，然后不動(dòng)神色的繼續(xù)傳遞密碼本谜疤，那么接下來電臺(tái)之間的密文傳遞在敵軍組織眼里就跟明文沒什么區(qū)別了，對(duì)應(yīng)到網(wǎng)絡(luò)中秘鑰被黑客截取的過程现诀。
· 密碼本管理問題夷磕，電臺(tái)每天要負(fù)責(zé)那么多的信息傳遞，為了安全又不可能所有地方發(fā)來的電報(bào)都用一把密碼本破譯仔沿，那樣一旦密碼本泄漏整個(gè)被一鍋端了坐桩，因此對(duì)應(yīng)到網(wǎng)絡(luò)應(yīng)用中，就是服務(wù)器端需要為每個(gè)用戶單獨(dú)生成一個(gè)秘鑰并且管理封锉，互聯(lián)網(wǎng)中客戶如此多绵跷，秘鑰的管理代價(jià)就會(huì)很大，web服務(wù)場景肯定是行不通的成福。
常見的對(duì)稱加密算法有DES碾局、3DES、Blowfish奴艾、IDEA净当、RC4、RC5、RC6和AES像啼，感興趣的可以自行百度俘闯。
非對(duì)稱加密
玩歸玩鬧歸鬧，別拿安全開玩笑忽冻，有一說一真朗，“野狼disco”是首不錯(cuò)的歌
過程說明： 非對(duì)稱加密主要解決安全問題，客戶端和服務(wù)器各自生成一對(duì)秘鑰對(duì)僧诚，私鑰自己保管遮婶，公鑰暴露給對(duì)方，然后傳輸加密用對(duì)方給的公鑰進(jìn)行加密振诬，對(duì)方有自己公鑰的鑰匙蹭睡，以此達(dá)到解密數(shù)據(jù)的目的。各自保管一份私鑰赶么，不需要傳輸肩豁，就不會(huì)出現(xiàn)密碼本泄漏的情況.
公鑰與私鑰是一對(duì)，如果用公鑰對(duì)數(shù)據(jù)進(jìn)行加密辫呻，只有用對(duì)應(yīng)的私鑰才能解密清钥。因?yàn)榧用芎徒饷苁褂玫氖莾蓚€(gè)不同的密鑰，所以這種算法叫作非對(duì)稱加密算法放闺。
這種方式祟昭，服務(wù)器只需要保存自己的秘鑰就可以，管理秘鑰問題得到解決怖侦，加密數(shù)據(jù)的目的也達(dá)到了篡悟，但是還會(huì)有問題：
· 最大的問題出現(xiàn)在了第一步公鑰傳遞上面，我怎么信任你這把公鑰呢匾寝？要知道這個(gè)地方還是在裸奔啊辛友，如果出現(xiàn)了“中間dog”故意使壞导盅，破解不了你但是要搞殘你环凿，將雙方發(fā)送給對(duì)方的公鑰篡改讥电，冒充成隨便一個(gè)公鑰，那么雙方用這個(gè)假公鑰加密對(duì)方永遠(yuǎn)都解密不出來數(shù)據(jù)猜年。
· 第二是加密和解密花費(fèi)時(shí)間長抡锈、速度慢，只適合對(duì)少量數(shù)據(jù)進(jìn)行加密乔外。
https全過程 = 對(duì)稱加密 + 非對(duì)稱加密 + 數(shù)字證書
現(xiàn)實(shí)世界中床三，解決信任問題一般是“權(quán)威機(jī)構(gòu)”或者權(quán)威人物背書，https就是這樣杨幼，操作系統(tǒng)里面一開始就內(nèi)置了各大數(shù)字認(rèn)證權(quán)威機(jī)構(gòu)(Certificate Authority勿璃，縮寫為CA)的數(shù)字證書，作為系統(tǒng)根證書，macOS可以通過【鑰匙串->系統(tǒng)根證書】查看补疑，如圖：
· 服務(wù)器發(fā)送的證書里(chrome瀏覽器點(diǎn)擊地址欄最左邊歧沪，能看到證書的詳細(xì)內(nèi)容)，數(shù)字證書主要包含了以下幾個(gè)內(nèi)容:
- 證書發(fā)布機(jī)構(gòu)莲组，即哪家CA
- 證書的有效期
- 證書的所有者诊胞，以及相關(guān)的證書的域名、公司名等等
- 公鑰
- 證書簽名
· 客戶端校驗(yàn)證書的可信性锹杈，可以簡單分為下面幾步：
- 校驗(yàn)證書聲明的CA在操作系統(tǒng)的根證書里面
- 校驗(yàn)證書在有效期內(nèi)
- 校驗(yàn)證書的簽名撵孤，這一步能夠證明此證書確實(shí)是由CA機(jī)構(gòu)頒發(fā)的。
· 其中校驗(yàn)證書簽名是關(guān)鍵竭望，證書簽名是網(wǎng)站申請(qǐng)證書時(shí)邪码，CA機(jī)構(gòu)對(duì)一個(gè)hash值使用CA私鑰對(duì)稱加密后的字符串。 可以用表達(dá)式表達(dá)為：
sign = encrypt(hash("證書機(jī)構(gòu)" + "證書有效期" + "證書所有者" + "公鑰"))
· 校驗(yàn)簽名的步驟:
- 客戶端從系統(tǒng)根證書中取出對(duì)應(yīng)CA的公鑰咬清，然后對(duì)簽名解密獲取到hash值闭专。
- 客戶端使用相同的方式拼接證書信息，使用相同算法得到hash值旧烧。
- 比較解密出來的hash值和客戶端拼接的hash值是否相同影钉，相同則通過。
這個(gè)過程其實(shí)完成了這么一件事情掘剪，客戶端看了一眼證書提供的信息平委，然后通過CA公鑰解密，證明了證書提供的信息是被擁有CA私鑰的機(jī)構(gòu)確認(rèn)過的(證書的簽名)夺谁，便相信了證書提供的信息廉赔。
就像現(xiàn)實(shí)生活中的票據(jù)，相信票據(jù)中的信息匾鸥，因?yàn)橛幸粋€(gè)獨(dú)一無二的機(jī)構(gòu)簽章（雖然可以偽造昂勉，但是非對(duì)稱機(jī)密的簽章是不可偽造的）
· https的流程圖如下：
解決的問題：
非對(duì)稱加密只用來傳輸密碼本，實(shí)際數(shù)據(jù)傳輸用的對(duì)稱加密扫腺，解決了非對(duì)稱加密解密速度慢的問題
CA機(jī)構(gòu)數(shù)字證書驗(yàn)證公鑰，解決公鑰傳輸?shù)男湃螁栴}
一步一步的村象，所有的問題都解決了笆环，是不是特別的nice！：裾摺躁劣！
需要指出的是，HTTPS盡管可以保護(hù)數(shù)據(jù)在傳輸環(huán)節(jié)的安全库菲，但HTTPS不是萬能的账忘，不能解決所有的安全問題。HTTPS無法解決跨站腳本XSS攻擊、跨站資源冒用CSRF鳖擒、跨站腳本跟蹤XST溉浙、SQL注入攻擊、病毒攻擊蒋荚，HTTPS依然無法解決戳稽。解決這些安全問題，需要在通信的終端采取措施來保證用戶數(shù)據(jù)安全期升。
?
??
