一、爲什麼要HTTPS
HTTP協議因爲其輕、小、快、簡單，所以在全世界普及開來，各種應用都離不開它。但是隨着業務複雜度的提高，HTTP的這些優點逐漸成爲了短板。所以就開始各種打補丁，比如因爲HTTP是無狀態的協議，所以爲了管理狀態而誕生的Cookie。這篇文章要說的是其中一個爲了安全而誕生的超級補丁SSL（HTTPS）。
1. HTTP在安全方面哪兒不行
- 竊聽
HTTP使用明文進行傳輸，因此傳輸內容可能會被竊聽。以太網工作方式是將要發送的數據包發往連接在一起的所有主機。在包頭中包括有應該接收數據包的主機的正確地址，因爲只有與數據包中目標地址一致的那臺主機才能接收到信息包，但是當主機工作在監聽模式下的話不管數據包中的目標物理地址是什麼，主機都將可以接收到。- 僞裝
HTTP協議中不管是請求還是響應都不會對客戶端和服務器的身份進行確認。在HTTP協議通信時，任何人都可以發起請求，服務器只要接收到請求，不管對方是誰都會返回一個響應（當然，可以在服務端對IP或者端口進行限制）。因此，可能服務器或者客戶端並不是我們想象中的對方。而且，對於無意義的請求服務器也會照單全收，可能會遭遇DoS攻擊。- 篡改
對於信息的準確性我們可以用一個專業術語—報文完整性來說明，由於HTTP無法驗證通信報文的完整性，因此，在請求或者響應發送之後到接收這段時間內，傳輸的內容可能已經被篡改（中間人攻擊）。
2. HTTPS呢
- 防止被竊聽—加密
加密分爲兩種，首先是對通信的加密，HTTP協議中沒有加密機制，但是可以通過外掛的方式對通信進行加密，通過和SSL或TLS的組合使用，可以加密HTTP的通信內容。其次是對內容的加密，在這種情況下，客戶端和服務器需要對發送的內容進行加密解密操作。另外，由於該方法不像SSL和TLS一樣對整個通信線路進行加密，雖然內容不會被竊聽，但是可能會被篡改。此外，加密分爲對稱加密和非對稱加密。HTTPS當然是使用最複雜的混合加密機制（對稱加密和非對稱加密一起使用）（SSL、TLS、對稱和非對稱加密稍後會介紹）。- 防止遭遇僞裝—證書
藉助剛剛提到的SSL，它不僅提供加密處理，還提供了用於確認通信雙方身份的東西—證書。證書是由大家都信任的第三方機構頒發的，用來證明服務器或者客戶端是實際存在的。- 防止被篡改—摘要
藉助與SSL提供的認證、加密和摘要功能，這些功能組合起來可以有效檢測傳輸內容的完整性。當然，HTTP本身就帶有MD5和SHA-1等散列值校驗的方法，但是並不可靠。
因此，可以說HTTPS就是穿着SSL馬甲的HTTP。
二、SSL，TLS，對稱加密，非對稱加密，證書都是什麼鬼
SSL和TLS
TLS是以SSL爲原型開發的協議，有時會統一稱爲SSL協議。
HTTPS並不是應用層的一種新協議，只是普通HTTP協議在接口部分使用SSL（Secure Socket Layer，安全套接層）和TLS（Transport Layer Security，安全傳輸層）協議而已。
通常，HTTP直接與tcp協議進行通信，當使用SSL時，則HTTP先和SSL通信，再由SSL和TCP進行通信，SSL是獨立於HTTP的協議，所以除了HTTP以外，其他應用層協議也可以和SSL配合使用（如SMTP和Telnet）。
對稱和非對稱加密
這裏的對稱描述的是加解密的密鑰，如果加密和解密密鑰相同，則是對稱加密，反之則是非對稱加密。下面說一下兩種加密方式的優缺點（只是針對用在HTTPS協議方面的優缺點），具體的加密算法有很多，感興趣的推薦看一下《現代密碼學趣味之旅》，一本科普一樣的密碼書，不像其他密碼書那樣全是數學晦澀難懂。
- 對稱加密和非對稱加密優缺點
對稱加密因爲加解密使用的是同一密鑰，相對非對稱加解密使用不同密鑰，對稱加密對CPU資源的消耗會更少，速度會更快，更適合大量數據的加密。但是對稱加密需要將密鑰發送給通信的另一方，如果密鑰在傳輸過程中被截獲，那就白忙活了。所以這時候就需要非對稱加密發揮優勢了，非對稱加密可以用來傳輸對稱加密的密鑰！- HTTPS混合加密機制
HTTPS當然使用複雜的混合加密機制（對稱加密和非對稱加密一起使用）。其實對稱加密已經夠用，只是有一個問題，對稱加密的密鑰如何發送給通信的另一方。我們把信息裝進一個帶鎖的箱子了，並把箱子發送給另一方，對方如何打開箱子纔是問題的關鍵。這一過程也叫做密鑰交換。混合加密機制就是在密鑰交換階段使用非對稱加密方式，之後使用對稱加密方式進行傳輸。
證書
即使使用上述的非對稱加密方式進行加密，還是有一個問題，那就是無法確認公開的密鑰就是貨真價實的通信對方的公開密鑰。有可能公鑰在傳輸過程中已經被攻擊者替換掉了。
爲了解決這個問題，證書應運而生。證書也叫公開密鑰證書，是由數字證書認證機構（CA，Certificate Authority）和其相關機構頒發的。以下是數字證書認證機構的業務流程：
- 服務器的運營人員向數字證書認證機構提出公鑰申請。
- 認證機構在判明申請者的身份之後，對已申請的公鑰做數字簽名（非對稱加密使用私鑰進行加密叫數字簽名）。
- 認證機構分配這個已簽名的公鑰，並將該公鑰放入公鑰證書後綁定在一起。
- 服務器將證書發送給客戶端，客戶端使用認證機構的公鑰解開證書，進行驗證。
這裏有一個比較棘手的問題，認證機構的公鑰如何發送給客戶端？一般現在主流瀏覽器都是在內部植入了認證機構的公鑰。
還有一點就是客戶端也有證明身份的客戶端證書，比如銀行的網銀網盾。
三、整個過程走一遍
一般面試的時候面試官都喜歡問HTTPS的整個通信步驟。
- 請求由客戶端發起。客戶端發送Client Hello報文開始SSL通信。報文中包含了SSL的版本，加密組件等信息。
- 服務器收到請求會以Server Hello報文作爲應答，報文內容和請求時差不多（經過篩選的）。
- 緊接着服務器再發送一條Certificate報文，報文中包含了證書。
- 服務器活還沒幹完，還需要發送Server Hello Done報文給客戶端，表示SSL握手結束。
- 然後該客戶端了，客戶端會迴應一個Client Key Exchange報文，報文包含用步驟3中公鑰加密後的隨機密碼串。
- 接着客戶端繼續發送Cipher Spec報文，提示服務器，用步驟5的隨機密碼串作爲密鑰加密之後的通信。
- 然後客戶端發送Finished報文，表示這次協商結束，是否成功還得看服務器能不能解密該報文。
- 服務器沒問題，發送Change Cipher Spec報文。
- 服務器發送Finished。
- SSL連接完成，接下來使用HTTP進行通信。
- 最後由客戶端斷開連接。發送close_notify報文。