（一）HTTP基本原理

1. 基本概念

HTTP+ 加密 + 認證 + 完整性保護=HTTPS

即：HTTP 加上加密處理和認證以及完整性保護後即是HTTPS

HTTPS 並非是應用層的一種新協議。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。通常，HTTP 直接和 TCP 通信。當使用 SSL時，則演變成先和 SSL通信，再由 SSL和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披SSL協議這層外殼的 HTTP。HTTPS的SSL加密是在傳輸層實現的。在採用 SSL後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。

SSL是獨立於 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL協議使用。可以說 SSL是當今世界上應用最爲廣泛的網絡安全。SSL採用一種叫做公開密鑰加密（Public-key cryptography）的加密處理方式。

2. HTTPS優缺點

優點：

使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程中不被竊取、改變，確保數據的完整性。
HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

缺點：

https握手階段比較費時，會使頁面加載時間延長50%，增加10%~20%的耗電。
https緩存不如http高效，會增加數據開銷。
SSL證書也需要錢，功能越強大的證書費用越高。
SSL證書需要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。

（二）加密

近代的加密方法中加密算法是公開的，而密鑰卻是保密的。通過這種方式得以保持加密方法的安全性。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。如果密鑰被攻擊者獲得，那加密也就失去了意義。

1. 共享密鑰加密

共享密鑰加密：又叫做私鑰加密或對稱加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特點是算法公開、加密和解密速度快，適合於對大數據量進行加密。

共享密鑰加密中用到的密鑰叫做私鑰，私鑰表示個人私有的密鑰，即該密鑰不能被泄露。

共享密鑰加密過程

加密過程：明文 + 加密算法 + 私鑰 => 密文
解密過程：密文 + 解密算法 + 私鑰 => 明文

由於共享密鑰加密的算法是公開的，所以一旦私鑰被泄露，那麼密文就很容易被破解，所以共享密鑰加密的缺點是密鑰安全管理困難。以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那麼密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

於是引出下面要說的 公開密鑰加密，公開密鑰加密方式很好地解決了共享密鑰加密的困難。

2. 公開密鑰加密

公開密鑰加密：也叫做公鑰加密或非對稱加密。非對稱加密與對稱加密相比，其安全性更好。

非對稱加密使用一對密鑰，即公鑰和私鑰，且二者成對出現。私鑰被自己保存，不能對外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密，用另一個進行解密。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因爲解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實。

公開密鑰加密過程：

被公鑰加密過的密文只能被私鑰解密，過程如下：

明文 + 加密算法 + 公鑰 => 密文，密文 + 解密算法 + 私鑰 => 明文
被私鑰加密過的密文只能被公鑰解密，過程如下：
明文 + 加密算法 + 私鑰 => 密文，密文 + 解密算法 + 公鑰 => 明文

由於加密和解密使用了兩個不同的密鑰，這就是非對稱加密“非對稱”的原因。
非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數據進行加密。

3. HTTPS採用混合加密機制

HTTPS 採用共享密鑰加密和公開密鑰加密兩者並用的混合加密機制。若密鑰能夠實現安全交換，那麼有可能會考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通信。在交換密鑰環節使用公開密鑰加密方式，之後的建立通信交換報文階段則使用共享密鑰加密方。

混合加密機制：

HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。

（三）證書

1. 證明公開密鑰正確性的數字證書

遺憾的是，公開密鑰加密方式還是存在一些問題的。那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。比如，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。

爲了解決上述問題，可以使用由數字證書認證機構（CA，CertificateAuthority）和其相關機關頒發的公開密鑰證書。數字證書認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場上。

數字證書認證機構的業務流程

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。
數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起。
服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。公鑰證書也可叫做數字證書或直接稱爲證書。
接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴。

此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發佈版本時，會事先在內部植入常用認證機關的公開密鑰。

2. 可證明組織真實性的 EV SSL 證書

