超詳細https握手與數字簽名講解

以前看過不少https相關內容，感受都是有個大概印象。趁着剛閱讀《http權威指南》後，發表一下本身的理解。若是我有講的不對的地方，麻煩你們幫我指點出來，阿里嘎多～

其實我也不知道從哪裏開始講起，咱走一步算一步吧哈哈哈哈哈哈。

總覽

大部分困難的編碼及解碼工做都是在 SSL 庫中完成的，因此 Web 客戶端和服務器在使用安全 HTTP 時無需過多地修改其協議處理邏輯。在大多數狀況下，只須要用 SSL 的輸入 / 輸出調用取代 TCP 的調用，再增長其餘幾個調用來配置和管理安全信息就好了。 

對稱密鑰與非對稱密鑰

 相比之下，對於對稱密鑰加密技術，128 位的密鑰被認爲是很是強大的。實際上， 長密鑰對密碼安全有着很是重要的影響，美國政府甚至對使用長密鑰的加密軟件實 施了出口控制，以防止潛在的敵對組織建立出美國國家安全局(National Security Agency，NSA)本身都沒法破解的祕密代碼。 基本上能夠理解爲，用128位的密鑰黑客基本GG了。

對稱密鑰加密技術的缺點之一就是發送者和接收者在互相對話以前，必定要有一個共享的保密密鑰。每對通訊實體都須要本身的私有密鑰。若是有 N 個節點， 每一個節點都要和其餘全部 N-1 個節點進行安全對話，總共大概會有 N2 個保密密鑰: 這將是一個管理噩夢。非對稱加密不只更安全，並且還減小了服務器端的壓力，由於它不用再記住它和每一個客戶端的祕鑰。

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

（還作什麼程序員，不如去研究一下RSA窮其一輩子說不定和畢加索同樣永垂不朽了）

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

還在混淆數字證書和數字簽名嗎？

數字證書

數字證書(一般被稱做「certs」，有點像 certs 牌薄荷糖)中包含了由某個受信任組織擔保的用戶或公司的相關信息。 咱們每一個人都有不少形式的身份證實。有些 ID，好比護照和駕照，都足以在不少場合證實某人的身份。例如，你能夠用美國的駕照在新年前夜搭乘前往紐約的航班， 在你到那兒以後，接着用它來證實你的年齡，這樣你就能和朋友們一塊兒喝酒了。

受信程度更高的身份證實，好比護照，是由政府在特殊的紙上籤發並蓋章的。很難 僞造，所以能夠承載較高的信任度。有些公司的徽章和智能卡中包含有電子信息， 以強化使用者的身份證實。有些絕密的政府組織甚至會對你的指紋或視網膜毛細血 管模式進行匹配以便確認你的 ID ! 

數字證書主要內容：

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

我要強調一點！數字證書一般還包括所用簽名算法的描述性信息。

爲何我要強調這個玩意兒呢？由於固然這就是在一開始三步握手交換信息時雙方驗證摘要報文的時候，要用到！！！不少人很懵逼不知道瀏覽器和服務器怎麼驗證報文的，由於幾乎沒有做者詳細介紹是如何驗證過程的，或許你看了我下面解釋的這個過程，甚至本身想實現一把。

報文摘要：用於對發送的報文生成一個很是小的摘要信息。這個摘要信息保證原報文的完整性，即原報文只要有一位被改變，則摘要信息就會不匹配。對報文使用簽名函數（SHA-1和MD5，而簽名函數來自數字證書！

摘要是「對信息主體的濃縮」。摘要是一種單向函數，主要用於將無限的輸入值轉 換爲有限的濃縮輸出值。7常見的摘要函數 MD5，會將任意長度的字節序列轉換爲 一個 128 位的摘要。有時也將摘要函數稱爲加密的校驗和、單向散列函數或指紋函數。強調單向防止被逆向啊。  這樣才能百分百保證信息沒有徹底被修改。聽不懂？？？不要緊，這纔是開胃菜。

數字簽名：

數字簽名來驗證證書的完整性。就是在第二步握手的時候，稍後講解。

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

