本文主要內(nèi)容
- 概念
- 加密算法
- HTTPS原理
- 總結(jié)
1检诗、概念
HTTP 協(xié)議（HyperText Transfer Protocol锥余，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 媒至。
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，可以把HTTPS 理解成安全的 HTTP 協(xié)議么介。
那SSL和TLS又是什么呢?
SSL（Secure Socket Layer娜遵，安全套接字層）：1994年為 Netscape 所研發(fā)，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間壤短，為數(shù)據(jù)通訊提供安全支持魔熏。
TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL鸽扁，它最初的幾個版本（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 三個版本相赁。SSL3.0和TLS1.0由于存在安全漏洞，已經(jīng)很少被使用到慰于。TLS 1.3 改動會比較大钮科，目前還在草案階段，目前使用最廣泛的是TLS 1.1婆赠、TLS 1.2绵脯。
2、加密算法
HTTPS 協(xié)議中用了不同的加密算法休里，在此我們學(xué)習(xí)下加密算法的基礎(chǔ)知識蛆挫，加密算法有對稱加密和非對稱加密的方式。
對稱加密妙黍，有流式悴侵、分組兩種，加密和解密都是使用的同一個密鑰拭嫁。例如：DES可免、AES-GCM、ChaCha20-Poly1305等
非對稱加密做粤，加密使用的密鑰和解密使用的密鑰是不相同的浇借，分別稱為：公鑰、私鑰驮宴，公鑰和算法都是公開的逮刨，私鑰是保密的呕缭。非對稱加密算法性能較低堵泽，但是安全性超強(qiáng)修己，由于其加密特性，非對稱加密算法能加密的數(shù)據(jù)長度也是有限的迎罗。例如：RSA睬愤、DSA、ECDSA纹安、 DH尤辱、ECDHE
由此可見，使用 git 即是使用非對稱加密厢岂，我們需要在網(wǎng)頁端填寫公鑰值光督。
除加密方法外，還有其它方法可以在一定程度上保證安全性
- 哈希算法塔粒，將任意長度的信息轉(zhuǎn)換為較短的固定長度的值结借，通常其長度要比信息小得多，且算法不可逆卒茬。例如：MD5船老、SHA-1、SHA-2圃酵、SHA-256 等
此前闡述過 android apk 簽名及驗證過程柳畔，里邊就有涉及 SHA-256 算法等，通過此算法可以驗證信息有沒有被修改郭赐，如果修改了薪韩，哈希之后得到的值肯定會變化，所以哈希算法可以用于鑒定信息是否被篡改捌锭。
- 數(shù)字簽名躬存，保證信息傳輸?shù)耐暾浴l(fā)送者的身份認(rèn)證舀锨、防止交易中的抵賴發(fā)生岭洲。 數(shù)字簽名技術(shù)是將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接收者坎匿。 接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息盾剩，然后用對收到的原文產(chǎn)生一個摘要信息，與解密的摘要信息對比替蔬。
3告私、HTTPS原理
HTTP 協(xié)議是明文協(xié)議，使用它通信承桥，存在三個風(fēng)險：
- 竊聽風(fēng)險（eavesdropping）：第三方可以獲知通信內(nèi)容驻粟。
- 篡改風(fēng)險（tampering）：第三方可以修改通信內(nèi)容。
- 冒充風(fēng)險（pretending）：第三方可以冒充他人身份參與通信。
為了解決這三個問題蜀撑，HTTPS 協(xié)議可以說是煞費(fèi)苦心挤巡。
第1步，既然明文協(xié)議不安全酷麦，那就執(zhí)行加密通信
如上圖所示矿卑，此種方式屬于對稱加密，雙方擁有相同的密鑰沃饶，信息得到安全傳輸母廷，但此種方式的缺點是：
- 不同的客戶端、服務(wù)器數(shù)量龐大糊肤，所以雙方都需要維護(hù)大量的密鑰琴昆，維護(hù)成本很高
- 因每個客戶端、服務(wù)器的安全級別不同馆揉，密鑰極易泄露
第2步椎咧，既然對稱加密不行，我們換成非對稱加密試試：
如上圖所示把介，客戶端使用公鑰發(fā)送主動勤讽，服務(wù)端使用私鑰解密請求，并且將響應(yīng)內(nèi)容加密拗踢，發(fā)給客戶端脚牍。但上述過程也存在缺點：
- 公鑰是公開的（也就是黑客也會有公鑰），所以第 ④ 步私鑰加密的信息巢墅，如果被黑客截獲诸狭，其可以使用公鑰進(jìn)行解密，獲取其中的內(nèi)容
第3步君纫，非對稱加密既然也有缺陷驯遇，那我們就將對稱加密，非對稱加密兩者結(jié)合起來蓄髓，取其精華叉庐、去其糟粕，發(fā)揮兩者的各自的優(yōu)勢
如上圖所示：
第 ③ 步時会喝，客戶端說：（咱們后續(xù)回話采用對稱加密吧陡叠，這是對稱加密的算法和對稱密鑰）這段話用公鑰進(jìn)行加密，然后傳給服務(wù)器
服務(wù)器收到信息后肢执，用私鑰解密枉阵，提取出對稱加密算法和對稱密鑰后，服務(wù)器說：（好的）對稱密鑰加密
后續(xù)兩者之間信息的傳輸就可以使用對稱加密的方式了
這里存在兩個問題预茄，客戶端如何獲取公鑰呢兴溜？如何確定這是真實的服務(wù)器而不是黑客呢？如果客戶端到某個地址去下載公鑰，下載地址有可能是假的拙徽，而且每次對話之前還要去下載刨沦，很麻煩。如果是服務(wù)器主動將公鑰交給客戶端斋攀，客戶端怎么確定服務(wù)器是真實的而不是黑客冒充的呢？
為了解決公鑰問題梧田，SSL證書派上用場了淳蔼。
在第2步中，服務(wù)器會將一個SSL證書發(fā)送給客戶端裁眯，SSL證書審核嚴(yán)格而且還是要收費(fèi)的鹉梨，它不會被冒充〈┪龋客戶端接收證書后存皂，會對證書進(jìn)行驗證，證書驗證為真后逢艘，客戶端會從SSL證書中讀取出一個公鑰旦袋，用于接下來的非對稱加密。在非對稱加密中它改，客戶端將對稱加密的密鑰發(fā)給服務(wù)器疤孕，服務(wù)器接收后，后續(xù)的通信就可以使用對稱加密了央拖。
SSL證書的驗證過程：
（1）首先瀏覽器讀取證書中的證書所有者祭阀、有效期等信息進(jìn)行一一校驗
（2）瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA，與服務(wù)器發(fā)來的證書中的頒發(fā)者CA比對鲜戒，用于校驗證書是否為合法機(jī)構(gòu)頒發(fā)
（3）如果找不到专控，瀏覽器就會報錯，說明服務(wù)器發(fā)來的證書是不可信任的遏餐。
（4）如果找到伦腐，那么瀏覽器就會從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰，然后對服務(wù)器發(fā)來的證書里面的簽名進(jìn)行解密
（5）瀏覽器使用相同的hash算法計算出服務(wù)器發(fā)來的證書的hash值失都，將這個計算的hash值與證書中簽名做對比
（6）對比結(jié)果一致蔗牡，則證明服務(wù)器發(fā)來的證書合法，沒有被冒充
4嗅剖、總結(jié)
HTTPS協(xié)議比HTTP協(xié)議安全可靠辩越，整個過程中黑客也沒有辦法監(jiān)聽或者篡改、冒充了信粮。
（1） 所有信息都是加密傳播黔攒，黑客無法竊聽。
（2） 具有校驗機(jī)制，一旦被篡改督惰，通信雙方會立刻發(fā)現(xiàn)不傅。
（3） 配備身份證書，防止身份被冒充赏胚。
另外需要提一點的就是TCP協(xié)議和 HTTP 及 HTTPS 協(xié)議的關(guān)系访娶，TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸觉阅，而HTTP是應(yīng)用層協(xié)議崖疤，主要解決如何包裝數(shù)據(jù)。
關(guān)于TCP/IP和HTTP協(xié)議的關(guān)系典勇，網(wǎng)絡(luò)有一段比較容易理解的介紹：“我們在傳輸數(shù)據(jù)時劫哼，可以只使用（傳輸層）TCP/IP協(xié)議，但是那樣的話割笙，如果沒有應(yīng)用層权烧，便無法識別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義伤溉，則必須使用到應(yīng)用層協(xié)議般码，應(yīng)用層協(xié)議有很多，比如HTTP乱顾、FTP侈询、TELNET等。
HTTPS 協(xié)議在android應(yīng)用時糯耍，與 HTTP 協(xié)議有一些差別扔字，注意這些即可。
