HTTPS詳解

文章同步於 Github/blog

人們會用 Web 事務來處理一些很重要的事情。若是沒有強有力的安全保證，人們就 沒法安心地進行網絡購物或使用銀行業務。若是沒法嚴格限制訪問權限，公司就不 能將重要的文檔放在 Web 服務器上。Web 須要一種安全的 HTTP 形式。

目前已存在一些提供認證(基本認證和 摘要認證 )和報文完整性檢查(摘要 qop="auth-int")的輕量級方法。對不少網絡事務來講，這些方法都是很好用的， 但對大規模的購物、銀行事務，或者對訪問機密數據來講，並不足夠強大。這些更 爲重要的事務須要將 HTTP 和數字加密技術結合起來使用，才能確保安全。

HTTP 的安全版本要高效、可移植且易於管理，不但可以適應不斷變化的狀況並且還應 該能知足社會和政府的各項要求。咱們須要一種可以提供下列功能的 HTTP 安全技術。

• 服務器認證 (客戶端知道它們是在與真正的而不是僞造的服務器通話)。
• 客戶端認證 (服務器知道它們是在與真正的而不是僞造的客戶端通話)。
• 完整性 (客戶端和服務器的數據不會被修改)。
• 加密 (客戶端和服務器的對話是私密的，無需擔憂被竊聽)。
• 效率 (一個運行的足夠快的算法，以便低端的客戶端和服務器使用)。
• 普適性 (基本上全部的客戶端和服務器都支持這些協議)。
• 管理的可擴展性 (在任何地方的任何人均可以當即進行安全通訊)。
• 適應性 (可以支持當前最知名的安全方法)。
• 在社會上的可行性 (知足社會的政治文化須要)。

數字加密

術語

在這個數字加密技術的入門介紹中，咱們會討論如下內容。

• 密鑰：改變密碼行爲的數字化參數。
• 對稱密鑰加密系統：編 / 解碼使用相同密鑰的算法。
• 不對稱密鑰加密系統：編 / 解碼使用不一樣密鑰的算法。
• 公開密鑰加密系統：一種可以使數百萬計算機便捷地發送機密報文的系統。
• 數字簽名：用來驗證報文未被僞造或篡改的校驗和。
• 數字證書：由一個可信的組織驗證和簽發的識別信息。

密碼

密碼學基於一種名爲密碼(cipher)的祕密代碼。密碼是一套編碼方案——一種特 殊的報文編碼方式和一種稍後使用的相應解碼方式的結合體。加密以前的原始報文一般被稱爲 明文(plaintext 或 cleartext)。使用了密碼以後的編碼報文一般被稱做 密文(ciphertext)。

用密碼來生成保密信息已經有數千年了。傳說 尤利烏斯·凱撒(Julius Caesar) 曾使用過一種三字符循環移位密碼，報文中的每一個字符都由字母表中三個位置以後的字符來取代。在現代的字母表中，「A」就應該由「D」來取代，「B」就應該由「E」 來取代，以此類推。

密鑰

隨着技術的進步，人們開始製造一些機器，這些機器能夠用複雜得多的密碼來快速、 精確地對報文進行編解碼。這些密碼機不只能作一些簡單的旋轉，它們還能夠替換 字符、改變字符順序，將報文切片切塊，使代碼的破解更加困難。

每每在現實中，編碼算法和編碼機均可能會落入敵人的手中，因此大部分機器上都有一些號盤，能夠將其設置爲大量不一樣的值以改變密碼的工做方式。即便機器被盜，沒有正確的號盤設置(密鑰值)，解碼器也沒法工做。

這些密碼參數被稱爲 密鑰(key)。要在密碼機中輸入正確的密鑰，解密過程才能正確進行。密碼密鑰會讓一個密碼機看起來好像是多個虛擬密碼機同樣，每一個密碼機 都有不一樣的密鑰值，所以其行爲都會有所不一樣。

給定一段明文報文 P、一個編碼函數 E 和一個數字編碼密鑰 e，就能夠生成一段經 過編碼的密文 C。經過解碼函數 D 和解碼密鑰 d，能夠將密文 C 解 碼爲原始的明文 P。固然，編 / 解碼函數都是互爲反函數的，對 P 的編碼進行解碼 就會回到原始報文 P 上去。

對稱密鑰加密技術

不少數字加密算法都被稱爲 對稱密鑰(symmetric-key) 加密技術，這是由於它們在編碼時使用的密鑰值和解碼時 同樣(e=d)。咱們就將其統稱爲密鑰 k。

流行的對稱密鑰加密算法包括：DES、Triple-DES、RC2 和 RC4。