簽名是加了密的校驗和：

• 簽名能夠證實是做者編寫了這條報文。只有做者纔會有最機密的私有密鑰， 所以，只有做者才能計算出這些校驗和。校驗和就像來自做者的我的「簽名」同樣。

• 簽名能夠防止報文被篡改。若是有惡意攻擊者在報文傳輸過程當中對其進行了修改，校驗和就再也不匹配了。因爲校驗和只有做者保密的私有密鑰才能產生，因此攻擊者沒法爲篡改了的報文僞造出正確的校驗碼。

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

• 此時假定私有密鑰沒有被人偷走。大多數私有密鑰都會在一段時間後過時。還有一些「取消列表」記 錄了被偷走或入侵的密鑰。

HTTPS方案

一般狀況下，非安全 HTTP 的 URL 方案前綴爲 http，以下所示:

http://www.joes-hardware.com/index.html

在安全 HTTPS 協議中，URL 的方案前綴爲 https，以下所示:

https://cajun-shop.securesites.com/Merchant2/merchant.mv?Store_Code=AGCGS

請求一個客戶端(好比 Web 瀏覽器)對某 Web 資源 執行某事務時，它會去檢查 URL 的方案。 

• 若是 URL 的方案爲 http，客戶端就會打開一條到服務器端口 80(默認狀況下) 的鏈接，並向其發送老的 HTTP 命令 

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

如今一般是第三種方案。

SSL握手

在發送已加密的 HTTP 報文以前，客戶端和服務器要進行一次 SSL 握手，在這個握手過程當中，它們要完成如下工做: 

• 交換協議版本號;
• 選擇一個兩端都瞭解的密碼;
• 對兩端的身份進行認證;
• 生成臨時的會話密鑰，以便加密信道。 

咱們來一個http握手與https握手概覽。

這是一個概覽，有利於下面咱們在具體分析的時候，不知道在哪一個過程的時候，記得來看圖對比。讓你對https握手更加清晰。

服務器證書

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

• Web 站點的名稱和主機名;

• Web 站點的公開密鑰;
  • 簽名頒發機構的名稱;
  • 來自簽名頒發機構的簽名。

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

放大招：具體握手過程

（SSL的加密過程是RSA與AES混合進行的。簡單歸納一下，就是經過RSA加密方式來交換AES加解密的密鑰，而後使用AES加密的方式來傳輸報文。）

第一步：

有客戶端發起的第一次握手，這次握手過程的主要目的是從服務端獲取數字簽名證書，服務端在發送數字簽名證書以前要先確認客戶端的SSL版本、加密算法等信息。------第一步用到數字證書

客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表以內。若是數字證書記載的網址，與你正在瀏覽的網址不一致，就說明這張證書可能被冒用，瀏覽器會發出警告。

第二步：

完成第一次握手後，接着進行第二次握手。第二次握手是在客戶端收到證書後發起的，主要目的是將AES加解密使用的Key （Pre-master secret）發送給服務端。固然這個AES_KEY是使用第一次握手獲取的公鑰進行加密的。客戶端收到這個使用公鑰加密後的AES_KEY，使用服務端的私鑰進行解密。這樣客戶端和服務端通過二次握手後都持有了AES加解密的KEY。———第二步進行數字簽名驗證。

參考下面的圖理解啊！！老哥們～（我說的第二步能夠當作下圖中2和3）

第二步包括數字簽名過程，也就是RSA算法驗證過程。（這個過程比較艱難，若是一時無法理解，谷歌一下相關知識。或者請留言前提是你已經研究了一小時了仍是隻知其一;不知其二）

節點 A 將變長報文提取爲定長的摘要 節點（把A當作瀏覽器也就是客戶端）