證書的一個作用是用來證明作爲通信一方的服務器是否規範，另外一個作用是可確認對方服務器背後運營的企業是否真實存在。擁有該特性的證書就是 EV SSL證書（Extended Validation SSLCertificate）

EV SSL證書是基於國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，因此，通過認證的Web 網站能夠獲得更高的認可度。

持有 EV SSL證書的 Web 網站的瀏覽器地址欄處的背景色是綠色的，從視覺上就能一眼辨別出。而且在地址欄的左側顯示了 SSL證書中記錄的組織名稱以及頒發證書的認證機構的名稱。

3. 用以確認客戶端的客戶端證書

HTTPS 中還可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。但客戶端證書仍存在幾處問題點。其中的一個問題點是證書的獲取及發佈。想獲取證書時，用戶得自行安裝客戶端證書。但由於客戶端證書是要付費購買的，且每張證書對應到每位用戶也就意味着需支付和用戶數對等的費用。另外，要讓知識層次不同的用戶們自行安裝證書，這件事本身也充滿了各種挑戰。現狀是，安全性極高的認證機構可頒發客戶端證書但僅用於特殊用途的業務。比如那些可支撐客戶端證書支出費用的業務。例如，銀行的網上銀行就採用了客戶端證書。在登錄網銀時不僅要求用戶確認輸入 ID 和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。

客戶端證書存在的另一個問題點是，客戶端證書畢竟只能用來證明客戶端實際存在，而不能用來證明用戶本人的真實有效性。也就是說，只要獲得了安裝有客戶端證書的計算機的使用權限，也就意味着同時擁有了客戶端證書的使用權限。

4. 由自認證機構頒發的證書稱爲自簽名證書

如果使用 OpenSSL這套開源程序，每個人都可以構建一套屬於自己的認證機構，從而自己給自己頒發服務器證書。但該服務器證書在互聯網上不可作爲證書使用，似乎沒什麼幫助。
獨立構建的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被戲稱爲自簽名證書。
瀏覽器訪問該服務器時，會顯示“無法確認連接安全性”或“該網站的安全證書存在問題”等警告消息。

由自認證機構頒發的服務器證書之所以不起作用，是因爲它無法消除僞裝的可能性。自認證機構能夠產生的作用頂多也就是自己對外宣稱“我是○○”的這種程度。即使採用自簽名證書，通過 SSL加密之後，可能偶爾還會看見通信處在安全狀態的提示，可那也是有問題的。因爲就算加密通信，也不能排除正在和已經過僞裝的假服務器保持通信。值得信賴的第三方機構介入認證，才能讓已植入在瀏覽器內的認證機構頒佈的公開密鑰發揮作用，並藉此證明服務器的真實

（四）HTTPS的安全通信機制

1. HTTPS 通信過程

（1）具體通信過程：

客戶端通過發送 Client Hello 報文開始 SSL通信。報文中包含客戶端支持的 SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
服務器以 Server Hello 報文作爲應答。和客戶端一樣，在報文中包含 SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
之後服務器發送 Certificate 報文。報文中包含公開密鑰證書。
最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL握手協商部分結束。
SSL第一次握手結束之後，客戶端以 Client Key Exchange 報文作爲迴應。報文中包含通信加密中使用的一種被稱爲 Pre-mastersecret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文之後的通信會採用 Pre-master secret 密鑰加密。
客戶端發送 Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以服務器是否能夠正確解密該報文作爲判定標準。
服務器發送 Change Cipher Spec 報文。
服務器發送 Finished 報文。
服務器和客戶端的 Finished 報文交換完畢之後，SSL連接就算建立完成。當然，通信會受到 SSL的保護。從此處開始進行應用層協議的通信，即發送 HTTP 請求。
應用層協議通信，即發送 HTTP 響應。
最後由客戶端斷開連接。斷開連接時，發送 close_notify 報文。

上圖做了一些省略，這步之後再發送 TCP FIN 報文來關閉與 TCP的通信。

