why https ?
Foreword
不知道有沒有同學和我一樣，在網上看https的資料總是覺得好像講的不詳細或者經不起推敲，甚至在書本中，也看的雲裡霧裡，稍微到了關鍵的地方，就被跳過不介紹了。自己好像懂了，誒，好像又沒懂。
反正我當初是憋了好一段時間 (〒︿〒)
因此，為了避免新手別像本王一樣走彎，本王放棄了看動漫的時間，下定決心寫一篇關於https的文章。
原文
github上看排版更好。
What
https在MDN上的定義：
HTTPS （安全的HTTP）是 HTTP 協議的加密版本。它通常使用 SSL 或者 TLS 來加密客戶端和伺服器之前所有的通訊 。這安全的連結允許客戶端與伺服器安全地交換敏感的資料，例如網上銀行或者線上商城等涉及金錢的操作。
SSL和TLS的區別：
大體上說白了，沒什麼區別。就是TLS是IETF的標準化，SSL不是，而且會被歷史給能慢慢淘汰。
值得一提的是SSL 3.0開始，便引入了 前向安全性 ，為了不一開始就讓各位困擾，前向安全會在後面介紹。
Why
那為什麼要是用https呢？
自然因為安全啦。
那http怎麼就不安全了呢？
接下來就讓我們一起來看看吧：
小灰是客戶端，小灰的同事小紅是服務端，有一天小灰試圖給小紅髮送請求。
但是，由於傳輸資訊是明文，這個資訊有可能被某個中間人惡意截獲甚至篡改。這種行為叫做中間人攻擊。
如何進行加密呢？
小灰和小紅可以事先約定一種對稱加密方式，並且約定一個隨機生成的金鑰。後續的通訊中，資訊傳送方都使用金鑰對資訊加密，而資訊接收方通過同樣的金鑰對資訊解密。
這樣做是不是就絕對安全了呢？並不是。
雖然我們在後續的通訊中對明文進行了加密，但是第一次約定加密方式和金鑰的通訊仍然是明文，如果第一次通訊就已經被攔截了，那麼金鑰就會洩露給中間人，中間人仍然可以解密後續所有的通訊內容。
這可怎麼辦呢？別擔心，我們可以使用非對稱加密，為金鑰的傳輸做一層額外的保護。非對稱加密的一組祕鑰對中，包含一個公鑰和一個私鑰。明文既可以用公鑰加密，用私鑰解密；也可以用私鑰加密，用公鑰解密。
在小灰和小紅建立通訊的時候，小紅首先把自己的公鑰Key1發給小灰：
收到小紅的公鑰以後，小灰自己生成一個用於對稱加密的金鑰Key2，並且用剛才接收的公鑰Key1對Key2進行加密，傳送給小紅：
小紅利用自己非對稱加密的私鑰，解開了公鑰Key1的加密，獲得了Key2的內容。從此以後，兩人就可以利用Key2進行對稱加密的通訊了。
在通訊過程中，即使中間人在一開始就截獲了公鑰Key1，由於不知道私鑰是什麼，也無從解密。
那這樣做是不是就絕對安全了呢？同樣不是。
中間人雖然不知道小紅的私鑰是什麼，但是在截獲了小紅的公鑰Key1之後，卻可以偷天換日，自己另外生成一對公鑰私鑰，把自己的公鑰Key3傳送給小灰。
小灰不知道公鑰被偷偷換過，以為Key3就是小紅的公鑰。於是按照先前的流程，用Key3加密了自己生成的對稱加密金鑰Key2，傳送給小紅。
這一次通訊再次被中間人截獲，中間人先用自己的私鑰解開了Key3的加密，獲得Key2，然後再用當初小紅髮來的Key1重新加密，再發給小紅。
那怎麼辦呢？難道再把公鑰進行一次加密嗎？這樣只會陷入雞生蛋蛋生雞，永無止境的困局。
這時候，我們有必要引入第三方，一個權威的證書頒發機構（CA）來解決。
接下來，也是開始正真的進入https的詳解了。
How
證書的生成
權威的證書頒發機構（CA）是做什麼的？
簡單的說，就是發安全證書的，而且受全世界認可，相信它絕不造假，安全可靠。使用者通過申請，填寫相關資料，然後花點錢，就能獲得CA下發的安全證書。
我們介紹下具體的流程：
- 生成金鑰和證書籤名請求
此部分使用 openssl 命令列程式（大部分 Linux、BSD 和 Mac OS X 系統均附帶此程式）來生成私鑰/公鑰和 CSR(證書籤名請求 )。
- 生成一個公鑰/私鑰對
用於生成 RSA 金鑰對的命令為：
openssl genrsa -out www.example.com.key 2048
- 生成CSR（證書籤名請求）
命令：
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
- 將 CSR 提交給證書頒發機構
對於不同的證書頒發機構 (CA)，需要使用不同的方法將 CSR 傳送給他們。 這些方法可能包括在其網站上使用表單、以電子郵件或其他方式傳送 CSR。 一些 CA（或其經銷商）甚至可能將其中部分或全部流程自動化（在某些情況下，包括金鑰對和 CSR 的生成）。
將 CSR 傳送給 CA 並按照他們的說明接收最終證書或證書鏈。
關於收費：
對於為您的公鑰進行證實的服務，不同 CA 的收費將有所不同。
還可以選擇將金鑰對映到多個 DNS 名稱，包括多個獨立名稱（例如 example.com、www.example.com、example.net 和 www.example.net 的全部）或“萬用字元”名稱（例如 *.example.com）。
例如，某個 CA 目前提供以下價格：
標準：16 美元/年，適用於 example.com 和 www.example.com。
萬用字元：150 美元/年，適用於 example.com 和 *.example.com。
對稱加密的金鑰生成
證書包含如下資訊：
對於已經雙方都有私鑰以後的事情，想必同學們都已經經過之前的訓練非常清楚了。
所以我們只需要重點介紹服務端和客戶端進行對稱加密的時候的金鑰是怎麼生成就可以了。
我們來看看整個用https資訊互動的流程：
第一種方式：
第二種方式：
圖中生成對稱金鑰的流程已經很清楚了。
另外提一下，我們需要知道，目前有兩對金鑰：
- 一對是服務端生成的公私鑰
- 另一對是CA自己的公私鑰
- 服務端的私鑰只在服務端存著；
- 服務端的公鑰在證書裡面；
- CA的私鑰只在CA機構那邊存著（可想而知，要是CA的私鑰被洩露了，那基本這個CA機構也就破產了）；
- CA的公鑰和證書一起預置了在各個作業系統裡。
為了流程圖更清晰，圖中忽略了客戶端用CA的公鑰解密證書中服務端的公鑰和簽名的過程。
回過頭來，有個問題是，為什麼有兩種方式？
這就得提到之前說過的 前向安全性 了。
它們主要的區別就是生成對稱金鑰的演算法，圖1是RSA，圖2則是DH。
什麼是RSA？
C隨機選取一個master key（即對稱加密的金鑰） ，用S 的公鑰加密，S解密，得到明文的master key，剩下過程和DH演算法類似！
什麼是DH？
S為server端，C為client端：
S 篩選出自己的素數對 S1、S2；
C 篩選出自己的素數對 C1、C2；
S與C交換各自的S2、C2；
S擁有了S1、C2，DH可以算出一個master key；
C擁有了C1、S2，DH可以算出一個master key；
兩個master key 完全一樣。
這就是神奇的DH演算法！
任何第三方都無法根據截獲的S2、C2算出master key。
Summary
最終，我們通過http中遇到的種種問題，到一步步的想辦法解決，再到後來的走投無路，最終引入了https。然後又學習了https加密的整個過程，以及https早期的前向安全問題的解決方案。
想必，同學們已經對https有了更深入的瞭解了。
參考資料