A 對摘要應用了一個「簽名」函數，這個簽名函數就是 數字證書裏面約好的。這個函數會將用戶的私有密鑰做爲參數。 由於只有用戶B（服務器）才知道私有密鑰，因此正確的簽名函數會說明簽名者就是其全部者。 在圖中，因爲解碼函數 D 中 包含了用戶（服務器）的私有密鑰，因此咱們將其做爲簽名函數使用（RSA 加密系統將解碼函數 D 做爲簽名函數使用，是由於 D 已經將私有密鑰做爲輸入使用了。注意， 解碼函數只是一個函數，所以，能夠將其用於任意的輸入。一樣，在 RSA 加密系統中，以任意順序 應用 D 和 E 函數時， 二者都會相互抵消。所以 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 同樣） 注意：這裏請用工程思想去理解，也就是私有密鑰做爲參數這句話，只有服務器才知道私有密鑰。

一旦計算出簽名，節點 A 就將其附加在報文的末尾，並將報文和簽名都發送給B 在接收端，若是節點 B 須要肯定報文確實是節點 A 寫的，並且沒有被篡改過， 節點 B 就能夠對簽名進行檢查。節點 B 接收經私有密鑰擾碼的簽名，並應用了 使用公開密鑰的反函數。若是拆包後的摘要與節點 B 本身的摘要版本不匹配，要 麼就是報文在傳輸過程當中被篡改了，要麼就是發送端沒有節點 A 的私有密鑰（也 就是說它不是節點 A）

用大白話說：這個過程就是驗證A就是瀏覽器,用戶就是服務器。而不是中間者（或者黑客）。瀏覽器知道數字證書上的簽名函數，對發送的報文生成一個很是小的摘要信息。那麼這個信息就是惟一不可改變的信息。服務器收到後用公開密鑰（固然應用了私有密鑰 ）獲得報文摘要C。而後本身再用一樣的簽名函數對明文獲得報文摘要D。若是C==D，說明驗證成功。不然就是有問題的。

當你看到這裏說明你已經成功70%了！！！

第三步：

當Client與Server端都持有AES_KEY後，就能夠對HTTP報文進行加解密了。這裏就再也不是RSA了，而是使用對稱加密，就算被第三方劫持，第三方也不知道密碼。除非其中一我的把密碼告訴第三方。這裏使用對稱加密也是爲了提升HTTPS的性能。由於自己HTTPS所消耗的時間也是不可忽視的。我能夠看一下掘金的用例：

經過代理以隧道形式傳輸安全流量

CONNECT 方法請求隧道網關建立一條到達任意目的服務器和端口的 TCP 鏈接，並 對客戶端和服務器之間的後繼數據進行盲轉發。 

客戶端一般會用 Web 代理服務器表明它們來訪問 Web 服務器。比 如，不少公司都會在公司網絡和公共因特網的安全邊界上放置一個代理。代理是防火牆路由器惟一容許進行 HTTP 流量交換的設備，它可能會進行 病毒檢測或其餘的內容控制工做。但只要客戶端開始用服務器的公開密鑰對發往服務器的數據進行加密，代理就再也 不能讀取 HTTP 首部了!代理不能讀取 HTTP 首部，就沒法知道應該將請求轉向何 處了。

爲了使 HTTPS 與代理配合工做，要進行幾處修改以告知代理鏈接到何處。一種常 用的技術就是 HTTPS SSL 隧道協議。使用 HTTPS 隧道協議，客戶端首先要告知代 理，它想要鏈接的安全主機和端口。這是在開始加密以前，以明文形式告知的，所 以代理能夠理解這條信息。

 HTTP 經過新的名爲 CONNECT 的擴展方法來發送明文形式的端點信息。CONNECT 方 法會告訴代理，打開一條到所指望主機和端口號的鏈接。這項工做完成以後，直接 在客戶端和服務器之間以隧道形式傳輸數據。CONNECT 方法就是一條單行的文本命 令，它提供了由冒號分隔的安全原始服務器的主機名和端口號。host:port 後面跟 着一個空格和 HTTP 版本字符串，再後面是 CRLF。接下來是零個或多個 HTTP 請 求首部行，後面跟着一個空行。空行以後，若是創建鏈接的握手過程成功完成，就能夠開始傳輸 SSL 數據了。

It's over。

是否是特別詳細咩～歡迎指出不正之處！