安全越來越被重視
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連線做得更加安全的一個專案，所以越多的網站加入，網際網路就回變得越安全。