保持密鑰的機密狀態是很重要的。在不少狀況下，編 / 解碼算法都是衆所周知的，所以密鑰就是惟一保密的東西了。好的加密算法會迫使攻擊者試遍每個可能的密鑰，才能破解代碼。用暴力去嘗試 全部的密鑰值稱爲 枚舉攻擊(enumeration attack)。

缺點

對稱密鑰加密技術的缺點之一就是發送者和接收者在互相對話以前，必定要有一個共享的保密密鑰。

好比 Alice(A)、Bob(B)和 Chris(C)都想與 Joe 的 五金商店(J) 對話。A、B 和 C 都要創建本身與 J 之間的保密密鑰。A 可能須要密鑰 KAJ，B 可能須要密鑰 KBJ，C 可能須要密鑰 KCJ。每對通訊實體都須要本身的私有密鑰。若是有 N 個節點， 每一個節點都要和其餘全部 N-1 個節點進行安全對話，總共大概會有 N2 個保密密鑰: 這將是一個管理噩夢。

公開密鑰加密技術

公開密鑰加密技術沒有爲每對主機使用單獨的加密 / 解密密鑰，而是使用了兩個非對稱密鑰：一個用來對主機報文編碼，另外一個用來對主機報文解碼。

RSA

全部公開密鑰非對稱加密系統所面臨的共同挑戰是，要確保即使有人擁有了下面全部的線索，也沒法計算出保密的私有密鑰:

• 公開密鑰 (是公有的，全部人均可以得到);
• 一小片攔截下來的密文 (可經過對網絡的嗅探獲取);
• 一條報文及與之相關的密文 (對任意一段文本運行加密器就能夠獲得)。

RSA算法 就是一個知足了全部這些條件的流行的公開密鑰加密系統，它是在 MIT 發明的，後來由 RSA 數據安全公司將其商業化。即便有了公共密鑰、任意一段明文、用公共密鑰對明文編碼以後獲得的相關密文、RSA 算法自身，甚至 RSA 實現 的源代碼，破解代碼找到相應的私有密鑰的難度仍至關於對一個極大的數進行質因數分解的困難程度，這種計算被認爲是全部計算機科學中最難的問題之一。所以， 若是你發現了一種可以快速地將一個極大的數字分解爲質因數的方法，就不只可以入侵瑞士銀行的帳戶系統，並且還能夠得到圖靈獎了。

混合加密系統和會話密鑰

任何人只要知道了其公開密鑰，就能夠向一臺公共服務器發送安全報文，因此非對稱的公開密鑰加密系統是很好用的。兩個節點無須爲了進行安全的通訊而先交換私有密鑰。

但公開密鑰加密算法的計算可能會很慢。實際上它混合使用了對稱和非對稱策略。 好比，比較常見的作法是在兩節點間經過便捷的公開密鑰加密技術創建起安全通訊， 而後再用那條安全的通道產生併發送臨時的隨機對稱密鑰，經過更快的對稱加密技 術對其他的數據進行加密。（SSH和HTTPS都是這樣的）

數字簽名

除了加 / 解密報文以外，還能夠用加密系統對報文進行簽名(sign)，以說明是誰編寫的報文，同時證實報文未被篡改過。這種技術被稱爲數字簽名(digital signing)。

數字簽名是附加在報文上的特殊加密校驗碼。數字簽名一般是用 非對稱公開密鑰技術產生的。由於只有全部者才知道其私有密鑰， 因此能夠將做者的私有密鑰看成一種「指紋」使用。

RSA 加密系統將解碼函數 D 做爲簽名函數使用，是由於 D 已經將私有密鑰做爲輸入使用了。注意， 解碼函數只是一個函數，所以，能夠將其用於任意的輸入。一樣，在 RSA 加密系統中，以任意順序 應用 D 和 E 函數時，二者都會相互抵消。所以 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 同樣。

注意

私鑰和公鑰是一對，均可以加解密，配對使用。RSA 的原理，兩個大質數(p,q)乘積(n)難以逆向求解，因此 pq 是對等的，公鑰和私鑰也是對等的。

1. 私鑰加密公鑰解密，能證實「私鑰擁有者」 的惟一身份，用於簽名。
2. 公鑰加密私鑰解密，確保發送的信息，只有有「私鑰擁有者」 可以解密，（若是用私鑰加密，傳遞數據，則會被公鑰持有者（可能有不少持有者） 解密，失去對信息的保護）

數字證書

因特網上的「ID 卡」——數字證書。數字證書(一般被稱做「certs」，有點像 certs 牌薄荷糖)中包含了由某個受信任組織擔保的用戶或公司的相關信息。

數字證書中還包含一組信息，全部這些信息都是由一個官方的 證書頒發機構(CA) 以數字方式簽發的。

