大家都知道，在客戶端與服務器數據傳輸的過程中，HTTP協議的傳輸是不安全的，也就是一般情況下HTTP是明文傳輸的。但HTTPS協議的數據傳輸是安全的，也就是說HTTPS數據的傳輸是經過加密的。

在客戶端與服務器這兩個完全沒有見過面的陌生人交流中，HTTPS是如何保證數據傳輸的安全性的呢？下面我將帶大家一步步了解HTTPS是如何加密才得以保證數據傳輸的安全性的。

我們先把客戶端稱為小客，服務器稱為小服。然后一步步探索在小客與小服的交流中（就是一方請求一方響應），HTTPS是如何保證他們的交流不會被中間人竊聽的。

對稱加密

假如現在小客與小服要進行一次私密的對話，他們不希望這次對話內容被其他外人知道。可是，我們平時的數據傳輸過程中又是明文傳輸的，萬一被某個黑客把他們的對話內容給竊取了，那就難受了。

為了解決這個問題，小服這家伙想到了一個方法來加密數據，讓黑客看不到具體的內容。該方法是這樣子的：

在每次數據傳輸之前，小服會先傳輸給小客一把密鑰，然后小服在之后給小客發消息的過程中，會用這把密鑰對這些消息進行加密。小客在收到這些消息后，會用之前小服給的那把密鑰對這些消息進行解密，這樣，小客就能得到密文里面真正的數據了。如果小客要給小服發消息，也同樣用這把密鑰來對消息進行加密，小服收到后也用這把密鑰進行解密。 

這樣，就保證了數據傳輸的安全性。如圖所示：

這種方法稱之為對稱加密，加密和解密都用同一把密鑰。

這時，小服想著自己的策咯，還是挺得意的。但這個策略安全的前提是，小客擁有小服的那把密鑰。可問題是，小服是以明文的方式把這把密鑰傳輸給小客的，如果黑客截取了這把密鑰，小服與小客就算是加密了內容，在截取了密鑰的黑客老哥眼里，這和明文沒啥區別。

非對稱加密

小服還是挺聰明的，意識到了密鑰會被截取這個問題，他又想到了另外一種方法：用非對稱加密的方法來加密數據。方法如下：

小服和小客都擁有兩把鑰匙，一把鑰匙是公開的（全世界都知道也沒關系），稱之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道），稱之為私鑰。并且，用公鑰加密的數據，只有對應的私鑰才能解密；用私鑰加密的數據，只有對應的公鑰才能解密。

所以在傳輸數據的過程中，小服在給小客傳輸數據的過程中，會用小客給他的公鑰進行加密，然后小客收到后，再用自己的私鑰進行解密。小客給小服發消息的時候，也一樣會用小服給他的公鑰進行加密，然后小服再用自己的私鑰進行解密。

這樣，數據就能安全到達雙方。如圖：

想著這么復雜的策略都能想出來，小服可是得意的不能再得意了…..還沒等小服得意多久，小客就給它潑了一波冷水。

小客嚴肅著說：其實，你的這種方法也不是那么安全啊，還是存在被黑客截取的危險啊。例如：

你在給我傳輸公鑰的過程中，如果黑客截取了你的公鑰，并且拿著自己的公鑰來冒充你的公鑰來發給我。我收到公鑰之后，會用公鑰進行加密傳輸（這時用的公鑰實際上是黑客的公鑰）。黑客截取了加密的消息之后，可以用他自己的私鑰來進行解密來獲取消息內容。然后再用你（小服）的公鑰來對消息進行加密，之后再發給你（小服）。 這樣子，我們的對話內容還是被黑客給截取了（倒過來小客給小服傳輸公鑰的時候也一樣）。

......這么精妙的想法居然也不行，小服這波，滿臉無神。

這里插講下，其實在傳輸數據的過程中，在速度上用對稱加密的方法會比非對稱加密的方法快很多。所以在傳輸數據的時候，一般不單單只用非對稱加密這種方法（我們先假設非對稱密碼這種方法很安全），而是會用非對稱加密 + 對稱加密這兩種結合的方法。基于這個，我們可以用非對稱加密方法來安全著傳輸密鑰，之后再用對稱加密的方法來傳輸消息內容（當然，我這里假定了非對稱加密傳輸是安全的，下面會講如何使之安全）。

數字證書

我們回頭想一下，是什么原因導致非對稱加密這種方法的不安全性呢？它和對稱加密方法的不安全性不同。非對稱加密之所以不安全，是因為小客收到了公鑰之后，無法確定這把公鑰是否真的屬于小服。

也就是說，我們需要找到一種策略來證明這把公鑰就是小服的，而不是別人冒充的。

為了解決這個問題，小服和小客絞盡腦汁想出了一種終極策略：數字證書——我們需要找到一個擁有公信力、大家都認可的認證中心（CA）。小服在給小客發公鑰的過程中，會把公鑰以及小服的個人信息通過Hash算法生成消息摘要。如圖：

為了防止摘要被人調換，小服還會用CA提供的私鑰對消息摘要進行加密來形成數字簽名。如圖：

并且，最后還會把原來沒Hash算法之前的信息和數字簽名合并在一起，形成數字證書。如圖：

當小客拿到這份數字證書之后，就會用CA提供的公鑰來對數字證書里面的數字簽名進行解密得到消息摘要，然后對數字證書里面小服的公鑰和個人信息進行Hash得到另一份消息摘要，然后把兩份消息摘要進行對比，如果一樣，則證明這些東西確實是小服的，否則就不是。如圖：

這時可能有人會有疑問，CA的公鑰是怎么拿給小客的呢？小服又怎么有CA的私鑰呢？

其實，（有些）服務器在一開始就向認證中心申請了這些證書，而客戶端里，也會內置這些證書。如圖（此圖來元阮一峰的網絡日志）：

當客戶端收到服務器返回來的數據時，就會在內置的證書列表里，查看是否有有解開該數字證書的公鑰。

河南億恩科技股份有限公司(www.zuiquanben.com)始創于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網站建設、網站托管等網絡基礎服務，另有網總管、名片俠網絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900