這是一篇內部分享文
背景： 2016年底 iOS App 強制要求使用HTTPS協議。Chrome 計劃在2017年將所有使用非 HTTPS 協議的網站標記為不安全，並在位址列的前面顯示一個紅叉。Mozilla 宣佈所有的新特性將只提供給 HTTPS 網站，HTTP 網站將逐步被禁止訪問瀏覽器功能。
HTTP
HTTP 的缺點
使用明文通訊
http 沒有加密功能， 無法對請求和響應的內容加密。內容在經過網路中間節點是容易被竊聽。
不驗證通訊方身份
HTTP 在請求和響應時， 不確認通訊雙方的身份。也就是說， 客戶端無法確認返回的訊息就是從真正的伺服器上返回的， 有可能是從偽裝的伺服器上返回的。
同時， 服務端也不知道接收響應的客戶端是否就是正真的目標客戶端。
這就是中間人攻擊。
不驗證報文完整性
客戶端端和服務端都無法確認收到的訊息是否就是對方傳送的原始訊息， 有可能中間被修改。
HTTPS
在不安全的網路上建立一安全通道。
什麼是HTTPS
TLS是傳輸層安全協議（Transport Layer Security）的縮寫，是一種對基於網路的傳輸的加密協議，可以在受信任的第三方公證基礎上做雙方的身份認證。
SSL是TLS的前身，現在已不再更新 > TSL/SSL 原理
HTTPS是在基於TLS/SSL的安全套接字上的的應用層協議，除了傳輸層進行了加密外，其它與常規HTTP協議基本保持一致
簡單來說就是 HTTPS = HTTP + TLS/SSL
如何彌補HTTP缺點的
加密
加密方式
-
共享祕鑰加密（對稱金鑰加密）
使用雙方共同擁有的單個金鑰。這種金鑰既用於加密，也用於解密，叫做機密金鑰。
-
公開祕鑰加密（非對稱加密）
一個公鑰和一個私鑰，這兩個金鑰在數學上是相關的。在公鑰加密中，公鑰可在通訊雙方之間公開傳遞，或在公用儲備庫中釋出，但相關的私鑰是保密的。只有使用私鑰才能解密用公鑰加密的資料。使用私鑰加密的資料只能用公鑰解密。
在HTTP應用中單純的使用上面的任一中加密方式都存在問題：
- 服務端如何安全的將祕鑰傳送給客戶端？如果通訊被竊聽， 那麼攻擊者就在獲得密文的同時獲得祕鑰，加密也就失去了意義。
- 如何讓所有的客戶端持有公鑰？ 客戶端如何確認收到的公開祕鑰不是從中間人傳送過來的假祕鑰而是貨真價實的真祕鑰？
HTTPS 的加密方式
HTTPS 使用混合使用2中加密方式， 同時使用證照來證明公鑰的正確性。
認證
目的： 為保證雙方傳遞資訊的 真實性、可靠性、完整性。
CA: 證照認證中心 (Certificate Authority) 中心。是一個負責發放和管理數字證照的第三方權威機構。
認證流程:
-
把證照請求 (ssl.csr) 發給證照機構。
-
CA 確認申請人身份後使用 CA 機構的私鑰對伺服器公鑰進行數字簽名， 同時把已簽名的公鑰分配給機構， 並且把證照和公鑰及簽名進行繫結。
也就是證照裡面包含了伺服器公鑰 + CA 對公鑰的數字簽名。
-
伺服器把證照傳送給客戶端（瀏覽器）
-
客戶端使用CA機構的公鑰驗證證照上的數字簽名。 如果驗證通過，則表明：
- CA 的認證伺服器是有效的
- CA 的公鑰是有效的
- 伺服器的公鑰是有效的
合法的CA機構的公鑰是內建在瀏覽器中的。
-
客戶端使用伺服器的公鑰對報文加密
-
伺服器使用私鑰解密報文
既然我們有開源的 openssl， 為什麼還要去購買ssl證照?
https 安全的前提
數字證照頒發機構（CA）被客戶端和服務端絕對信任。
自簽名證照
就是自己扮演 CA 機構，自己給自己的伺服器頒發證照。
由於自簽名證照無法排除被中間人偽造的可能， 所有瀏覽器對自簽名證照不信任，瀏覽的時候回給出風險提示。
因此， 只有值得信賴的第三方機構介入， 才能讓植入在瀏覽器中的認證機構公開祕鑰發揮作用， 從而藉此證明伺服器的真實性。
漏洞
Mozilla 和 Google 宣佈對 WoSign 和 StartCom ( StartSSL ) 一年內新簽發的所有SSL證照不信任。
360 > WoSign > StartCom
本作品採用《CC 協議》，轉載必須註明作者和本文連結