關於HTTPS的詳解
- 一个新手原創
- 2017-10-24 09:23:533219瀏覽
文章同步於 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 是對等的，公鑰和私鑰也是對等的。
私鑰加密公鑰解密，能證明「私鑰擁有者」 的唯一身份，用於簽章。
公鑰加密私鑰解密，確保發送的訊息，只有有「私鑰擁有者」 能夠解密，（如果用私鑰加密，傳遞數據，則會被公鑰持有者（可能有很多持有者） 解密，失去對資訊的保護）
數位憑證
因特網路上的「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）。假定客戶端叫做愛麗絲，伺服器叫做鮑勃，整個握手過程可以用下圖說明。
握手階段分成五步驟：
愛麗絲給出協定版本號、一個客戶端產生的
隨機數（Client random），以及客戶端支援的加密方法。鮑伯確認雙方使用的加密方法，並給出數字憑證、以及一個
伺服器產生的隨機數（Server random）。愛麗絲確認數位憑證有效，然後產生一個新的
隨機數（Premaster secret），並使用數位憑證中的公鑰，加密這個隨機數，發給鮑伯。鮑伯使用自己的私鑰，取得愛麗絲寄來的隨機數（即
Premaster secret）。愛麗絲和鮑伯根據約定的加密方法，使用前面的三個隨機數，產生
對話金鑰（session key），用來加密接下來的整個對話過程。
上面的五步，畫成一張圖，就是下面這樣：
握手階段有三點要注意：
產生對話金鑰總共需要三個隨機數。
握手之後的對話使用
對話金鑰（session key）加密（對稱加密），伺服器的公鑰和私密金鑰只用於加密和解密對話金鑰（session key）（非對稱加密），無其他作用。伺服器公鑰放在伺服器的數位憑證之中。
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 权威指南
文章同步於 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 是對等的，公鑰和私鑰也是對等的。
私鑰加密公鑰解密，能證明「私鑰擁有者」 的唯一身份，用於簽章。
公鑰加密私鑰解密，確保發送的訊息，只有有「私鑰擁有者」 能夠解密，（如果用私鑰加密，傳遞數據，則會被公鑰持有者（可能有很多持有者） 解密，失去對資訊的保護）
數位憑證
因特網路上的「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）。假定客戶端叫做愛麗絲，伺服器叫做鮑勃，整個握手過程可以用下圖說明。
握手階段分成五步驟：
愛麗絲給出協定版本號、一個客戶端產生的
隨機數（Client random），以及客戶端支援的加密方法。鮑伯確認雙方使用的加密方法，並給出數字憑證、以及一個
伺服器產生的隨機數（Server random）。愛麗絲確認數位憑證有效，然後產生一個新的
隨機數（Premaster secret），並使用數位憑證中的公鑰，加密這個隨機數，發給鮑伯。鮑伯使用自己的私鑰，取得愛麗絲寄來的隨機數（即
Premaster secret）。愛麗絲和鮑伯根據約定的加密方法，使用前面的三個隨機數，產生
對話金鑰（session key），用來加密接下來的整個對話過程。
上面的五步，畫成一張圖，就是下面這樣：
握手階段有三點要注意：
產生對話金鑰總共需要三個隨機數。
握手之後的對話使用
對話金鑰（session key）加密（對稱加密），伺服器的公鑰和私密金鑰只用於加密和解密對話金鑰（session key）（非對稱加密），無其他作用。伺服器公鑰放在伺服器的數位憑證之中。
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 權威指南
#20 小時前發布
##如果你覺得我的文章對你有用，請隨意讚賞
零基礎如何學爬蟲技術
作用
瀏覽
載入中...
顯示更多註解
以上是關於HTTPS的詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！