HTTPS 如何保證資料傳輸的安全性?
大家都知道,在客戶端與伺服器資料傳輸的過程中,HTTP協議的傳輸是不安全的,也就是一般情況下HTTP是明文傳輸的。但HTTPS協議的資料傳輸是安全的,也就是說HTTPS資料的傳輸是經過加密的。
在客戶端與伺服器這兩個完全沒有見過面的陌生人交流中,HTTPS是如何保證資料傳輸的安全性的呢?下面我將帶大家一步步瞭解HTTPS是如何加密才得以保證資料傳輸的安全性的。
我們先把客戶端稱為小客,伺服器稱為小服。然後一步步探索在小客與小服的交流中(就是一方請求一方響應),HTTPS是如何保證他們的交流不會被中間人竊聽的。
對稱加密
假如現在小客與小服要進行一次私密的對話,他們不希望這次對話內容被其他外人知道。可是,我們平時的資料傳輸過程中又是明文傳輸的,萬一被某個黑客把他們的對話內容給竊取了,那就難受了。
為了解決這個問題,小服這傢伙想到了一個方法來加密資料,讓黑客看不到具體的內容。該方法是這樣子的:
在每次資料傳輸之前,小服會先傳輸給小客一把金鑰,然後小服在之後給小客發訊息的過程中,會用這把金鑰對這些訊息進行加密。小客在收到這些訊息後,會用之前小服給的那把金鑰對這些訊息進行解密,這樣,小客就能得到密文裡面真正的資料了。如果小客要給小服發訊息,也同樣用這把金鑰來對訊息進行加密,小服收到後也用這把金鑰進行解密。
這樣,就保證了資料傳輸的安全性。如圖所示:
這種方法稱之為對稱加密,加密和解密都用同一把金鑰。
這時,小服想著自己的策咯,還是挺得意的。但這個策略安全的前提是,小客擁有小服的那把金鑰。可問題是,小服是以明文的方式把這把金鑰傳輸給小客的,如果黑客截取了這把金鑰,小服與小客就算是加密了內容,在截取了金鑰的黑客老哥眼裡,這和明文沒啥區別。
非對稱加密
小服還是挺聰明的,意識到了金鑰會被擷取這個問題,他又想到了另外一種方法:用非對稱加密的方法來加密資料。方法如下:
小服和小客都擁有兩把鑰匙,一把鑰匙是公開的(全世界都知道也沒關係),稱之為公鑰;而另一把鑰匙是保密(也就是隻有自己才知道),稱之為私鑰。並且,用公鑰加密的資料,只有對應的私鑰才能解密;用私鑰加密的資料,只有對應的公鑰才能解密。
所以在傳輸資料的過程中,小服在給小客傳輸資料的過程中,會用小客給他的公鑰進行加密,然後小客收到後,再用自己的私鑰進行解密。小客給小服發訊息的時候,也一樣會用小服給他的公鑰進行加密,然後小服再用自己的私鑰進行解密。
這樣,資料就能安全到達雙方。如圖:
想著這麼複雜的策略都能想出來,小服可是得意的不能再得意了…..還沒等小服得意多久,小客就給它潑了一波冷水。
小客嚴肅著說:其實,你的這種方法也不是那麼安全啊,還是存在被黑客擷取的危險啊。例如:
你在給我傳輸公鑰的過程中,如果黑客截取了你的公鑰,並且拿著自己的公鑰來冒充你的公鑰來發給我。我收到公鑰之後,會用公鑰進行加密傳輸(這時用的公鑰實際上是黑客的公鑰)。黑客截取了加密的訊息之後,可以用他自己的私鑰來進行解密來獲取訊息內容。然後再用你(小服)的公鑰來對訊息進行加密,之後再發給你(小服)。 這樣子,我們的對話內容還是被黑客給截取了(倒過來小客給小服傳輸公鑰的時候也一樣)。
......這麼精妙的想法居然也不行,小服這波,滿臉無神。
這裡插講下,其實在傳輸資料的過程中,在速度上用對稱加密的方法會比非對稱加密的方法快很多。所以在傳輸資料的時候,一般不單單隻用非對稱加密這種方法(我們先假設非對稱密碼這種方法很安全),而是會用非對稱加密 + 對稱加密這兩種結合的方法。基於這個,我們可以用非對稱加密方法來安全著傳輸金鑰,之後再用對稱加密的方法來傳輸訊息內容(當然,我這裡假定了非對稱加密傳輸是安全的,下面會講如何使之安全)。
數字證書
我們回頭想一下,是什麼原因導致非對稱加密這種方法的不安全性呢?它和對稱加密方法的不安全性不同。非對稱加密之所以不安全,是因為小客收到了公鑰之後,無法確定這把公鑰是否真的屬於小服。
也就是說,我們需要找到一種策略來證明這把公鑰就是小服的,而不是別人冒充的。
為了解決這個問題,小服和小客絞盡腦汁想出了一種終極策略:數字證書——我們需要找到一個擁有公信力、大家都認可的認證中心(CA)。小服在給小客發公鑰的過程中,會把公鑰以及小服的個人資訊通過Hash演算法生成訊息摘要。如圖:
為了防止摘要被人調換,小服還會用CA提供的私鑰對訊息摘要進行加密來形成數字簽名。如圖:
並且,最後還會把原來沒Hash演算法之前的資訊和數字簽名合併在一起,形成數字證書。如圖:
當小客拿到這份數字證書之後,就會用CA提供的公鑰來對數字證書裡面的數字簽名進行解密得到訊息摘要,然後對數字證書裡面小服的公鑰和個人資訊進行Hash得到另一份訊息摘要,然後把兩份訊息摘要進行對比,如果一樣,則證明這些東西確實是小服的,否則就不是。如圖:
這時可能有人會有疑問,CA的公鑰是怎麼拿給小客的呢?小服又怎麼有CA的私鑰呢?
其實,(有些)伺服器在一開始就向認證中心申請了這些證書,而客戶端裡,也會內建這些證書。如圖(此圖來元阮一峰的網路日誌):
當客戶端收到伺服器返回來的資料時,就會在內建的證書列表裡,檢視是否有有解開該數字證書的公鑰。