我也想來談談HTTPS

安全越來越被重視

2014年8月份Google在官博上發表 《HTTPS as a ranking signal》

表示調整其搜索引擎算法，采用HTTPS加密的網站在搜索結果中的排名將會更高，鼓勵全球網站采用安全度更高的HTTPS以保證訪客安全。

同一年（2014年），百度開始對外開放了HTTPS的訪問，并于3月初正式對全網用戶進行了HTTPS跳轉。對百度自身來說，HTTPS能夠保護用戶體驗，降低劫持/隱私泄露對用戶的傷害。

而2015年，百度開放收錄HTTPS站點公告。全面支持HTTPS頁面直接收錄；百度搜索引擎認為在權值相同的站點中，采用HTTPS協議的頁面更加安全，排名上會優先對待。

“HTTP = 不安全”，為什么說HTTP不安全？

HTTP報文是由一行行簡單字符串組成的，是純文本，可以很方便地對其進行讀寫。一個簡單事務所使用的報文：

HTTP傳輸的內容是明文的，你上網瀏覽過、提交過的內容，所有在后臺工作的實體，比如路由器的所有者、網線途徑路線的不明意圖者、省市運營商、運營商骨干網、跨運營商網關等都能夠查看。舉個不安全的例子：

一個簡單非HTTPS的登錄采用POST方法提交包含用戶名和密碼的表單，會發生什么？

POST表單發出去的信息， 沒有做任何的安全性信息置亂（加密編碼） ，直接編碼為下一層協議(TCP層)需要的內容，所有用戶名和密碼信息一覽無余，任何攔截到報文信息的人都可以獲取到你的用戶名和密碼，是不是想想都覺得恐怖？

那么問題來了，怎么樣才是安全的呢？

對于包含用戶敏感信息的網站需要進行怎樣的安全防護？

對于一個包含用戶敏感信息的網站（從實際角度出發），我們期望實現HTTP安全技術能夠滿足至少以下需求：

• 服務器認證（客戶端知道它們是在與真正的而不是偽造的服務器通話）
• 客戶端認證（服務器知道它們是在與真正的而不是偽造的客戶端通話）
• 完整性（客戶端和服務器的數據不會被修改）
• 加密（客戶端和服務器的對話是私密的，無需擔心被竊聽）
• 效率（一個運行的足夠快的算法，以便低端的客戶端和服務器使用）
• 普適性（基本上所有的客戶端和服務器都支持這個協議）
• 管理的可擴展性（在任何地方的任何人都可以立即進行安全通信）
• 適應性（能夠支持當前最知名的安全方法）
• 在社會上的可行性（滿足社會的政治文化需要）

HTTPS協議來解決安全性的問題：HTTPS和HTTP的不同 – TLS安全層（會話層）

超文本傳輸安全協議（HTTPS，也被稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種網絡安全傳輸協議。

HTTPS開發的主要目的，是提供對網絡服務器的認證，保證交換信息的機密性和完整性。

它和HTTP的差別在于，HTTPS經由超文本傳輸協議進行通信，但利用SSL/TLS來對包進行加密，即所有的HTTP請求和響應數據在發送到網絡上之前，都要進行加密。如下圖：

安全操作，即數據編碼（加密）和解碼（解密）的工作是由SSL一層來完成，而其他的部分和HTTP協議沒有太多的不同。更詳細的TLS層協議圖：

SSL層是實現HTTPS的安全性的基石， 它是如何做到的呢？ 我們需要了解SSL層背后基本原理和概念，由于涉及到信息安全和密碼學的概念，我盡量用簡單的語言和示意圖來描述。

SSL層背后基本原理和概念

介紹HTTPS背后的基本原理和概念，涉及到的概念：加密算法，數字證書，CA中心等。

加密算法

加密算法嚴格來說屬于編碼學（密碼編碼學），編碼是信息從一種形式或格式轉換為另一種形式的過程。解碼，是編碼的逆過程（對應密碼學中的解密）。

對稱加密算法

加密算法主要分兩類：對稱和非對稱加密算法。在對稱加密算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，這就要求解密方事先必須知道加密密鑰。

但是對稱加密算法有一個問題：一旦通信的實體多了，那么管理秘鑰就會成為問題。

非對稱加密算法（加密和簽名）

非對稱加密算法需要兩個密鑰： 公開密鑰（public key） 和 私有密鑰（private key） 。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那么只有用對應的公開密鑰才能解密，這個反過來的過程叫作 數字簽名 （因為私鑰是非公開的，所以可以驗證該實體的身份）。

他們就像是 鎖和鑰匙的關系 。Alice把打開的鎖（公鑰）發送給不同的實體（Bob，Tom），然后他們用這把鎖把信息加密，Alice只需要一把鑰匙（私鑰）就能解開內容。

那么，有一個很重要的問題：加密算法是如何保證數據傳輸的安全，即不被破解？有兩點：

