為什么需要 HTTPS?
我們知道 HTTP 是一個純文本傳輸協議，對傳輸過程中的數據包不進行加密，是明文傳輸，那這樣的話對於介於在發送端和接收端之間的任何
一個節點都能知道傳輸的內容，這些節點可能是路由器、代理等。
一個比較常見的例子：用戶完善個人信息。用戶輸入需要填寫的資料，這些資料中可能包含一些個人居住地址、手機號碼等一些比較隱私的數據
，如果采用的是 HTTP 協議，只需要在代理服務器上做點手腳就可以拿到用戶的相關資料數據。
HTTPS 是如何保障安全的？
HTTPS 其實是 HTTP 的升級版，被稱為安全傳輸協議。我們知道 HTTP 是應用層協議，而在 HTTP 之下的是 TCP 傳輸協議，TCP 主要負責傳輸
數據，而 HTTP 定義了如何包裝數據，也就是 HTTP 將包裝好后的數據包打包給 TCP 讓其幫忙進行傳輸。那么 HTTPS 相較於 HTTP 有哪些不一樣
的地方呢？其實在 HTTP 和 TCP 之間多了一層加密層 SSL/TLS。
SSL 和 TLS 是類似的東西，SSL 是一個加密套件，對 HTTP 打包的數據進行加密。TLS 是 SSL 的升級版本，現在說到的 HTTPS 加密套件基本上
指的就是 TLS。
傳輸加密的流程
原先是 HTTP 應用層將數據打包給 TCP進行傳輸，現在應用層需要將數據先傳給 SSL/TLS 進行加密，然后再傳給 TCP。
HTTPS 怎么加密數據的？
常見的加密手段有對稱加密和非對稱加密。
對稱加密：
指的是，加密數據和解密數據用的是同一個密鑰。對稱加密的優點在於加密、解密效率比較高。缺點在於發送方和接收方公用一把密鑰，如果這個密鑰
泄露了數據依然是不安全的。
非對稱加密：
指的是，加密數據用的密鑰和解密數據用的密鑰是不一樣的，分為公鑰(Public)和私鑰(Private)，公鑰是公開的，相對的私鑰是非公開的密鑰，這里有一點
需要注意，公鑰加密的數據可以用私鑰解開，同樣使用私鑰加密的數據也能通過公鑰解開。
一個關於非對稱加密的例子：
假設小明是某個知名網站 ZH 的用戶，ZH 處於安全考慮在小明登陸的地方使用了非對稱加密。小明在輸入帳號、密碼然后點擊登陸。然后瀏覽器通過公鑰對
小明的帳號密碼進行加密，並向 ZH 發送登陸請求，ZH 通過私鑰對數據解密，並進行驗證，驗證通過后將小明的個人信息再次通過私鑰加密，傳輸回瀏覽器，
。瀏覽器再使用公鑰解密，並展示給小明。
前面說過公鑰和私鑰可以相互將對方加密的數據解開，而公鑰又是公開的，如果中間代理獲得公鑰，那么可以很容易的將小明的數據解開，所以，非對稱
加密只能保證單向數據傳輸的安全性。
這里有兩個問題 1：如何獲取公鑰？ 2：數據傳輸僅單向安全
1：如何獲取公鑰？
這里牽涉到兩個非常重要的概念：證書、CA(證書頒發機構)
證書，可以理解為一個站點的身份證，這個身份證里面包含了很多信息，其中就有公鑰。
當我們訪問 ZH 的時候，ZH 就會把證書頒發給瀏覽器，告訴瀏覽器訪問 ZH 的時候使用這個證書里面的公鑰對數據加密，這里又會有一個問題，證書是哪來的
？這個就需要 CA 了。
CA(證書頒發機構)，網站在建站之初會向 CA 提交申請，當申請審核通過后，就會給網站頒發證書，用戶訪問網站的時候，網站將證書頒發給用戶(其實是給到
瀏覽器，用戶是無感知的)。
到這里我們已經知道了證書和公鑰都是怎么來的了。
2：數據傳輸僅單向安全
上面我們說到通過私鑰加密的數據也可以用公鑰解開，那這樣表明網站傳給用戶的數據也是不安全的，這時候我們會想既然 HTTPS 也是不能完全保證數據的安
全傳輸，那么為什么現在對 HTTPS 的呼聲也很高呢？因為，HTTPS 可並不是僅僅只使用了非對稱加密它還結合使用了其他手段，比如使用了對稱加密來確保授權、
加密傳輸的效率、安全性。
概括的來說，整個簡化版的加密通信的流程是這樣的：
1.小明訪問 ZH，ZH 將自己的證書給到小明(其實是給到瀏覽器，用戶在這里對這個過程是無感知的)
2.瀏覽器從證書中拿到 ZH 的公鑰 A
3.瀏覽器生成一個只有自己知道的對稱密鑰 B，使用公鑰 A 加密，加密的數據包含對稱密鑰 B，並傳給 ZH(這個過程是有一個協商的，這里便於理解簡化了)
4.ZH 通過私鑰去解密，拿到對稱密鑰 B
5.瀏覽器、ZH 之后的數據通信，都是使用對稱密鑰 B 進行加密
注意：對於每一個訪問 ZH 的用戶，生成的對稱密鑰 B 是不一樣的，比如說小明、小花、小華可能生成的就是B1、B2、B3
證書可能存在哪些問題？
簡單的了解了 HTTPS 加密通信的流程后，我們會想如何保證證書是合法有效的呢？
證書非法可能會有兩種情況：
1.證書是偽造的，壓根不是 CA 頒發的
2.證書被篡改過，比如說將證書中的公鑰給替換了
示例：
假設，小明登陸 ZH 網站，小明的請求先到了代理服務器上，代理服務器再將請求轉發到授權服務器，假如，有一天代理服務器被入侵了，將小名的請求攔截了，
同時，返回了一個非法的證書，然后小明(瀏覽器)相信了，那么小明的數據將再次不安全，那么，是通過什么機制防止這樣的事情發生的呢？
我們先來看一下證書都包含哪些內容，這樣我們就可以知道防護措施了。
證書簡介
我們先看一下什么是數字證書和摘要，這兩個是證書防偽非常關鍵的點。
數字簽名與摘要：
簡單的說，摘要就是對傳輸的內容，通過 hash 算法計算出一段固定長度的串，然后再通過 CA 的私鑰對這段摘要加密，加密后得到的結果就是數字簽名。
明文->通過 hash 算法->摘要->CA 私鑰->數字簽名
現在我們來了解一下證書中都包含哪些內容，證書的內容非常多，我們需要關注的點有幾個：
1.證書包含了頒發證書機構的名字
2.證書本身的數字簽名(用 CA 私鑰生成)
3.證書持有者的公鑰
4.證書簽名用到的 hash 算法
有2點需要注意：
1.CA 有自己的證書，被稱為 "根證書"，這個"根證書"是用來證明 CA 自己的，本質是一份普通的數字證書
2.瀏覽器通常會內置大多數主流權威的 CA 的根證書
如何辨別非法證書：
1.證書頒發機構是偽造的，瀏覽器不認識，直接認為是危險證書
2.證書頒發機構確實存在，於是根據 CA 名，找到對應的內置 CA 根證書、CA 的公鑰
3.用 CA 的公鑰，對偽造的證書的數字簽名解密，發現解不了，認為是危險證書
HTTPS 如何保證數據加密傳輸的安全機制基本上都覆蓋了，細節的技術這里沒提，方便於理解，這里還有兩個問題沒有解決，
1.網站是如何將證書給到瀏覽器的
2.上面我們提到瀏覽器會生成一個對稱密鑰，這個對稱密鑰是如何協商的
HTTPS 的數據傳輸流程和 HTTP 是類似的，同樣包含兩個階段，握手，數據傳輸
握手階段，證書下發，密鑰協商(這個階段都還是明文的)，數據傳輸是加密階段，用的就是在握手階段協商出來的密鑰
原文地址：https://blog.csdn.net/jasonjwl/article/details/50985271
--------------------------------------------------------------------分割線--------------------------------------------------------------
看到一篇比較不錯的文章，寫的也是非常簡明易懂，貼出來看看
首先先舉一個例子：
假設你坐在一個教室里面，你現在非常想把某個信息傳遞給教室里的另一個人，一般我們會選擇傳紙條。傳紙條這個比喻相當正確，因為
這就類似互聯網的一個基礎協議 TCP 協議的工作模式。通常情況下，HTTP 協議的數據是使用 TCP 傳輸協議傳輸的。HTTP 指的是你在紙
條上寫的你要傳遞的目的地的作為，再然后才是你想要傳輸的內容。途徑的同學拿到紙條后根據上面的地址傳過去就行了。這樣要面臨一個
問題：途徑的同學完全知道你紙條上寫的什么。
這就是 HTTP 面臨的一個問題，這個問題通常情況下被叫做 "竊聽"，指的是在接受方和發送方之間的任意一個節點這個節點可以是路由可
以是代理服務器，可以偷窺到你傳輸的內容。這當然也是 HTTPS 要解決的第一個問題。這種問題通常是通過"加密"解決的，一般采用一種叫
做 AES 的算法來解決的，這種算法需要一個密鑰 KEY 來加密整個信息，加密和解密所需要使用的 KEY 是一樣的，所以這種加密一般也叫作
對稱加密。AES 在數學上保證了，只要你使用的 KEY 足夠的長，破解是很難的。
我們假設這種破解幾乎是不可能的，現在我們再次回到教室，你接着傳紙條，你把地址寫上了，也用了 AES 對傳輸的內容加密了。但是問
題來了，AES 有一個 KEY，我們怎么把 KEY 傳輸到目的呢？不然對方收到后沒法解密啊，如果我們把 KEY 直接寫在紙條上那么中間人也可
以解密，在現實中你可以通過一些其他辦法來把密鑰安全地傳輸給目的地，但是在互聯網上要想這么做是很難的，畢竟這個過程會有很多節點
，所以，貌似這種方式也是不安全的。
我們現在來使用另外一種加密算法---非對稱加密算法， 這種算法理解起來可能會困難一點，這種加密指的是可以生成一對密鑰(K1，K2)凡
是 K1加密的數據，K1 自身不能解密，而需要 K2 才能解開；凡是 K2 加密的數據，K2 自身不能解開，需要 K1 能解開。這種算法有很多，常
用的就是 RSA ，我們現在繼續傳紙條，但是傳紙條之前需要先准備把接下來通訊的對稱加密密鑰給傳輸過去。於是，你使用 RSA 生成一對密
鑰 K1，K2 ，你把K1 用明文送了出去，途中有人或許會劫持，但是沒有用，K1 加密的數據需要使用 K2 才能解密，而此時 K2 在你自己手里，
K1 到達目的地后，目的地的人會去准備一個接下來用於加密傳輸內容的對稱密鑰 KEY，然后使用 K1 把 KEY 加密了，把加密好的數據傳回來
，就算途中的人劫持了也解不開，等到了你的手上你用手上的 K2 把K1 加密的 KEY 解出來，現在整個班級只有你和目的地有 KEY，你們就可
以使用 AES 算法進行加密傳輸了。
當然這個時候會有兩個問題：
1：既然非對稱加密算法那么安全為什么不直接使用它來加密信息呢，而是去加密 對稱加密的 密鑰呢？
因為非對稱加密密鑰對生成和加密消耗的時間比較長，為了節約雙方的計算時間，通常只用它交換密鑰，而非直接用來傳輸數據。
2：非對稱加密是完全安全的嗎？
聽起來是挺安全的，但實際上，還有一種更惡劣的攻擊是這種方法無法防范的，這就是傳說中的“中間人攻擊”。我們繼續讓你坐在教室里
傳紙條，現在你和你的目的地途徑一個中間人，他有意想要知道你們的消息。我們將你稱為 A，你的目的地稱為 B，而中間人稱為 M。當你和 B
完成第一次密鑰交換的時候，途徑了 M，M 知道你要進行密鑰交換了，它把小紙條扣了下來，偽裝自己是 B，偽造了一個 KEY，然后用你發來的
密鑰 K1 對 KEY加密返回給你，你以為你和 B 完成了密鑰交換，實際上你是和 M 完成了密鑰交換。同時 M 和 B 也完成了一次密鑰交換，讓 B 誤
以為和你完成了密鑰交換。現在，由A->B 完整的加密，變成了 A(加密鏈接1)->M(明文)->B(加密鏈接2)的情況了。這時候 M 依然能夠知道 A 和 B
傳輸中的全部信息。
對於這種事，似乎很難找到一個解決辦法來解決這個問題，除非我們能從源頭保證交換密鑰的對象是安全的。這時候我們就要認識互聯網 HTT
PS 和 傳紙條的微妙區別了。傳紙條的時候，你和你的目的地的關系是對等的。而你訪問網站的時候，你訪問的對象通常是一個比較大的服務提供
商，他們有充沛的資源證明他們的合法性。
這時候我們會引入一個第三方叫做 CA，CA 是一些非常權威的專門用於認證一個網站合法性的組織。服務商會向他們申請一個證書，使得他們
建立安全鏈接時可以帶上 CA 的簽名。而 CA 的安全性由操作系統或瀏覽器來認證。你的 Windows、Linux、Chrome等會默認內置一些 CA 證書列
表，如果和你建立安全鏈接的人帶着這些人的簽名，那么認為這個安全連接是安全的，沒有遭到中間人攻擊。
CA 證書通常情況下是安全的，因為一旦某個 CA 頒發的證書被用於非法途徑，瀏覽器和操作系統一般會通過更新將整個 CA 頒發過的全部證書
視為不安全。這使得 CA 在頒發證書的時候是比較小心的。
所以，通過 非對稱加密 + 對稱加密 + CA 認證這三個技術混合在一起，才使得 HTTP 的后面加上了一個 S-Security。實際上 HTTPS 的協議比
我這里描述的更加復雜一些，這里主要說的是基本的實現原理。因為其中任何一環稍有閃失，就會使得整個加密都將變得不安全。這也是為什么 HT
TPS 的加密協議從 SSL1.0升級到SSL3.0再被 TLS1.0 取代現在被TLS1.2取代，但即使如此，你的 HTTPS 盡可能的保證了你傳輸的安全，但這種安
全也不是絕對的，比如說 CA 證書被用於了中間人攻擊，短期內，你的安全將陷於直接的麻煩，直到瀏覽器或操作系統重新更新了 CA 列表或你手動
調整了列表，但是大多數情況下還是安全的。