HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer ，安全的超文字傳輸協議），是以安全為目標的HTTP通道。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。這個系統的最初研發由 Netscape 進行。
如今，HTTPS 已經漸漸成為主流，很多大型網站都已經全站 HTTPS 化。那麼有了 HTTP 後為什麼還需要有 HTTPS 呢？——為了解決 HTTP 的不足。
HTTP 的不足之處
- 通訊內容使用明文——內容可能被竊聽
- 不驗證通訊方的身份——可能遭遇偽裝
- 無法驗證報文的完整性——報文有可能已遭篡改
現在來看看一般的明文通訊都存在什麼問題。
使用明文傳輸內容存在的問題
在理想的資訊流動情況下，資訊能夠安全達到目的地且未受到任何攻擊。
我們平時生活中所說的“攻擊”，更多地有”主動“的意義。但是這裡的攻擊，囊括了主動和被動兩層意義。根據 ITU-T 的 X.800 推薦標準（OSI 安全框架），攻擊分為以下幾類：
- 被動攻擊
- 竊聽：一個非授權方介入系統的攻擊，獲取了傳輸的資訊，破壞保密性。
- 流量攻擊：監聽流量來判斷通訊的性質。
- 主動攻擊
- 偽裝/冒充：個實體假裝成另外一個實體。
- 偽造/篡改：將偽造的客體插入系統中，破壞真實性。
- 重放：獲取有效資料段以重播的方式獲取對方信任。
- DoS / DDoS：導致合法使用者不能夠訪問正常網路服務的行為都算是拒絕服務攻擊。
一般的明文網路訪問，無法防止上面所述的攻擊方式。通過應用密碼學的知識，一般可以阻止上面多數的攻擊。（但是密碼學對流量攻擊、重放和 (D)DoS 還做不了太多。防止重放攻擊還需要在更高的應用層做一些處理。）
下面，我們用密碼學來解決它可以解決的風險：
- 竊聽風險：黑客可以獲知通訊內容。 —— 保證資料的隱私性
- 篡改風險：黑客可以修改通訊內容。 —— 保證資料的完整性
- 冒充風險：黑客可以冒充他人身份參與通訊。 —— 保證身份正確。
解決竊聽風險：加密
1、對稱加密 。有流式、分組兩種，加密和解密都是使用的同一個金鑰。 例如：DES、AES 等
2、非對稱加密 。加密使用的金鑰和解密使用的金鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法效能低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的資料長度也是有限的。 例如：RSA、DSA。
非對稱加密是最安全的。但是在頻繁大量的網路資料傳輸過程中，非對稱加密演算法的效能限制會成為整個系統的瓶頸。如果需要長時間且頻繁地傳輸資訊，全程使用非對稱加密是萬萬不可以的。
Client->Server: I want to talk with you.
Server->Client: It's my public key.
Client->Server: Message encoded by public key.
Note: The hacker knows nothing.
Note: Server knows this messgae.
複製程式碼只要演算法和金鑰選擇得當，使用對稱加密演算法可以得到同樣安全的加密效果。但是使用對稱加密金鑰也有它自己的問題：通訊雙方如何商定出金鑰。通訊雙方共享同一個對稱金鑰，如果雙方已經知道這一金鑰，之後的資訊使用這一金鑰進行加密完全沒有問題。 但是，不同的客戶端、伺服器數量龐大，所以雙方都需要維護大量的金鑰，維護成本很高，金鑰極易洩露。因此，對稱金鑰必須動態生成。但問題就在於，金鑰如何安全的分享出去。金鑰鑰如果洩漏，加密就失去了意義。
我們可以將對稱加密和非對稱加密聯合起來來解決這個問題。
對於沒有見過面的雙方，第一次請求通訊的時候，S 先發出自己的公鑰，C 記下 S 的公鑰。之後 S 和 C 協商得出一個對稱金鑰。因為是通訊非對稱加密後的，監聽者僅憑他們之間的通訊內容是難以破譯出它們協商出的對稱金鑰的。之後，S、C 使用對稱金鑰進行正式的通訊，監聽者不知道他們的金鑰，所以也無法破譯他們之間的通訊內容。
看起來很完美。
如何防止中間人：認證
考慮下面的情況：中間人代理了 S、C 之間的所有流量。
C -> H: 請求公鑰
H -> S: 請求公鑰
S -> H: 返回真實公鑰
Note: 偽造金鑰對
H -> C: 返回偽造的公鑰
Note: 用偽造公鑰加密明文
C -> H: 密文
Note: 解密得到明文
Note: 用真實公鑰加密明文
H -> S: 密文
Note: 用私鑰解密得明文
Note: 無感知
Note: 無感知
複製程式碼中間人通過偽造公鑰私鑰對，偽裝成 S，同時 C、S 雙方對此毫無感知。其實即使不偽造金鑰對，只要中間人監聽到了公鑰，就足以把 S 發給 C 的訊息給解密出來。這裡的問題是：如何確認 ”S“ 是真實的而不是中間人 ”H“，如何保證公鑰的準確 。
為了保證公鑰的真實性，引入了認證這一手段。
數字簽名
數字簽名基於公鑰私鑰體制，將一段文字通過雜湊（hash）和私鑰加密處理後生成數字簽名。接收者用傳送者的公共金鑰對簽名解密，並將之與收到的資訊“指紋”進行比較，以確定其真實性。只要簽名者的私鑰不被洩漏，數字簽名就是可信的。
+---------------------+
| A digital signature | +---------+ +--------+
|(not to be confused |----Hash--->| 訊息摘要 |---私鑰加密--->| 數字簽名 |
|with a digital | +---------+ +--------+
+---------------------+
複製程式碼數字證書
數字證書，是由一個官方的證書頒發機構（CA）簽發的一組資料。這種證書很難偽造，用於使用者的身份證明。
數字證書包含以下內容：
- 物件名稱（人、伺服器、組織、公司等）
- 物件的公開金鑰
- 其它擴充套件資訊
- = = = = = = = = = = = = = = = = = = = = =
- 附上證書頒發機構的數字簽名
使用證書，正常的通訊流程是這樣子的：
-
S 會把自己的數字證書下發給 C
-
C 通過證書中“證書頒發機構的數字簽名”來驗證證書的來源和完整性。
具體做法是使用 CA 的公鑰解密並對比。
-
一旦證書被認證通過，C 就從證書中取出 “物件的公開金鑰”，之後就用這個公鑰來加密資料。
CA 的私鑰僅它自己知道，因此黑客無法偽造 CA 的簽名，也不能得到合法的證書。只要證書認證通過，它的公鑰就是可信的。
到這裡，這整個過程才算是無懈可擊的。
HTTPS 具體是怎麼做的
HTTPS 的通訊過程和上面描述的基本一致。
-> 客戶端向服務端傳送請求
-> 服務端返回數字證書
-> 客戶端用自己的CA[主流的CA機構證書一般都內建在各個主流瀏覽器中]公鑰去解密證書,如果證書有問題會提示風險
-> 如果證書沒問題客戶端會生成一個對稱加密的隨機祕鑰然後再和剛剛解密的伺服器端的公鑰對資料進行加密,然後傳送給伺服器端
-> 伺服器端收到以後會用自己的私鑰對客戶端發來的對稱祕鑰進行解密
-> 之後雙方就拿著這個對稱加密祕鑰來進行正常的通訊`
複製程式碼
整個過程中，HTTPS 證書使用的是 X.509 證書標準。
X.509 是密碼學裡公鑰證書的格式標準。 X.509 證書己應用在包括TLS/SSL 在內的眾多網路協議裡。
X.509 是由國際電信聯盟（ITU-T）制定的數字證書標準。為了提供公用網路使用者目錄資訊服務， ITU 於 1988 年制定了 X.500 系列標準。其中 X.500 和 X.509 是安全認證系統的核心， X.500 定義了一種區別命名規則，以命名樹來確保使用者名稱稱的唯一性； X.509 則為 X.500 使用者名稱稱提供了通訊實體鑑別機制，並規定了實體鑑別過程中廣泛適用的證書語法和資料介面， X.509 稱之為證書。
HTTPS協議使用的是 SSL 證書，它遵從了 X.509 標準。
- 證書格式版本號
- 證書序列號
- 過期時間
- 證書辦法機構
- 證書使用的簽名演算法
- 過期時間
- 物件名稱（人、伺服器、組織、公司等）
- 物件的公開金鑰
- 其它擴充套件資訊
- = = = = = = = = = = = = = = = = = = = = =
- 附上證書頒發機構的數字簽名
在瀏覽器中，檢視證書內容非常容易。
X.509 證書的信任鏈
到現在，還有一個問題沒有被解決。使用證書認證的前提是 C 知道 S 的公鑰，可是S 的公鑰不能在不安全的網路中直接傳送給 C。
此時就引入了證書頒發機構（Certificate Authority，簡稱CA），世界上CA數量並不多。C 預先擁有所有受信任CA的證書。如果 S 想要一個證書，它先向 CA 申請，CA 使用它自己的私鑰對 S 的證書進行簽名。接下來，C 和 S 要相互通訊的時候，S 將它的證書發給 C。 C 擁有所有 CA 的可信公鑰，所以 C 可以驗證證書的真實性。
如此一來，C 信任 CA，CA信任 S 使得 C 信任 S，信任鏈（Chain Of Trust）就是這樣形成的。
事實上，客戶端 C 內建的是 CA的根證書(Root Certificate)，HTTPS協議中伺服器會傳送證書鏈（Certificate Chain）給客戶端。
如上圖，“Wikipedia”的證書的證書鏈如下。這裡，C 一定是信任 根證書 Root CA 的，於是 C 最終信任 "Wikimedia Foundation, Inc" 。這裡有一個細節，根證書是由根證書自己來簽名和頒發的。
| 證書 | 證書頒發者 |
|---|---|
| GlobalSign Root CA（根證書） | GlobalSign Root CA（自簽名） |
| GlobalSign Organization Validation CA - SHA256 - G2 | GlobalSign Root CA |
| "Wikimedia Foundation, Inc." | GlobalSign Organization Validation CA |
最終，C 只要內建世界上僅有的幾個根證書就可以自行校驗所有的 HTTPS 證書了。S 的證書必須經過某一個 CA 的簽名。但是現在的作業系統和瀏覽器也允許使用者自行新增自己的根證書。例如 12306.cn 曾經要求使用者自行下載安裝指定的根證書。
從下圖可以看到，根證書 “GlobalSign Root CA” 早已經內建到系統內部了。
結語
使用密碼學理論，客戶端和伺服器之間實現了資訊的保密傳輸。密碼學中對稱加密、非對稱加密和雜湊函式在整個通訊建立的過程中都發揮了作用，並且都缺一不可。密碼學的理論知識已經成為安全通訊的理論基礎。
現在 HTTPS 已經被廣泛運用到各大網站中，它已經成為我們日常中用到的技術，而我們對此並沒有太大的感知。密碼學提供了很多已經被我們視為理所當然的工具，我們使用的大多數安全通訊工具都仰仗於它。