1.利用數學計算的困難性（比如：離散對數問題）

2.加密算法是公開的，關鍵在于秘鑰，密碼學中有柯克霍夫斯基原則，即加密算法的安全性依賴的是密鑰的保密而不是算法的保密，因此，保證秘鑰的定期更換是非常重要的。

數字證書，用來實現身份認證和秘鑰交換

數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息，使用的加密算法以及公開密鑰的文件。

以數字證書為核心的加密技術可以對網絡上傳輸的信息進行加密和解密、數字簽名和簽名驗證，確保網上傳遞信息的機密性、完整性及交易的不可抵賴性。使用了數字證書，即使您發送的信息在網上被他人截獲，甚至您丟失了個人的賬戶、密碼等信息，仍可以保證您的賬戶、資金安全。 （比如，支付寶的一種安全手段就是在指定電腦上安裝數字證書）

身份認證（我憑什么信任你）

身份認證是建立每一個TLS連接不可或缺的部分。比如，你有可能和任何一方建立一個加密的通道，包括攻擊者，除非我們可以確定通信的服務端是我們可以信任的，否則，所有的加密（保密）工作都沒有任何作用。

而身份認證的方式就是通過證書以數字方式簽名的聲明，它將公鑰與持有相應私鑰的主體(個人、設備和服務)身份綁定在一起。通過在證書上簽名，CA可以核實與證書上公鑰相應的私鑰為證書所指定的主體所擁有。

了解TLS協議

HTTPS的安全主要靠的是TLS協議層的操作。那么它到底做了什么，來建立一條安全的數據傳輸通道呢？

TLS握手：安全通道是如何建立的

0 ms

TLS運行在一個可靠的TCP協議上，意味著我們必須首先完成TCP協議的三次握手。

56 ms

在TCP連接建立完成之后，客戶端會以明文的方式發送一系列說明，比如使用的TLS協議版本，客戶端所支持的加密算法等。

84 ms

服務器端拿到TLS協議版本，根據客戶端提供的加密算法列表選擇一個合適的加密算法，然后將選擇的算法連同服務器的證書一起發送到客戶端。

112 ms

假設服務器和客戶端協商后，得到一個共同的TLS版本和加密算法，客戶端檢測服務端的證書，非常滿意，客戶端就會要么使用RSA加密算法（公鑰加密）或者DH秘鑰交換協議，得到一個服務器和客戶端公用的對稱秘鑰。

由于歷史和商業原因，基于RSA的秘鑰交換占據了TLS協議的大片江山：客戶端生成一個對稱秘鑰，使用服務器端證書的公鑰加密，然后發送給服務器端，服務器端利用私鑰解密得到對稱秘鑰。

140 ms

服務器處理由客戶端發送的秘鑰交換參數，通過驗證MAC（Message Authentication Code，消息認證碼）來驗證消息的完整性，返回一個加密過的“Finished”消息給客戶端。

在密碼學中，消息認證碼（英語：Message Authentication Code，縮寫為MAC），又譯為消息鑒別碼、文件消息認證碼、訊息鑒別碼、信息認證碼，是經過特定算法后產生的一小段信息，檢查某段消息的完整性，以及作身份驗證。它可以用來檢查在消息傳遞過程中，其內容是否被更改過，不管更改的原因是來自意外或是蓄意攻擊。同時可以作為消息來源的身份驗證，確認消息的來源。

168 ms

客戶端用協商得到的堆成秘鑰解密“Finished”消息，驗證MAC（消息完整性驗證），如果一切ok，那么這個加密的通道就建立完成，可以開始數據傳輸了。

在這之后的通信，采用對稱秘鑰對數據加密傳輸，從而保證數據的機密性。

到此為止，我是想要介紹的基本原理的全部內容，但HTTPS得知識點不止如此，還有更多說，現在來點干貨（實戰）！！

那么，教練，我想用HTTPS

選擇合適的證書， Let’s Encrypt(It’s free, automated, and open.)是一種不錯的選擇 – https://letsencrypt.org/

ThoughtWorks在2016年4月份發布的技術雷達中對Let’s Encrypt項目進行了介紹：

從2015年12月開始，Let’s Encrypt項目從封閉測試階段轉向公開測試階段，也就是說用戶不再需要收到邀請才能使用它了。Let’s Encrypt為那些尋求網站安全的用戶提供了一種簡單的方式獲取和管理證書。Let’s Encrypt也使得“安全和隱私”獲得了更好的保障，而這一趨勢已經隨著ThoughtWorks和我們許多使用其進行證書認證的項目開始了。

據Let’s Encrypt發布的數據來看，至今該項目已經頒發了超過300萬份證書——300萬這個數字是在5月8日-9日之間達成的。Let’s Encrypt是為了讓HTTP連接做得更加安全的一個項目，所以越多的網站加入，互聯網就回變得越安全。

 

來自：http://insights.thoughtworkers.org/talk-about-https/