協(xié)議
1剔氏、HTTP 協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 竹祷。
2谈跛、HTTPS 協(xié)議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層塑陵，HTTPS 的安全基礎(chǔ)是 SSL感憾，因此加密的詳細(xì)內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS
SSL（Secure Socket Layer阻桅，安全套接字層）：1994年為 Netscape 所研發(fā)凉倚，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持嫂沉。
TLS（Transport Layer Security稽寒，傳輸層安全）：其前身是 SSL，它最初的幾個(gè)版本（SSL 1.0趟章、SSL 2.0杏糙、SSL 3.0）由網(wǎng)景公司開發(fā)，1999年從 3.1 開始被 IETF 標(biāo)準(zhǔn)化并改名蚓土，發(fā)展至今已經(jīng)有 TLS 1.0宏侍、TLS 1.1、TLS 1.2 三個(gè)版本蜀漆。SSL3.0和TLS1.0由于存在安全漏洞谅河，已經(jīng)很少被使用到。TLS 1.3 改動會比較大确丢，目前還在草案階段绷耍，目前使用最廣泛的是TLS 1.1、TLS 1.2鲜侥。
加密算法：
據(jù)記載褂始，公元前400年，古希臘人就發(fā)明了置換密碼剃毒；在第二次世界大戰(zhàn)期間病袄，德國軍方啟用了“恩尼格瑪”密碼機(jī)，所以密碼學(xué)在社會發(fā)展中有著廣泛的用途赘阀。
1益缠、對稱加密
有流式、分組兩種基公，加密和解密都是使用的同一個(gè)密鑰幅慌。
例如：DES、AES-GCM轰豆、ChaCha20-Poly1305等
2胰伍、非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰酸休、私鑰骂租，公鑰和算法都是公開的，私鑰是保密的斑司。非對稱加密算法性能較低渗饮，但是安全性超強(qiáng)，由于其加密特性，非對稱加密算法能加密的數(shù)據(jù)長度也是有限的互站。
例如：RSA私蕾、DSA、ECDSA胡桃、 DH踩叭、ECDHE
3、哈希算法
將任意長度的信息轉(zhuǎn)換為較短的固定長度的值翠胰，通常其長度要比信息小得多容贝，且算法不可逆。
例如：MD5亡容、SHA-1嗤疯、SHA-2冤今、SHA-256 等
4闺兢、數(shù)字簽名
簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過hash后的值），可以證明信息沒有被修改過戏罢。hash值一般都會加密后（也就是簽名）再和信息一起發(fā)送屋谭，以保證這個(gè)hash值不被修改。
詳解
一龟糕、HTTP 訪問過程
抓包如下：
如上圖所示桐磁，HTTP請求過程中，客戶端與服務(wù)器之間沒有任何身份確認(rèn)的過程讲岁，數(shù)據(jù)全部明文傳輸我擂，“裸奔”在互聯(lián)網(wǎng)上，所以很容易遭到黑客的攻擊缓艳，如下：
可以看到校摩，客戶端發(fā)出的請求很容易被黑客截獲，如果此時(shí)黑客冒充服務(wù)器阶淘，則其可返回任意信息給客戶端衙吩，而不被客戶端察覺，所以我們經(jīng)常會聽到一詞“劫持”溪窒，現(xiàn)象如下：
下面兩圖中坤塞，瀏覽器中填入的是相同的URL，左邊是正確響應(yīng)澈蚌，而右邊則是被劫持后的響應(yīng)
所以 HTTP 傳輸面臨的風(fēng)險(xiǎn)有：
（1） 竊聽風(fēng)險(xiǎn)：黑客可以獲知通信內(nèi)容摹芙。
（2） 篡改風(fēng)險(xiǎn)：黑客可以修改通信內(nèi)容。
（3） 冒充風(fēng)險(xiǎn)：黑客可以冒充他人身份參與通信宛瞄。
二浮禾、HTTP 向 HTTPS 演化的過程
第一步：為了防止上述現(xiàn)象的發(fā)生，人們想到一個(gè)辦法：對傳輸?shù)男畔⒓用埽词购诳徒孬@，也無法破解）
如上圖所示伐厌，此種方式屬于對稱加密承绸，雙方擁有相同的密鑰，信息得到安全傳輸挣轨，但此種方式的缺點(diǎn)是：
（1）不同的客戶端军熏、服務(wù)器數(shù)量龐大，所以雙方都需要維護(hù)大量的密鑰卷扮，維護(hù)成本很高
（2）因每個(gè)客戶端荡澎、服務(wù)器的安全級別不同，密鑰極易泄露
第二步：既然使用對稱加密時(shí)晤锹，密鑰維護(hù)這么繁瑣摩幔，那我們就用非對稱加密試試
如上圖所示，客戶端用公鑰對請求內(nèi)容加密鞭铆，服務(wù)器使用私鑰對內(nèi)容解密或衡，反之亦然，但上述過程也存在缺點(diǎn)：
（1）公鑰是公開的（也就是黑客也會有公鑰）车遂，所以第 ④ 步私鑰加密的信息封断，如果被黑客截獲，其可以使用公鑰進(jìn)行解密舶担，獲取其中的內(nèi)容
第三步：非對稱加密既然也有缺陷坡疼，那我們就將對稱加密，非對稱加密兩者結(jié)合起來衣陶，取其精華柄瑰、去其糟粕，發(fā)揮兩者的各自的優(yōu)勢
如上圖所示
（1）第 ③ 步時(shí)剪况，客戶端說：（咱們后續(xù)回話采用對稱加密吧教沾，這是對稱加密的算法和對稱密鑰）這段話用公鑰進(jìn)行加密，然后傳給服務(wù)器
（2）服務(wù)器收到信息后拯欧，用私鑰解密详囤，提取出對稱加密算法和對稱密鑰后，服務(wù)器說：（好的）對稱密鑰加密
（3）后續(xù)兩者之間信息的傳輸就可以使用對稱加密的方式了
遇到的問題：
（1）客戶端如何獲得公鑰
（2）如何確認(rèn)服務(wù)器是真實(shí)的而不是黑客
第四步：獲取公鑰與確認(rèn)服務(wù)器身份
1镐作、獲取公鑰
（1）提供一個(gè)下載公鑰的地址藏姐，回話前讓客戶端去下載。（缺點(diǎn)：下載地址有可能是假的该贾；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開始時(shí)羔杨，服務(wù)器把公鑰發(fā)給客戶端（缺點(diǎn)：黑客冒充服務(wù)器，發(fā)送給客戶端假的公鑰）
2杨蛋、那有木有一種方式既可以安全的獲取公鑰兜材，又能防止黑客冒充呢理澎？ 那就需要用到終極武器了：SSL 證書（申購）
如上圖所示，在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書給客戶端曙寡，SSL 證書中包含的具體內(nèi)容有：
（1）證書的發(fā)布機(jī)構(gòu)CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名
………
3糠爬、客戶端在接受到服務(wù)端發(fā)來的SSL證書時(shí)，會對證書的真?zhèn)芜M(jìn)行校驗(yàn)举庶，以瀏覽器為例說明如下：
（1）首先瀏覽器讀取證書中的證書所有者执隧、有效期等信息進(jìn)行一一校驗(yàn)
（2）瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA，與服務(wù)器發(fā)來的證書中的頒發(fā)者CA比對户侥，用于校驗(yàn)證書是否為合法機(jī)構(gòu)頒發(fā)
（3）如果找不到镀琉，瀏覽器就會報(bào)錯(cuò)，說明服務(wù)器發(fā)來的證書是不可信任的蕊唐。
（4）如果找到屋摔，那么瀏覽器就會從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰，然后對服務(wù)器發(fā)來的證書里面的簽名進(jìn)行解密
（5）瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來的證書的hash值替梨，將這個(gè)計(jì)算的hash值與證書中簽名做對比
（6）對比結(jié)果一致钓试，則證明服務(wù)器發(fā)來的證書合法，沒有被冒充
（7）此時(shí)瀏覽器就可以讀取證書中的公鑰耙替，用于后續(xù)加密了
4亚侠、所以通過發(fā)送SSL證書的形式曹体，既解決了公鑰獲取問題俗扇，又解決了黑客冒充問題，一箭雙雕箕别，HTTPS加密過程也就此形成
所以相比HTTP铜幽，HTTPS 傳輸更加安全
（1） 所有信息都是加密傳播，黑客無法竊聽串稀。
（2） 具有校驗(yàn)機(jī)制除抛，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)母截。
（3） 配備身份證書到忽，防止身份被冒充。
Https通信詳解
客戶端發(fā)出握手請求(Client Hello)清寇，包含以下信息：
- 支持的協(xié)議版本喘漏，比如TLS 1.0版。
- 一個(gè)客戶端生成的隨機(jī)數(shù)(random_1)华烟，這個(gè)隨機(jī)數(shù)既需要客戶端保存又需要發(fā)送給服務(wù)器翩迈。
- 支持的加密方法，比如RSA公鑰加密盔夜。
- 支持的壓縮方法。
服務(wù)器回復(fù)(Server Hello)墙基，包含以下信息：
- 確認(rèn)使用的加密通信協(xié)議版本晨川，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致妥泉，服務(wù)器關(guān)閉加密通信。
- 一個(gè)服務(wù)器生成的隨機(jī)數(shù)(random_2)洞坑。
- 確認(rèn)使用的加密方法涛漂，比如RSA公鑰加密。
- 服務(wù)器證書检诗。
- 如果服務(wù)器需要確認(rèn)客戶端的身份匈仗，就會再包含一項(xiàng)請求，要求客戶端提供”客戶端證書”逢慌。比如悠轩，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰攻泼，里面就包含了一張客戶端證書火架。
客戶端回應(yīng)，包含以下步驟：
- 驗(yàn)證服務(wù)器證書的合法性忙菠，證書合法性包括：證書是否過期何鸡，發(fā)行服務(wù)器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”牛欢，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配骡男。如果合法性驗(yàn)證沒有通過，通訊將斷開傍睹；
- 客戶端使用一些加密算法(例如：RSA,Diffie-Hellman)產(chǎn)生一個(gè)48個(gè)字節(jié)的Key隔盛，這個(gè)Key叫PreMaster Secret。該P(yáng)reMaster Secret用服務(wù)器公鑰加密傳送拾稳，防止被竊聽吮炕。
- 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送访得。
- 客戶端握手結(jié)束通知龙亲，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值悍抑，用來供服務(wù)器校驗(yàn)鳄炉。
- 如果前一步，服務(wù)器要求客戶端證書传趾，客戶端會在這一步發(fā)送證書及相關(guān)信息迎膜。
服務(wù)器回應(yīng)，服務(wù)器通過上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret)浆兰，計(jì)算出本次會話的『會話密鑰(session secret)』磕仅，然后向客戶端發(fā)送下面信息
- 編碼改變通知珊豹，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
- 服務(wù)器握手結(jié)束通知榕订，表示服務(wù)器的握手階段已經(jīng)結(jié)束店茶。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)劫恒。
至此贩幻，服務(wù)器和客戶端的握手階段全部結(jié)束，接下來两嘴，客戶端與服務(wù)器進(jìn)入加密通信丛楚，就完全是使用普通的HTTP協(xié)議，只不過用『會話密鑰(session secret)』對內(nèi)容做對稱加密憔辫。
PreMaster Secret 說明
PreMaster secret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的趣些。它將用來跟服務(wù)端和客戶端在Hello階段產(chǎn)生的隨機(jī)數(shù)結(jié)合在一起生成Master secret。在客戶端使用服務(wù)單的公鑰對PreMaster secret進(jìn)行加密之后傳送給服務(wù)端贰您，服務(wù)端將使用私鑰進(jìn)行解密得到PreMaster secret坏平。也就是說服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機(jī)數(shù)。
關(guān)于Master Secret的計(jì)算
至于為什么一定要用三個(gè)隨機(jī)數(shù)锦亦，來生成Master Secret舶替，由于SSL協(xié)議中證書是靜態(tài)的，因此需要引入一種隨機(jī)因素來保證協(xié)商出來的密鑰的隨機(jī)性杠园。SSL協(xié)議不信任每個(gè)主機(jī)都能生成完全隨機(jī)的隨機(jī)數(shù)顾瞪，所以這里需要服務(wù)器和客戶端共生成3個(gè)隨機(jī)數(shù)，每增加一個(gè)自由度返劲，隨機(jī)性就會相應(yīng)增加玲昧。
同時(shí)需要注意前兩個(gè)隨機(jī)數(shù)都是明文傳輸?shù)模`聽者是可以輕易獲取到的篮绿，只有最后一個(gè) PreMaster Secret 是加密傳輸?shù)模挥袚碛蟹?wù)器私鑰才能解密吕漂，一旦 PreMaster Secret 泄露亲配，那么本次通信就就完全可被破解了。
對稱加密 & 非對稱加密
HTTPS 的通信過程中只在握手階段使用了非對稱加密惶凝，后面的通信過程均使用的對稱加密吼虎。盡管非對稱加密相比對稱加密更加安全，但也存在兩個(gè)明顯缺點(diǎn)：
- CPU 計(jì)算資源消耗非常大苍鲜。一次完全 TLS 握手思灰，密鑰交換時(shí)的非對稱解密計(jì)算量占整個(gè)握手過程的 90% 以上。而對稱加密的計(jì)算量只相當(dāng)于非對稱加密的 0.1%混滔，如果應(yīng)用層數(shù)據(jù)也使用非對稱加解密洒疚，性能開銷太大歹颓，無法承受。
- 非對稱加密算法對加密內(nèi)容的長度有限制油湖，不能超過公鑰長度巍扛。比如現(xiàn)在常用的公鑰長度是 2048 位，意味著待加密內(nèi)容不能超過 256 個(gè)字節(jié)乏德。
所以公鑰加密目前只能用來作密鑰交換或者內(nèi)容簽名撤奸，不適合用來做應(yīng)用層傳輸內(nèi)容的加解密。
非對稱密鑰交換算法是整個(gè) HTTPS 得以安全的基石喊括，充分理解非對稱密鑰交換算法是理解 HTTPS 協(xié)議和功能的關(guān)鍵胧瓜。
安全性
針對 HTTPS 的攻擊最主要的就是 SSL 劫持攻擊，其分為兩種：
HTTPS 替換為 HTTP
這種方式就是攻擊者充當(dāng)中間人和服務(wù)器通信郑什，然后把相應(yīng)的通信內(nèi)容通過 HTTP 協(xié)議發(fā)送給客戶端贷痪，由于 HTTP 協(xié)議是未加密的，于是就可以截獲用戶的訪問數(shù)據(jù)蹦误。
這種攻擊方式比較簡單劫拢，通過代理，可以很容易的把 HTTPS 變成 HTTP强胰，這個(gè)一方面需要用戶留意網(wǎng)站是否有從 HTTPS 跳轉(zhuǎn)到 HTTP 的行為舱沧，另一方面服務(wù)器也可以通過配置將所有HTTP的請求強(qiáng)制轉(zhuǎn)移到HTTPS上。
HTTPS 劫持
這種方式攻擊者為了獲得 HTTPS 的明文傳輸內(nèi)容偶洋，需要充當(dāng)中間人熟吏，替換服務(wù)器發(fā)給用戶的包含公鑰的證書。攻擊者既和用戶之間建立了 HTTPS 鏈接玄窝，又和服務(wù)器建立了 HTTPS 鏈接牵寺。
在上面握手建立的過程中，由于用戶的公鑰是攻擊者生成的恩脂，所以攻擊者可以輕易獲得握手中的數(shù)據(jù)帽氓。也就可以獲取到和用戶通信過程中的對稱加密的密鑰，攻擊者可以通過密鑰獲取用戶發(fā)送的數(shù)據(jù)俩块，同時(shí)在使用和服務(wù)器通信的密鑰加密后再發(fā)送給服務(wù)器黎休。
這種攻擊方式也有一個(gè)明顯的問題就是攻擊者生成的證書幾乎是不可能被用戶信任的，在這種情況下玉凯，用戶瀏覽器通常會提示該網(wǎng)站的證書不可信势腮，是否繼續(xù)訪問，這已經(jīng)對用戶進(jìn)行了一個(gè)明顯的警告了漫仆。
另外我們也可以通過這種對基于 HTTPS 的通信進(jìn)行抓包分析捎拯。Mac 平臺著名的抓包工具 Charles 就是基于這種方式，首先要求你信任一個(gè)它的證書盲厌，然后自己充當(dāng)中間人對你與某個(gè)服務(wù)器的 HTTPS 通信進(jìn)行抓包分析署照。
總結(jié)
Http請求是明文通訊的祸泪，所有信息可以通過中間人，代理一覽無遺藤树， 所以我們需要一種加密后的通訊機(jī)制浴滴， 探索過程中有下面幾種方案：
- 對稱加密，客戶端和服務(wù)器端都維護(hù)相同的密鑰岁钓，對內(nèi)容進(jìn)行加密解密升略，缺點(diǎn)是雙方都需要維護(hù)大量的密鑰，維護(hù)成本很高屡限， 而且他們的安全性不同品嚣，很容易就會泄漏。
- 非對稱加密钧大，客戶端使用公鑰加密內(nèi)容翰撑，服務(wù)器使用私鑰解密，缺點(diǎn)是客戶端的公鑰是公開的啊央，很容易暴露給黑客眶诈。
- 非對稱加密和對稱加密結(jié)合：
客戶端發(fā)出握手請求(Client Hello)：
- 支持的協(xié)議版本，比如TLS 1.0版瓜饥。
- 一個(gè)客戶端生成的隨機(jī)數(shù)(random_1)
- 支持的加密方法逝撬，比如RSA公鑰加密。
服務(wù)器回復(fù)(Server Hello)：
- 確認(rèn)協(xié)議版本乓土， 比如TLS 1.0版宪潮。
- 生成一個(gè)隨機(jī)數(shù)random_2，發(fā)給客戶端
- 確定加密方法趣苏，比如RSA
- 服務(wù)器證書狡相。（包括公鑰，證書各種信息）
客戶端回應(yīng)：
- 驗(yàn)證證書各種有效性食磕，包括證書有效期尽棕，域名，公鑰是否正確
- 告訴服務(wù)器端以后對話使用對稱加密芬为。
- 使用一些加密算法(例如：RSA,Diffie-Hellman) 生成一個(gè)PreMaster Secret
- 使用公鑰加密PreMaster Secret等信息萄金，發(fā)送給服務(wù)器端。（也就是這里使用了非對稱加密）
服務(wù)器端回應(yīng)
- 收到信息后用私鑰解密（也就是這里使用了非對稱加密）
- 服務(wù)器通過上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret)媚朦，計(jì)算出本次會話的『會話密鑰(session secret)』
- 服務(wù)器端開始用session secret開始對稱加密返回加密方法和密鑰發(fā)送給客戶端
