HTTPS原理解析

開門見山地說，眾所周知，https=http+ssl/tls，使用非對稱加密演算法+對稱加密演算法的混合加密演算法。

最近在面試過程中被問到幾次這個問題，看過幾篇部落格，說的都不是很清楚，理解也有偏差，毫無意外的面試都掛了，今天看到了阮一峰老師的部落格——**ssl/tls

協議，終於有一種醍醐灌頂的感覺。

五次握手建立ssl連線：該部分主要為了產生後續傳輸資料的秘密金鑰

建立連線後，後續就與非對稱加密演算法沒有關係了，後續使用對稱加密的秘密金鑰進行資料互動。

先上圖（出自阮一峰老師的部落格，位址在文章開頭）

下面流程中的公鑰和私鑰均指非對稱加密演算法的公鑰和私鑰）

伺服器把server random——隨機數2、對稱加密演算法（在客戶端支援的加密演算法範圍中確認乙個）以及包含公鑰證書傳送給客戶端

客戶端接收到第二步的資訊之後，需要確認公鑰證書（記住這個證書只包含公鑰）是來自伺服器的，這我們後面再說，確認之後，生成乙個premaster secret——隨機數3（預主金鑰），並使用公鑰證書中的公鑰加密premaster secret，得到encrypted premaster secret並將其傳送給伺服器

伺服器收到encrypted premaster secret並使用私鑰解密得到premaster secret。（ok，到此為止，客服端和伺服器均有了隨機數1、隨機數2和隨機數3）

客服端和伺服器使用三個隨機數和第二步約定的加密演算法生成秘密金鑰，用於後面傳輸資料時明文資料的加密

現在，ssl連線已經建立了，從上面的流程可以看出來：非對稱加密演算法只用過一次，非對稱加密演算法本身的效能消耗很大，使用頻繁很消耗效能。

剛剛我們上面遺留了乙個問題，五次握手第二步伺服器傳送給客戶端的公鑰證書有可能被中間人擷取並篡改，那麼客戶端如何確認公鑰證書是來自伺服器而不是中間人呢？

這裡ca證書機構就要上場了，在介紹這個過程前需要先介紹幾個概念：摘要、數字簽名

摘要：通過單向hash函式對原文進行雜湊，將需加密的明文「摘要」成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一致，並且即使知道了摘要也不能反推出明文。

數字簽名：建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術。

（以上摘自

下面陳述中，單獨的公鑰私鑰依然指伺服器的公鑰和私鑰，ca私鑰、公鑰會特別說明

ca 通過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有網域名稱的所有權等

如果審核通過則向s頒發證書，證書資訊包含申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 ca 的資訊、有效時間、證書序列號等資訊的明文，同時包含乙個簽名，該簽名生成方法：證書資訊明文經過hash雜湊函式生成摘要，然後通過ca私鑰對摘要進行加密生成的密文就是數字簽名。

客戶端驗證公鑰證書

ok，介紹了這麼多，終於要介紹前面遺留的問題了。

現在的情況是，伺服器擁有了ca機構頒發的證書和ca公鑰，客戶端擁有ca公鑰（瀏覽器內建ca根證書）。

伺服器將包含公鑰的證書傳送給客戶端（這裡指瀏覽器），證書中包含公鑰、組織資訊、有效期等資訊，還有乙個ca私鑰加密過的數字簽名。

客戶端使用ca公鑰對數字簽名解密得到摘要1；客戶端讀取證書中的相關的明文資訊，採用相同的雜湊函式計算得到摘要2，對比摘要1和摘要2，相等則說明證書有效。

HTTPS原理解析

我們用https的目的是什麼？為了 a端與b端互發的訊息 就算被攔截獲取到也是加密了無法檢視的，通用的加密 解密過程如下 以上的過程分析如下 1 a端傳入加密串 xx 進a端的加密方法中，加密處理後假設生成了 fwe y h 2 然後a端將 fwe y h 傳送到b端。3 b端接收到 fwe y h...

HTTPS原理解析

https的驗證流程 延伸的問題 如果中間人自己向權威機構申請乙個證書，並且把服務端發來的證書進行偷換成自己的證書，該如何？並不能造成危害，因為證書的簽名是由服務端 等資訊生成的，並且經過機構私鑰加密，中間人無法篡改。所以，發個服務端的證書是無法通過驗證的。https的缺點 https和http的區...

https原理解析

最近公司分享會講了這塊的內容，於是就學習了一下。在客戶端和伺服器中作怪的中間人無非做三件事 竊聽 假冒 篡改 https的出現就是為了防止中間人作怪的。這裡要引入兩個概念 想想，兩方通訊若是直接明文傳輸，相當於打 中開著揚聲器，巴拉巴拉，周圍的人都能聽到，有危險的機率不言而喻。所以我們就要加密，用什...