並且，數字證書一般還包括對象的公開密鑰，以及對象和所用簽名算法的描述性信息。任何人均可以建立一個數字證書，但並非全部人都可以得到受人尊敬的簽發 權，從而爲證書信息擔保，並用其私有密鑰簽發證書。典型的證書結構如圖所示。

X.509 v3證書

不幸的是，數字證書沒有單一的全球標準。就像不是全部印刷版 ID 卡都在一樣的位 置包含了一樣的信息同樣，數字證書也有不少略有不一樣的形式。 不過好消息就是現 在使用的大多數證書都以一種標準格式—— X.509 v3，來存儲它們的信息。X.509 v3 證書提供了一種標準的方式，將證書信息規範至一些可解析字段中。不一樣類型的證 書有不一樣的字段值，但大部分都遵循X.509 v3結構。

基於 X.509 證書的簽名有好幾種，(其中)包括 Web 服務器證書、客戶端電子郵件 證書、軟件代碼簽名證書和證書頒發機構證書。

用證書對服務器進行認證

經過 HTTPS 創建了一個安全 Web 事務以後，現代的瀏覽器都會自動獲取所鏈接服 務器的數字證書。若是服務器沒有證書，安全鏈接就會失敗。

瀏覽器收到證書時會對簽名頒發機構進行檢查。若是這個機構是個頗有權威的公共簽名機構，瀏覽器可能已經知道其公開密鑰了(瀏覽器會預先安裝不少簽名頒發機構的證書)。

若是對簽名頒發機構一無所知，瀏覽器就沒法肯定是否應該信任這個簽名頒發機構， 它一般會向用戶顯示一個對話框，看看他是否相信這個簽名發佈者。簽名發佈者可 能是本地的 IT 部門或軟件廠商。

HTTPS

HTTPS 是最流行的 HTTP 安全形式。它是由網景公司獨創的，全部主要的瀏覽器和 服務器都支持此協議。

使用 HTTPS 時，全部的 HTTP 請求和響應數據在發送到網絡以前，都要進行加密。 HTTPS 在 HTTP 下面提供了一個傳輸級的密碼安全層——可使用 SSL，也可使用其後繼者—— 傳輸層安全(Transport Layer Security，TLS)。因爲 SSL 和 TLS 很是相似，因此咱們不太嚴格地用術語 SSL 來表示 SSL 和 TLS。

SSL/TLS

不使用SSL/TLS的HTTP通訊，就是不加密的通訊。全部信息明文傳播，帶來了三大風險。

• 竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。
• 篡改風險（tampering）：第三方能夠修改通訊內容。
• 冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

SSL/TLS協議是爲了解決這三大風險而設計的，但願達到：

• 全部信息都是加密傳播，第三方沒法竊聽。
• 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。
• 配備身份證書，防止身份被冒充。

SSL（Secure Socket Layer）是安全套接層，TLS（Transport Layer Security）是傳輸層安全協議，創建在SSL3.0協議規範，是 SSL3.0 的後續版本。SSL 直到 3.0版本才大規模的部署和應用。 TLS 版本相比於 SSL 變化明顯的是支持的加密算法不一樣。當前最新使用的是TLS1.2協議。1.3版本還在草案階段。

HTTPS方案

如今，安全 HTTP 是可選的。請求一個客戶端(好比 Web 瀏覽器)對某 Web 資源執行某事務時，它會去檢查 URL 的方案：

• 若是URL的方案爲http，客戶端就會打開一條到服務器端口80(默認狀況下) 的鏈接，並向其發送老的 HTTP 命令。
• 若是URL的方案爲https，客戶端就會打開一條到服務器端口443(默認狀況下) 的鏈接，而後與服務器「握手」，以二進制格式與服務器交換一些 SSL 安全參數， 附上加密的 HTTP 命令。

SSL 是個二進制協議，與 HTTP 徹底不一樣，其流量是承載在另外一個端口上的(SSL 一般是由端口 443 承載的)。若是 SSL 和 HTTP 流量都從端口 80 到達，大部分 Web 服務器會將二進制 SSL 流量理解爲錯誤的 HTTP 並關閉鏈接。將安全服務進一步整 合到 HTTP 層中去就無需使用多個目的端口了，在實際中這樣不會引起嚴重的問題。

SSL握手

開始加密通訊以前，客戶端和服務器首先必須創建鏈接和交換參數，這個過程叫作握手（handshake）。假定客戶端叫作愛麗絲，服務器叫作鮑勃，整個握手過程能夠用下圖說明。

握手階段分紅五步：

