一文看懂https如何保證資料傳輸的安全性的
一文看懂https如何保證資料傳輸的安全性的
大家都知道,在客戶端與伺服器資料傳輸的過程中,http協議的傳輸是不安全的,也就是一般情況下http是明文傳輸的。但https協議的資料傳輸是安全的,也就是說https資料的傳輸是經過加密。
在客戶端與伺服器這兩個完全沒有見過面的陌生人交流中,https是如何保證資料傳輸的安全性的呢?
下面我將帶大家一步步瞭解https是如何加密才得以保證資料傳輸的安全性的。我們先把客戶端稱為小客,伺服器稱為小服。然後一步步探索在小客與小服的交流中(就是一方請求一方響應),https是如何保證他們的交流不會被中間人竊聽的。
1. 對稱加密
假如現在小客與小服要進行一次私密的對話,他們不希望這次對話內容被其他外人知道。可是,我們平時的資料傳輸過程中又是明文傳輸的,萬一被某個黑客把他們的對話內容給竊取了,那就難受了。
為了解決這個問題,小服這傢伙想到了一個方法來加密資料,讓黑客看不到具體的內容。該方法是這樣子的:
在每次資料傳輸之前,小服會先傳輸小客一把金鑰,然後小服在之後給小客發訊息的過程中,會用這把金鑰對這些訊息進行加密。小客在收到這些訊息後,會用之前小服給的那把金鑰對這些訊息進行解密,這樣,小客就能得到密文裡面真正的資料了。如果小客要給小服發訊息,也同樣用這把金鑰來對訊息進行加密,小服收到後也用這把金鑰進行解密。 這樣,就保證了資料傳輸的安全性。如圖所示:
這時,小服想著自己的策咯,還是挺得意的。
可是,這時候問題來了。這個策略安全的前提是,小客擁有小服的那把金鑰。可問題是,小服是以明文的方式把這把金鑰傳輸給小客的,這個時候,如果黑客擷取了這把金鑰,那就難受了。小服與小客就算是加密了內容,在擷取了金鑰的黑客老哥眼裡,這和明文沒啥區別。
2. 非對稱加密
小服還是挺聰明的,得意了一會之後,小服意識到了金鑰會被擷取這個問題。倔強的小服又想到了另外一種方法:用非對稱加密的方法來加密資料。該方法是這樣的:
小服和小客都擁有兩把鑰匙,一把鑰匙的公開的(全世界都知道也沒關係),稱之為公鑰;而另一把鑰匙是保密(也就是隻有自己才知道),稱之為私鑰。並且,用公鑰加密的資料,只有對應的私鑰才能解密;用私鑰加密的資料,只有對應的公鑰才能解密。
所以在傳輸資料的過程中,小服在給小客傳輸資料的過程中,會用小客給他的公鑰進行加密,然後小客收到後,再用自己的私鑰進行解密。小客給小服發訊息的時候,也一樣會用小服給他的公鑰進行加密,然後小服再用自己的私鑰進行解密。 這樣,資料就能安全著到達雙方。如圖:
想著這麼複雜的策略都能想出來,小服可是得意的不能在得意了…..
看著那麼得意的小服,小客這時心情就不得好了。還沒等小服得意多久,小客就給它潑了一波冷水了。
小客嚴肅著說:其實,你的這種方法也不是那麼的安全啊。還是存在被黑客擷取的危險啊。例如:
你在給我傳輸公鑰的過程中,如果黑客擷取了你的公鑰,並且拿著自己的公鑰來冒充你的公鑰來發給我。我收到公鑰之後,會用公鑰進行加密傳輸(這時用的公鑰實際上是黑客的公鑰)。黑客擷取了加密的訊息之後,可以用他自己的私鑰來進行解密來獲取訊息內容。然後在用你(小服)的公鑰來對訊息進行加密,之後再發給你(小服)。 這樣子,我們的對話內容還是被黑客給擷取了啊。(倒過來小客給小服傳輸公鑰的時候也一樣)。
我靠,這麼精妙的想法居然也不行,小服這波,滿臉無神。
## 插講下 ##
其實在傳輸資料的過程中,在速度上用對稱加密的方法會比非對稱加密的方法快很多。所以在傳輸資料的時候,一般不單單隻用非對稱加密這種方法(我們先假設非對稱密碼這種方法很安全),而是會用非對稱加密 + 對稱加密這兩種結合的方法。 你想啊,對於對稱加密這種方法來說,之所以不安全是因為金鑰在傳輸的過程中,被別人知道了。基於這個,我們可以用非對稱加密方法來安全著傳輸金鑰,之後在用對稱加密的方法來傳輸訊息內容(當然,我這裡假定了非對稱加密傳輸是安全的,下面會講如何使之安全)。
數字證書
我們回頭想一下,是什麼原因導致非對稱加密這種方法的不安全性呢?它和對稱加密方法的不安全性不同。非對稱加密之所以不安全,是因為小客收到了公鑰之後,無法確定這把公鑰是否真的是小服。
也就是說,我們需要找到一種策略來證明這把公鑰就是小服的,而不是別人冒充的。
為了解決這個問題,小服和小客通過絞盡腦汁想出了一種終極策略:數字證書:
我們需要找到一個擁有公信力、大家都認可的認證中心(CA)
小服再給小客發公鑰的過程中,會把公鑰以及小服的個人資訊通過Hash演算法生成訊息摘要。如圖:
為了防止摘要被人調換,小服還會用CA提供的私鑰對訊息摘要進行加密來形成數字簽名。如圖:
並且,最後還會把原來沒Hash演算法之前的資訊和數字簽名合併在一起,形成數字證書。如圖:
當小客拿到這份數字證書之後,就會用CA提供的公鑰來對數字證書裡面的數字簽名進行解密得到訊息摘要,然後對數字證書裡面小服的公鑰和個人資訊進行Hash得到另一份訊息摘要,然後把兩份訊息摘要進行對比,如果一樣,則證明這些東西確實是小服的,否則就不是。如圖:
這時可能有人會有疑問,CA的公鑰是怎麼拿給小客的呢?小服又怎麼有CA的私鑰呢?其實,(有些)伺服器在一開始就向認證中心申請了這些證書,而客戶端裡,也會內建這些證書。如圖(此圖來元阮一峰的網路日誌)
當客戶端收到伺服器返回來的資料時,就會在內建的證書列表裡,檢視是否有有解開該數字證書的公鑰,如果有則…..否則…..
講到這裡,就大概結束了。希望對你有所幫助勒。如果有哪裡寫得不對的地方,歡迎大家指出。
相關文章
- 一文讓你看懂,https如何保證資料傳輸的安全性HTTP
- HTTPS 如何保證資料傳輸安全HTTP
- HTTPS是怎麼保證資料安全傳輸的?HTTP
- TCP協議如何保證資料的順序傳輸TCP協議
- 計算機網路——如何保證網路傳輸的安全性計算機網路
- 如何提高大資料傳輸的安全性大資料
- 如何保證MongoDB的安全性?MongoDB
- 談談資料傳輸中的安全性
- 《Apache資料傳輸加密、證書的製作》——涉及HTTPS協議Apache加密HTTP協議
- 資料傳輸 | 如何開啟 DTLE 的 HTTPS 訪問模式HTTP模式
- 如何保證訊息佇列的可靠性傳輸?佇列
- 前後端API互動如何保證資料安全性?後端API
- 訊息佇列之如何保證訊息的可靠傳輸佇列
- HTTPS 是如何進行安全傳輸的 ?HTTP
- HMAC演算法:資料傳輸的保護神Mac演算法
- 一文看懂怎麼快捷、安全地實現製造裝置資料傳輸
- 完成資料的跨界傳輸與驗證
- 如何衝破傳統傳輸形態帶來的風險,保護核心研發資料?
- 一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等HTTP
- 為什麼說HTTPS比HTTP安全? HTTPS是如何保證安全的?HTTP
- 前後端資料的互動--如何確保前後端資料的安全性?後端
- 雲端計算時代前端如何保證開原始碼的安全性前端原始碼
- 企業跨境檔案傳輸的核心痛點,怎樣保證穩定可靠的傳輸效能?
- 鐳速傳輸:保護企業資料傳輸和檔案傳輸的最佳解決方案是什麼?
- Oracle Goldengate是如何保證資料有序和確保資料不丟失的?OracleGo
- MQ系列11:如何保證訊息可靠性傳輸(除夕奉上)MQ
- 如何能保證頁面顯示的資料與資料庫的資料同步資料庫
- 超大型的檔案資料如何傳輸?
- 專案中對外暴露的http介面的安全性如何保證HTTP
- 深入理解Https如何保證通訊安全HTTP
- Elasticsearch如何保證資料不丟失?Elasticsearch
- 海量資料架構下如何保證Mycat的高可用?架構
- 如何透過防洩密隨身碟,實現資料傳輸的安全性及可控性?
- 如何替代傳統的方式,提高能源企業敏感檔案傳輸的安全性?
- iPaas資料傳輸的方式
- HTTPS是如何保證連線安全:每位Web開發者都應知道的HTTPWeb
- 遠端辦公如何保證資料安全?
- 讓機臺資料傳輸更高效可靠,一文了解!