之前看過很多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。
是不是特別詳細咩～歡迎指出不正之處！