深入理解HTTPS原理、過程與實踐
引言
HTTP是不安全的，我們的頁面也被運營商插入過小黃圖廣告（數據被篡改），對于HTTP來說，再簡單不過，只需要設定相應的DNS，做一個中間人攻擊，再將修改后的數據返回，這一方面可能泄露用戶隱私數據，同時也對我們的品牌形象產生惡劣影響。
然而，當我們切換HTTPS時候，運營商的這些小九九就施展不開了，服務端認證不通過，瀏覽器不會展示相應的頁面數據；運營商實施搞的這一套東東也就不能在用戶不知情的情況下搞起來了，解決辦法是去除相應的受污染的DNS。
全球最大的成人網站PornHub，YouPorn都要全面切HTTPS了,我們還在猶豫什么了？
安全的HTTP的需求
對HTTP的安全需求：
- 加密（客戶端和服務器的對話是私密的，無須擔心被竊聽）
- 服務端認證（客戶端知道它們是在與真正的而不是偽造的服務器通信）
- 客戶端認證（服務器知道它們是在與真正的而不是偽造的客戶端通信）
- 完整性（客戶端和服務器的數據不會被修改）
- 效率（一個運行足夠快的算法，一遍低端的客戶端和服務器使用）
- 普適性（基本上所有的客戶端和服務器都支持這些協議）
- 管理的可擴展性（在任何地方的任何人都可以立即進行安全通信）
- 適應性（能夠支持當前最知名的安全方法）
- 在社會上的可行性（滿足社會的政治文化需要），要有公眾受信能力
在這里面最重要的是前面幾條
- 數據加密 傳輸內容進行混淆
- 身份驗證 通信雙方驗證對方的身份真實性
- 數據完整性保護 檢測傳輸的內容是否被篡改或偽造
安全HTTP的實現
加密方式的選擇
共享密鑰加密 對稱密鑰加密
共享密鑰加密方式使用相同的密鑰進行加密解密，通信雙方都需要接收對方的加密密鑰進行數據解密，這種方式在通信過程中必須交互共享的密鑰，同樣無法避免被網絡監聽泄漏密鑰的問題；同時對于眾多客戶端的服務器來說還需要分配和管理密鑰，對于客戶端來說也需要管理密鑰，增加設計和實現的復雜度，同時也降低了通信的效率；不用看都不靠譜。
公開密鑰加密
公開密鑰加密方式使用一對非對稱的密鑰對（私鑰和公鑰），不公開的作為私鑰，隨意分發的作為公鑰；公鑰和私鑰都能進行數據加密和解密，公鑰能解密私鑰加密的數據，私鑰也能解密公鑰加密的數據；這樣只需要一套密鑰就能處理服務端和眾多客戶端直接的通信被網絡監聽泄漏密鑰的問題，同時沒有額外的管理成本；看起來挺合適。
沒那么簡單
公開密鑰加密安全性高，伴隨著加密方式復雜，處理速度慢的問題。如果我們的通信都是用公開密鑰的方式加密，那么通信效率會很低。
HTTPS采用共享密鑰加密和公開密鑰加密混合的加密方式，在交換密鑰對環節使用公開密鑰加密方式（防止被監聽泄漏密鑰）加密共享的密鑰，在隨后的通信過程中使用共享密鑰的方式使用共享的密鑰進行加解密。
認證方式實現
數字證書
數字簽名是附加在報文上的特殊加密校驗碼，可以證明是作者編寫了這條報文，前提是作者才會有私鑰，才能算出這些校驗碼。如果傳輸的報文被篡改，則校驗碼不會匹配，因為校驗碼只有作者保存的私鑰才能產生，所以前面可以保證報文的完整性。
數字證書認證機構（Certificate Authority CA）是客戶端和服務器雙方都可信賴的第三方機構。
服務器的運營人員向數字證書認證機構提出證書認證申請，數字證書認證機構在判明申請者的身份之后，會對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書（也叫數字證書或證書）后綁定在一起。服務器將這份有數字認證機構頒發的公鑰證書發總給客戶端，以進行公開密鑰加密方式通信。
EV SSL（Extended Validation SSL Certificate）證書是基于國際標準的認證指導方針辦法的證書，通過認證的Web網站能獲得更高的認可度。持有EV SSL證書的Web網站的瀏覽器地址欄的背景色是綠色的，同時在地址欄的左側顯示了SSL證書中記錄的組織名稱及辦法證書的認證機構的名稱。
使用OpenSSL，每個人都可以構建一套認證機構文件，同時可以用來給自己的證書請求進行簽名，這種方式產生的證書稱為自簽名證書，這種證書通常是CA自己的證書，用戶開發測試的正式，也可以像12306這樣的，信不信由你。
證書信任的方式
- 操作系統和瀏覽器內置每個操作系統和大多數瀏覽器都會內置一個知名證書頒發機構的名單。因此，你也會信任操作系統及瀏覽器提供商提供和維護的可信任機構。受信認證機構（也有不受信的，比如賽門鐵克，沃通，或者像2011年被入侵的DigiNotar等）的證書一般會被操作系統或者瀏覽器在發行或者發布時內置。
- 證書頒發機構CA（ Certificate Authority，證書頒發機構）是被證書接受者（擁有者）和依賴證書的一方共同信任的第三方。
- 手動指定證書所有瀏覽器和操作系統都提供了一種手工導入信任證書的機制。至于如何獲得證書和驗證完整性則完全由你自己來定。
PKI（Public Key Infrastructure），即公開密鑰基礎設施，是國際上解決開放式互聯網絡信息安全需求的一套體系。PKI支持身份認證，信息傳輸，存儲的完整性，消息傳輸，存儲的機密性以及操作的不可否認性。
數據完整性
數字簽名是只有信息發送者才能產生的別人無法偽造的一段文本，這段文本是對信息發送者發送信息真實性的一個有效證明，具有不可抵賴性。
報文的發送方從報文文本生成一個128位的散列值（或稱為報文摘要活哈希值），發送方使用自己的私鑰對這個摘要值進行加密來形成發送方的數字簽名。然后這個數字簽名將作為報文的附件一起發送給報文的接收方。報文的接收方首先從接收到的原始報文中計算出128位的散列值，再用發送方的公鑰來對報文附加的數字簽名進行解密。如果兩次得到的結果是一致的那么接收方可以確認該數字簽名是發送方的，同時確認信息是真實的 。
HTTPS數據交互過程
HTTP中沒有加密機制，可以通過SSL（Secure Socket Layer 安全套接層）或TLS（Transport Layer Security 安全層傳輸協議）的組合使用，加密HTTP的通信內容。
HTTPS是 HTTP Secure 或 HTTP over SSL。
SSL（Security Socket Layer）是最初由網景公司（NetScape）為了保障網上交易安全而開發的協議，該協議通過加密來保護客戶個人資料，通過認證和完整性檢查來確保交易安全。網景公司開發過SSL3.0之前的版本；目前主導權已轉移給IETF（Internet Engineering Task Force），IETF以SSL3.0為原型，標準化并制定了TSL1.0，TLS1.1，TLS1.2。但目前主流的還是SSL3.0和TSL1.0。
SSL工作在OSI七層模型中的表示層，TCP/IP 四層模型的應用層。
SSL 和 TLS 可以作為基礎協議的一部分（對應用透明），也可以嵌入在特定的軟件包中（比如Web服務器中的實現）。
SSL 基于TCP，SSL不是簡單地單個協議，而是兩層協議；SSL記錄協議（SSL Record Protocol）為多種高層協議（SSL握手協議，SSL修改密碼參數協議，SSL報警協議）提供基本的安全服務。HTTP是為Web客戶端/服務器交互提供傳輸服務的，它可以在SSL的頂層運行；SSL記錄協議為SSL鏈接提供兩種服務，機密性：握手協議定義了一個共享密鑰，用于SSL載荷的對稱加密。 消息完整性：握手協議還定義了一個共享密鑰，它用來產生一個消息認證碼（Message Authentication Code，MAC）。
SSL記錄協議操作
- 分段 將每個上層消息分解成不大于2^14（16384）位，然后有選擇的進行壓縮
- 添加MAC 在壓縮數據的基礎上計算MAC
- 加密 消息加上MAC用對稱加密方法加密
- 添加SSL記錄頭 內容類型（8位），主版本（8位），副版本（8位），壓縮長度（16位）
SSL握手過程
- 第一階段 建立安全能力 包括協議版本 會話Id 密碼構件 壓縮方法和初始隨機數
- 第二階段 服務器發送證書 密鑰交換數據和證書請求，最后發送請求-相應階段的結束信號
- 第三階段 如果有證書請求客戶端發送此證書 之后客戶端發送密鑰交換數據 也可以發送證書驗證消息
- 第四階段 變更密碼構件和結束握手協議
SSL協議兩個重要概念，SSL會話，SSL連接；SSL連接是點到點的連接，而且每個連接都是瞬態的，每一個鏈接都與一個會話關聯。SSL會話是一個客戶端和一個服務器之間的一種關聯，會話由握手協議（Handshake Protocol）創建，所有會話都定義了一組密碼安全參數，這些安全參數可以在多個連接之間共享，會話可以用來避免每一個鏈接需要進行的代價高昂的新的安全參數協商過程。
Client Server
ClientHello:HandShake -------->
ServerHello:Handshake
Certificate*:Handshake
ServerKeyExchange*:Handshake
CertificateRequest*:Handshake
<-------- ServerHelloDone:Handshake
Certificate*:Handshake
ClientKeyExchange:Handshake
CertificateVerify*:Handshake
[ChangeCipherSpec]
Finished:Handshake -------->
[ChangeCipherSpec]
<-------- Finished:Handshake
Application Data <-------> Application Data
客戶端服務器數據交互實戰
使用openssl命令
openssl s_client -state -connect q.qunarzz.com:443
該命令可以顯示SSL握手過程，SSL證書鏈，公鑰證書以及其他相關的狀態和屬性信息。
使用Wireshark抓取數據包
相關配置
- 配置環境變量，同時保證文件路徑存在
SSLKEYLOG=/path/to/sslkeylog.log - 配置Wireshark
Wireshark->Preference->Protocols->SSL->(Pre)-Master-Secret log filename=>選擇上面的路徑
抓包操作
- 在命令行中打開Chrome或者Firefox，確保環境變量被讀取;如果不行就用Chrome或者Firefox的開發版。
open /Applications/Firefox.app open /Applications/Google\ Chrome.app - 確保$SSLKEYLOGFILE里面有內容了，再往下進行。
- 選擇對應網卡，抓包配置為host http://q.qunarzz.com，開始抓包
- 使用剛剛打開的瀏覽器訪問一個對應host http://q.qunarzz.com下的某個資源，在抓包界面使用ssl過濾數據
- 在抓包界面可以看到對應的SSL握手信息，同時還能看到解密后的應用數據。
內容解析（不同的網絡資源可能不完全一致，比如需要客戶端證書）
客戶端⇒服務器
- Client Hello
- 最高支持的協議版本 如TLS 1.0
- 支持的加密算法列表(Cipher Suites)
- 支持的壓縮算法列表(Compression Methods)
- 客戶端生成的隨機數，稍后用于生成會話密鑰
服務器⇒客戶端
- Server Hello
- 選定的協議版本
- 選定的加密算法
- 選定的壓縮方法
- 服務端生成的隨機數，稍后用于生成會話密鑰
- Certificate 證書內容
- Server Key Exchange, Server Hello Done
- 公鑰
- 數字簽名
- Server Hello Done
客戶端⇒服務器
- Client Key Exchange, Change Cipher Spec, Finished
- 公鑰
- Change Cipher Spec
- Finished
客戶端⇒服務器
- HTTP GET
服務端⇒客戶端
- 內容的數據片段信息
- HTTP HTTP/1.1 200 OK
服務端⇒客戶端
- Encrypted Alert
- Alert (Level Warning, Description: Close Notify)
參考資料
- 《Web性能權威指南》
- 《RFC 2246》
- 《圖解HTTP》
- 《HTTP權威指南》
- 《HTTPS權威指南 在服務器和Web應用上部署SSL/TLS和PKI》
- 《計算機網絡系統方法》
- 《計算機網絡自上而下方法》
- 《計算機安全原理與實踐》
- 《網絡安全基礎-應用與標準》
- 《PKI/CA與數字證書技術大全》
- 《SSL與TLS》
- 《OpenSSL官方命令文檔》
- 《OpenSSL與網絡信息安全-基礎、結構和指令》
- 《OpenSSL攻略》
- Wireshark Doc SSL
