一、定義
Hypertext Transfer Protocol Secure（超文字傳輸安全協議，縮寫：HTTPS）是一種網路安全傳輸協議。 它是在http協議的基礎上開發的，實現了加密傳輸，解決了http協議傳輸不安全的問題。https協議由網景公司（Netscape）在1994年首次提出的。提到網景，會想到那場驚心動魄的瀏覽器大戰，只可惜網景沒有勝出。自古成王敗寇，只能感嘆商場競爭的殘酷。如果當年網景能夠存活下來，不知道還會帶來多少驚喜。
二、原理
HTTPS在傳輸資料之前需要客戶端與服務端之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。握手過程的如下圖所示：
三、SSL/TLS簡介
https又稱為http over TLS/SSL。它的核心是TLS/SSL,所以我們先了解一下。
TLS/SSL協議設計得非常精妙，它的智慧在於，用非對稱祕鑰加密要交換的key，真正通訊的時候，用對稱祕鑰加密資訊。充分利用了非對稱加密的安全性和對稱加密的高效性。
為什麼交換的key，需要非對稱祕鑰來傳輸呢？因為，對稱祕鑰是在本地生成的，但是要生成祕鑰，需要key的參與，所以key也需要保密。
TLS/SSL對加密演算法進行了綜合應用，使用了非對稱加密，對稱加密以及HASH演算法。常見的演算法：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法： AES，RC4，3DES
HASH演算法： MD5，SHA1，SHA256
TLS：(Transport Layer Security，傳輸層安全協議)，用於兩個應用程式之間提供保密性和資料完整性。TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的後續版本，可以理解為SSL 3.1，它是寫入了 RFC 的。
SSL/TLS協議提供的服務主要有：
- 認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器；
- 加密資料以防止資料中途被竊取；
- 維護資料的完整性，確保資料在傳輸過程中不被改變。
TLS對於安全性的改進
- 對於訊息認證使用金鑰雜湊法：TLS 使用“訊息認證程式碼的金鑰雜湊法”（HMAC），當記錄在開放的網路（如因特網）上傳送時，該程式碼確保記錄不會被變更。SSLv3.0還提供鍵控訊息認證，但HMAC比SSLv3.0使用的（訊息認證程式碼）MAC 功能更安全。
- 增強的偽隨機功能（PRF）：PRF生成金鑰資料。在TLS中，HMAC定義PRF。PRF使用兩種雜湊演算法保證其安全性。如果任一演算法暴露了，只要第二種演算法未暴露，則資料仍然是安全的。
- 改進的已完成訊息驗證：TLS和SSLv3.0都對兩個端點提供已完成的訊息，該訊息認證交換的訊息沒有被變更。然而，TLS將此已完成訊息基於PRF和HMAC值之上，這也比SSLv3.0更安全。
- 一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現交換的證書型別。
- 特定警報訊息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應該傳送某些警報進行記錄。
四、SSL協議結構：
說明：
SSL協議主要分為兩層：SSL記錄協議層和SSL握手協議層。
SSL記錄協議層
為高層協議提供基本的安全服務。它建立在可靠的傳輸（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能。
SSL握手協議層
包括SSL握手協議（SSL HandShake Protocol）、SSL密碼引數修改協議（SSL Change Cipher Spec Protocol）和SSL告警協議（SSL Alert Protocol）。其中最重要的是SSL握手協議，它建立在SSL記錄協議之上，用於在實際的資料傳輸開始之前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。
五、握手協議
分為兩個階段：
（1）Handshake phase（握手階段）：
協商加密演算法和認證伺服器，建立用於加密和MAC（Message Authentication Code，訊息認證碼）用的金鑰。資訊認證碼 ，是經過特定演算法後產生的一小段資訊，檢查某段訊息的完整性 ，以及作身份驗證。
（2）Secure data transfer phase（安全的資料傳輸階段）：
在已經建立的SSL連線裡安全的傳輸資料。
SSL建立總過程：
我們以訪問https://cn.bing.com/網站為例，用WireShark抓包：
ClientHello
握手第一步是客戶端向服務端傳送 Client Hello 訊息，這個訊息裡包含了一個客戶端生成的隨機數 Random1、客戶端支援的加密套件（Support Ciphers）和 SSL Version 等資訊。
這個隨機數一方面需要在客戶端儲存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生Master Secret 。
ServerHello
收到客戶端問候之後伺服器必須傳送伺服器問候資訊，伺服器會檢查指定諸如TLS版本和演算法的客戶端問候的條件，如果伺服器接受並支援所有條件，它將傳送其證書以及其他詳細資訊，否則，伺服器將傳送握手失敗訊息。
跟客戶端一樣，服務端也需要產生一個隨機數傳送給客戶端。客戶端和服務端都需要使用這兩個隨機數來產生Master Secret。
Server Key Exchange（可選）
根據之前在ClientHello訊息中包含的CipherSuite資訊，決定了金鑰交換方式（例如RSA或者DH）。
在服務端向客戶端傳送的證書中沒有提供足夠的資訊（證書公鑰）的時候，還可以向客戶端傳送一個 Server Key Exchange，它包含完成金鑰交換所需的一系列引數。
Certificate Request（可選）------可以是單向的身份認證，也可以雙向認證
這一步是可選的，如果在對安全性要求高的常見可能用到。伺服器用來驗證客戶端。伺服器端發出Certificate Request訊息，要求客戶端發他自己的證書過來進行驗證。該訊息中包含伺服器端支援的證書型別（RSA、DSA、ECDSA等）和伺服器端所信任的所有證書發行機構的CA列表，客戶端會用這些資訊來篩選證書。
Server Hello Done
客戶端：
Client Key exchange
客戶端按照不同的金鑰交換演算法，(例如：RSA, Diffie-Hellman)產生一個48個位元組的Key，這個key 就叫做premaster key，傳送給伺服器，服務端收到pre-master算出main master。而客戶端當然也能自己通過pre-master算出main master。如此以來雙方就算出了對稱金鑰。
ChangeCipherSpec
ChangeCipherSpec是一個獨立的協議，體現在資料包中就是一個位元組的資料，用於告知服務端，客戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，準備使用之前協商好的加密套件加密資料並傳輸了。
服務端：
服務端在接收到客戶端傳過來的 PreMaster 加密資料之後，使用私鑰對這段加密資料進行解密，並對資料進行驗證，也會使用跟客戶端同樣的方式生成 Session Secret，一切準備好之後，會給客戶端傳送一個 ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，準備使用加密套件和 Session Secret加密資料了。
六、幾個secret
Secret Keys
上面的分析和講解主要是為了突出握手的過程，所以PreMaster secret，Master secret，session secret都是一代而過，但是對於Https，SSL/TLS深入的理解和掌握，這些Secret Keys是非常重要的部分。所以，準備把這些Secret Keys抽出來單獨分析和講解。
我們先來看看這些Secret Keys的生成過程以及作用流程圖：
PreMaster secret
PreMaster Secret是在客戶端使用RSA或者Diffie-Hellman等加密演算法生成的。它將用來跟服務端和客戶端在Hello階段產生的隨機數結合在一起生成 Master Secret。在客戶端使用服務端的公鑰對PreMaster Secret進行加密之後傳送給服務端，服務端將使用私鑰進行解密得到PreMaster secret。也就是說服務端和客戶端都有一份相同的PreMaster secret和隨機數。
PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手資料的版本號，因為在Client Hello階段，客戶端會傳送一份加密套件列表和當前支援的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的資料包被破解之後，攻擊者很有可能串改資料包，選擇一個安全性較低的加密套件和版本給服務端，從而對資料進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止傳送任何訊息。
七、數字證書和 CA 機構
協議中，伺服器返回證書，客戶端需要身份認證，而且還要用證書裡的公鑰加密，所以有必要把證書詳細瞭解下。
在說校驗數字證書是否可信的過程前，我們先來看看數字證書是什麼，一個數字證書通常包含了：
- 公鑰；
- 持有者資訊；
- 證書認證機構（CA）的資訊；
- CA 對這份檔案的數字簽名及使用的演算法；
- 證書有效期；
- 還有一些其他額外資訊；
那數字證書的作用，是用來認證公鑰持有者的身份，以防止第三方進行冒充。說簡單些，證書就是用來告訴客戶端，該服務端是否是合法的，因為只有證書合法，才代表服務端身份是可信的。
證書如下圖：
我們用證書來認證公鑰持有者的身份（服務端的身份），那證書又是怎麼來的？又該怎麼認證證書呢？
證書指紋：29b4ede71f1c1b12996c9b1e2775ac012515771f，相當於身份證。這個證書指紋就是解密後的Hash值。證書的格式遵循X.509 標準。X.509 是由國際電信聯盟制定的數字證書標準。這個標準規定了證書應該有哪些資訊。
X.500和X.509是X.500系列標準中最核心的兩個協議。
X.500是用來管理使用者名稱，且提供搜尋，確保使用者的唯一性。
X.509是一個鑑別框架。使用者可用常規加密演算法（如 DES）為 資訊加密，然後再用接收者的公共金鑰對 DES 迚行加密並將之附於資訊之上， 這樣接收者可用對應的私鑰開啟 DES 密鎖，並對資訊解密。
為了讓服務端的公鑰被大家信任，服務端的證書都是由 CA （Certificate Authority，證書認證機構）簽名的，CA 就是網路世界裡的公安局、公證中心，具有極高的可信度，所以由它來給各個公鑰簽名，信任的一方簽發的證書，那必然證書也是被信任的。
之所以要簽名，是因為簽名的作用可以避免中間人在獲取證書時對證書內容的篡改。
數字證書籤發和驗證流程
如下圖圖所示，為數字證書籤發和驗證流程：
CA 簽發證書的過程，如上圖左邊部分：
首先 CA 會把持有者的公鑰、用途、頒發者、有效時間等資訊打成一個包，然後對這些資訊進行 Hash 計算，得到一個 Hash 值；
然後 CA 會使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對證書做了簽名；
最後將 Certificate Signature 新增在檔案證書上，形成數字證書；
客戶端校驗服務端的數字證書的過程，如上圖右邊部分：
首先客戶端會使用同樣的 Hash 演算法獲取該證書的 Hash 值 H1；
通常瀏覽器和作業系統中整合了 CA 的公鑰資訊，瀏覽器收到證書後可以使用 CA 的公鑰解密 Certificate Signature 內容，得到一個 Hash 值 H2 ；
最後比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。
小結：https的目的是網路安全，它僅僅保證了傳輸過程中的安全。https是大勢所趨，大多數有名的網站都會提供https服務。這只是網路安全裡的冰山一角。