在以上流程中，應用層發送數據時會附加一種叫做 MAC（MessageAuthentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。

下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）建立 HTTPS 通信的整個過程。

如果上面的步驟記不住，那可以參考下面這種相對簡要的HTTPS通信過程步驟：

（2）簡要通信過程：

客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接。
Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
客戶端的瀏覽器與Web服務器開始協商SSL/TLS連接的安全等級，也就是信息加密的等級。
客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然後利用網站的公鑰將會話密鑰加密，並傳送給網站。
Web服務器利用自己的私鑰解密出會話密鑰。
Web服務器利用會話密鑰加密與客戶端之間的通信。

（3）不一直使用 HTTPS的原因

其中一個原因是，因爲與純文本通信相比，加密通信會消耗更多的CPU 及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。
因此，如果是非敏感信息則使用 HTTP 通信，只有在包含個人信息等敏感數據時，才利用 HTTPS 加密通信。
特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔着的負載不容小覷。在進行加密處理時，並非對所有內容都進行加密處理，而是僅在那些需要信息隱藏時纔會加密，以節約資源。

2. SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer）和 TLS（Transport LayerSecurity）這兩個協議。

SSL技術最初是由瀏覽器開發商網景通信公司率先倡導的，開發過 SSL3.0 之前的版本。目前主導權已轉移到 IETF（InternetEngineering Task Force，Internet 工程任務組）的手中。
IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和TLS1.2。TSL是以 SSL爲原型開發的協議，有時會統一稱該協議爲 SSL。
由於 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，所以很多瀏覽器直接廢除了該協議版本。當前主流的版本是 SSL3.0 和 TLS1.0。

（1）SSL握手：

SSL握手過程其實已經包含在上面的HTTPS通信過程中了。下面就再單獨說明其握手過程：

客戶端發送 Client Hello 報文開始 SSL通信。

報文中包含客戶端支持的 SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
服務器以 Server Hello 報文作爲應答。和客戶端一樣，在報文中包含 SSL版本以及加密組件。
服務器發送 Certificate 報文。報文中包含公開密鑰證書。
最後服務器發送 Server Hello Done 報文通知客戶端。
客戶端以 Client Key Exchange 報文作爲迴應。

報文中包含通信加密中使用的一種被稱爲 Pre-mastersecret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文之後的通信會採用 Pre-master secret 密鑰加密。
客戶端發送 Finished 報文。
服務器發送 Change Cipher Spec 報文。
服務器發送 Finished 報文。

SSL連接就算建立完成。

（2）SSL速度慢的原因

HTTPS 也存在一些問題，那就是當使用 SSL時，它的處理速度會變慢。HTTPS 比 HTTP 要慢 2 到 100 倍。

SSL的慢分兩種：

一種是通信慢。
另一種是指由於大量消耗CPU 及內存等資源，導致處理速度變慢。

和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和TCP 連接、發送 HTTP 請求 • 響應以外，還必須進行 SSL通信，因此整體上處理通信量不可避免會增加。另一點是 SSL必須進行加密處理。在服務器和客戶端都需要進行加密和解密的運算處理。

因此從結果上講，比起 HTTP 會更多地消耗服務器和客戶端的硬件資源，導致負載增強。針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用SSL加速器這種（專用服務器）硬件來改善該問題。該硬件爲SSL通信專用硬件，相對軟件來講，能夠提高數倍 SSL的計算速度。僅在 SSL處理時發揮 SSL加速器的功效，以分擔負

（五）HTTP 和 HTTPS的區別

HTTPS協議需要到ca申請證書，一般免費證書很少，需要交費。
HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比HTTP協議安全。
HTTP和HTTPS使用的是完全不同的連接方式用的端口也不一樣,前者是80,後者是443。
HTTP的連接很簡單,是無狀態的。

注：此文爲閱讀《圖解HTTP》第七章後整理歸納的學習筆記。

HTTPS 超詳解 一文搞定HTTPS面試知識

目錄