前言
HTTPS（全稱：HyperText Transfer Protocol over Secure Socket Layer），其實 HTTPS 并不是一個新鮮協(xié)議，Google 很早就開始啟用了搔预，初衷是為了保證數(shù)據(jù)安全资锰。 近兩年首昔，Google寡喝、Baidu、Facebook 等這樣的互聯(lián)網(wǎng)巨頭勒奇，不謀而合地開始大力推行 HTTPS预鬓， 國內外的大型互聯(lián)網(wǎng)公司很多也都已經(jīng)啟用了全站 HTTPS，這也是未來互聯(lián)網(wǎng)發(fā)展的趨勢赊颠。
為鼓勵全球網(wǎng)站的 HTTPS 實現(xiàn)格二，一些互聯(lián)網(wǎng)公司都提出了自己的要求：
1）Google 已調整搜索引擎算法劈彪，讓采用 HTTPS 的網(wǎng)站在搜索中排名更靠前；
2）從 2017 年開始顶猜，Chrome 瀏覽器已把采用 HTTP 協(xié)議的網(wǎng)站標記為不安全網(wǎng)站沧奴；
3）蘋果要求 2017 年 App Store 中的所有應用都必須使用 HTTPS 加密連接；
4）當前國內炒的很火熱的微信小程序也要求必須使用 HTTPS 協(xié)議长窄；
5）新一代的 HTTP/2 協(xié)議的支持需以 HTTPS 為基礎扼仲。
等等，因此想必在不久的將來抄淑，全網(wǎng) HTTPS 勢在必行。
概念
協(xié)議
1驰后、HTTP 協(xié)議（HyperText Transfer Protocol肆资，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協(xié)議 。
2灶芝、HTTPS 協(xié)議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS郑原， 即HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL夜涕，因此加密的詳細內容就需要 SSL犯犁，用于安全的 HTTP 數(shù)據(jù)傳輸。
如上圖所示
HTTPS 相比HTTP多了一層 SSL/TLS
SSL（Secure Socket Layer女器，安全套接字層）：1994年為 Netscape 所研發(fā)酸役，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持驾胆。
TLS（Transport LayerSecurity涣澡，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0丧诺、SSL 2.0入桂、SSL 3.0）由網(wǎng)景公司開發(fā)，1999年從 3.1 開始被 IETF 標準化并改名驳阎，發(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癞季。
加密算法
據(jù)記載劫瞳，公元前400年倘潜，古希臘人就發(fā)明了置換密碼；在第二次世界大戰(zhàn)期間志于，德國軍方啟用了“恩尼格瑪”密碼機涮因，所以密碼學在社會發(fā)展中有著廣泛的用途。
- 1伺绽、對稱加密
有流式养泡、分組兩種，加密和解密都是使用的同一個密鑰奈应。例如：DES澜掩、AES-GCM、ChaCha20-Poly1305等- 2杖挣、非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的肩榕，分別稱為：公鑰、私鑰惩妇，公鑰和算法都是公開的株汉，私鑰是保密的。非對稱加密算法性能較低歌殃，但是安全性超強乔妈，由于其加密特性，非對稱加密算法能加密的數(shù)據(jù)長度也是有限的氓皱。例如：RSA路召、DSA、ECDSA波材、 DH优训、ECDHE- 3、哈希算法
將任意長度的信息轉換為較短的固定長度的值各聘，通常其長度要比信息小得多揣非，且算法不可逆。例如：MD5躲因、SHA-1早敬、SHA-2、SHA-256等- 4大脉、數(shù)字簽名
簽名就是在信息的后面再加上一段內容（信息經(jīng)過hash后的值）搞监，可以證明信息沒有被修改過。hash值一般都會加密后（也就是簽名）再和信息一起發(fā)送镰矿，以保證這個hash值不被修改琐驴。
詳解
HTTP 訪問過程
抓包如下：
如上圖所示，HTTP請求過程中，客戶端與服務器之間沒有任何身份確認的過程绝淡，數(shù)據(jù)全部明文傳輸宙刘，“裸奔”在互聯(lián)網(wǎng)上，所以很容易遭到黑客的攻擊牢酵，如下：
可以看到悬包，客戶端發(fā)出的請求很容易被黑客截獲，如果此時黑客冒充服務器馍乙，則其可返回任意信息給客戶端布近，而不被客戶端察覺，所以我們經(jīng)常會聽到一詞“劫持”丝格，現(xiàn)象如下：
下面兩圖中撑瞧，瀏覽器中填入的是相同的URL，左邊是正確響應显蝌，而右邊則是被劫持后的響應
所以 HTTP 傳輸面臨的風險有：
（1） 竊聽風險：黑客可以獲知通信內容预伺。
（2） 篡改風險：黑客可以修改通信內容。
（3） 冒充風險：黑客可以冒充他人身份參與通信琅束。
HTTP 向 HTTPS 演化的過程
第一步：為了防止上述現(xiàn)象的發(fā)生，人們想到一個辦法：對傳輸?shù)男畔⒓用埽词购诳徒孬@算谈，也無法破解)
如上圖所示涩禀，此種方式屬于對稱加密，雙方擁有相同的密鑰然眼，信息得到安全傳輸艾船，但此種方式的缺點是：
（1）不同的客戶端、服務器數(shù)量龐大高每，所以雙方都需要維護大量的密鑰屿岂，維護成本很高
（2）因每個客戶端、服務器的安全級別不同鲸匿，密鑰極易泄露
第二步：既然使用對稱加密時爷怀，密鑰維護這么繁瑣，那我們就用非對稱加密試試
如上圖所示带欢，客戶端用公鑰對請求內容加密运授，服務器使用私鑰對內容解密，反之亦然乔煞，但上述過程也存在缺點：
（1）公鑰是公開的（也就是黑客也會有公鑰）吁朦，所以第 ④ 步私鑰加密的信息，如果被黑客截獲渡贾，其可以使用公鑰進行解密逗宜，獲取其中的內容
第三步：非對稱加密既然也有缺陷，那我們就將對稱加密，非對稱加密兩者結合起來纺讲，取其精華擂仍、去其糟粕，發(fā)揮兩者的各自的優(yōu)勢
如上圖所示
（1）第 ③ 步時刻诊，客戶端說：（咱們后續(xù)回話采用對稱加密吧防楷，這是對稱加密的算法和對稱密鑰）這段話用公鑰進行加密，然后傳給服務器
（2）服務器收到信息后则涯，用私鑰解密复局，提取出對稱加密算法和對稱密鑰后，服務器說：（好的）對稱密鑰加密
（3）后續(xù)兩者之間信息的傳輸就可以使用對稱加密的方式了
遇到的問題：
（1）客戶端如何獲得公鑰
（2）如何確認服務器是真實的而不是黑客
第四步：獲取公鑰與確認服務器身份
1粟判、獲取公鑰
（1）提供一個下載公鑰的地址亿昏，回話前讓客戶端去下載。（缺點：下載地址有可能是假的档礁；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開始時角钩，服務器把公鑰發(fā)給客戶端（缺點：黑客冒充服務器，發(fā)送給客戶端假的公鑰）
2呻澜、那有木有一種方式既可以安全的獲取公鑰递礼，又能防止黑客冒充呢？ 那就需要用到終極武器了：SSL 證書
如上圖所示羹幸，在第 ② 步時服務器發(fā)送了一個SSL證書給客戶端脊髓，SSL 證書中包含的具體內容有：
(1）證書的發(fā)布機構CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名
3、客戶端在接受到服務端發(fā)來的SSL證書時栅受，會對證書的真?zhèn)芜M行校驗将硝，以瀏覽器為例說明如下
（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操作系統(tǒng)中已內置的受信任的證書發(fā)布機構CA屏镊，與服務器發(fā)來的證書中的頒發(fā)者CA比對依疼，用于校驗證書是否為合法機構頒發(fā)
（3）如果找不到，瀏覽器就會報錯而芥，說明服務器發(fā)來的證書是不可信任的律罢。
（4）如果找到，那么瀏覽器就會從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰棍丐，然后對服務器發(fā)來的證書里面的簽名進行解密
（5）瀏覽器使用相同的hash算法計算出服務器發(fā)來的證書的hash值弟翘，將這個計算的hash值與證書中簽名做對比
（6）對比結果一致，則證明服務器發(fā)來的證書合法骄酗，沒有被冒充
（7）此時瀏覽器就可以讀取證書中的公鑰稀余，用于后續(xù)加密了
4、所以通過發(fā)送SSL證書的形式趋翻，既解決了公鑰獲取問題睛琳，又解決了黑客冒充問題，一箭雙雕，HTTPS加密過程也就此形成
所以相比HTTP师骗，HTTPS 傳輸更加安全
（1） 所有信息都是加密傳播历等，黑客無法竊聽。
（2） 具有校驗機制辟癌，一旦被篡改寒屯，通信雙方會立刻發(fā)現(xiàn)。
（3） 配備身份證書黍少，防止身份被冒充寡夹。
