why https ?

Foreword

不知道有沒有同窗和我同樣，在網上看https的資料老是以爲好像講的不詳細或者經不起推敲，甚至在書本中，也看的雲裏霧裏，稍微到了關鍵的地方，就被跳過不介紹了。本身好像懂了，誒，好像又沒懂。
反正我當初是憋了好一段時間 (〒︿〒)
所以，爲了不新手別像本王同樣走彎，本王放棄了看動漫的時間，下定決心寫一篇關於https的文章。

原文

why 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下發的安全證書。
咱們介紹下具體的流程：

1. 生成密鑰和證書籤名請求

此部分使用 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

1. 將 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信息交互的流程：

第一種方式：

第二種方式：

圖中生成對稱密鑰的流程已經很清楚了。

另外提一下，咱們須要知道，目前有兩對密鑰：

1. 一對是服務端生成的公私鑰
2. 另外一對是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 篩選出本身的素數對 S一、S2；
C 篩選出本身的素數對 C一、C2；
S與C交換各自的S二、C2；
S擁有了S一、C2，DH能夠算出一個master key；
C擁有了C一、S2，DH能夠算出一個master key；
兩個master key 徹底同樣。

這就是神奇的DH算法！
任何第三方都沒法根據截獲的S二、C2算出master key。

Summary

最終，咱們經過http中遇到的種種問題，到一步步的想辦法解決，再到後來的走投無路，最終引入了https。而後又學習了https加密的整個過程，以及https早期的前向安全問題的解決方案。
想必，同窗們已經對https有了更深刻的瞭解了。

參考資料

HTTPS能夠防止中間人篡改內容嗎？

在服務器上啓用 HTTPS

TLS/SSL 高級進階

漫畫：什麼是 HTTPS 協議？