1. 愛麗絲給出協議版本號、一個客戶端生成的 隨機數（Client random），以及客戶端支持的加密方法。
2. 鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個 服務器生成的隨機數（Server random）。
3. 愛麗絲確認數字證書有效，而後生成一個新的 隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。
4. 鮑勃使用本身的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。
5. 愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成 對話密鑰（session key），用來加密接下來的整個對話過程。

上面的五步，畫成一張圖，就是下面這樣：

握手階段有三點須要注意：

1. 生成對話密鑰一共須要三個隨機數。
2. 握手以後的對話使用 對話密鑰（session key） 加密（對稱加密），服務器的公鑰和私鑰只用於加密和解密 對話密鑰（session key）（非對稱加密），無其餘做用。
3. 服務器公鑰放在服務器的數字證書之中。

DH算法的握手階段

整個握手階段都不加密（也無法加密），都是明文的。所以，若是有人竊聽通訊，他能夠知道雙方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全，只取決於 第三個隨機數（Premaster secret）能不能被破解。

雖然理論上，只要服務器的公鑰足夠長（好比2048位），那麼 Premaster secret 能夠保證不被破解。可是爲了足夠安全，咱們能夠考慮把握手階段的算法從默認的 RSA算法，改成 Diffie-Hellman算法（簡稱DH算法）。

採用 DH算法 後，Premaster secret 不須要傳遞，雙方只要交換各自的參數，就能夠算出這個隨機數。

上圖中，第三步和第四步由傳遞 Premaster secret 變成了傳遞 DH算法 所需的參數，而後雙方各自算出 Premaster secret。這樣就提升了安全性。

服務器證書

SSL 支持雙向認證，將服務器證書承載回客戶端，再將客戶端的證書回送給服務器。 而如今，瀏覽時並不常用客戶端證書。大部分用戶甚至都沒有本身的客戶端證書。服務器能夠要求使用客戶端證書，但實際中不多出現這種狀況。

站點證書的有效性

SSL 自身不要求用戶檢查 Web 服務器證書，但大部分現代瀏覽器都會對證書進行簡 單的完整性檢查，併爲用戶提供進行進一步徹查的手段。網景公司提出的一種 Web 服務器證書有效性算法是大部分瀏覽器有效性驗證技術的基礎。驗證步驟以下所述：

• 日期檢測 首先，瀏覽器檢查證書的起始日期和結束日期，以確保證書仍然有效。若是證書 過時了，或者還未被激活，則證書有效性驗證失敗，瀏覽器顯示一條錯誤信息。
• 簽名頒發者可信度檢測 每一個證書都是由某些 證書頒發機構(CA) 簽發的，它們負責爲服務器擔保。證書有不一樣的等級，每種證書都要求不一樣級別的背景驗證。好比，若是申請某個電 子商務服務器證書，一般須要提供一個營業的合法證實。
  任何人均可以生成證書，但有些 CA 是很是著名的組織，它們經過很是清晰的流 程來驗證證書申請人的身份及商業行爲的合法性。所以，瀏覽器會附帶一個簽名頒發機構的受信列表。若是瀏覽器收到了某未知(多是惡意的)頒發機構簽發的證書，那它一般會顯示一條警告信息。
• 簽名檢測 一旦斷定簽名受權是可信的，瀏覽器就要對簽名使用簽名頒發機構的公開密鑰， 並將其與校驗碼進行比較，以查看證書的完整性。
• 站點身份檢測 爲防止服務器複製其餘人的證書，或攔截其餘人的流量，大部分瀏覽器都會試着 去驗證證書中的域名與它們所對話的服務器的域名是否匹配。服務器證書中一般 都包含一個域名，但有些 CA 會爲一組或一羣服務器建立一些包含了服務器名稱 列表或通配域名的證書。若是主機名與證書中的標識符不匹配，面向用戶的客戶 端要麼就去通知用戶，要麼就以表示證書不正確的差錯報文來終止鏈接。

HTTPS客戶端

SSL 是個複雜的二進制協議。除非你是密碼專家，不然就不該該直接發送原始的 SSL 流量。幸運的是，藉助一些商業或開源的庫，編寫 SSL 客戶端和服務器並不十 分困難。

OpenSSL 是 SSL 和 TLS 最多見的開源實現。OpenSSL 項目由一些志願者合做開發， 目標是開發一個強壯的、具備完備功能的商業級工具集，以實現 SSL 和 TLS 協議以 及一個全功能的通用加密庫。能夠從 http://www.openssl.org 上得到 OpenSSL 的相 關信息，並下載相應軟件。

後記

強烈推薦一本書：HTTP 權威指南

參考

• 超詳解析 | CDN HTTPS優化實踐，全網一分鐘生效
• 圖解SSL/TLS協議
• HTTP 權威指南