HTTPS加密原理

2021-08-16 21:58:16 字數 2724 閱讀 9840

字數 2314

閱讀 630

喜歡 90

http、https在我們日常開發中是經常會接觸到的。

我們也都知道,一般 android 應用開發,在請求 api 網路介面的時候,很多使用的都是 http 協議;使用瀏覽器開啟網頁,也是利用 http 協議。看來 http 真是使用廣泛啊,但是,http 是不安全的。利用網路抓包工具就可以知道傳輸中的內容,一覽無餘。比如我經常會使用 fiddler 來抓包,蒐集一些有趣的 api 介面。

那麼問題來了,如何保證 http 的安全性呢?基本上所有的人都會脫口而出:使用 https 協議。99.9% 的人都知道 https 會將傳輸的內容進行加密,但是接著問具體加密的過程和步驟,很多人就啞口無言了。

為了防止出現這種尷尬的局面,所以今天你就要好好看看這篇的內容了。以後就可以裝個逼,哈哈!

先科普一下,加密演算法的型別基本上分為了兩種:

對稱加密的意思就是說雙方都有乙個共同的金鑰,然後通過這個金鑰完成加密和解密,這種加密方式速度快,但是安全性不如非對稱加密好。

舉個例子,現在學霸小明這裡有一道數學題的答案:123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前,約定了一把金鑰:456 。那麼小明就把答案內容經過金鑰加密,即 123 + 456 = 579 ,將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條,不知道他們是加密傳輸的,看到上面的 579 ,會誤以為答案就是 579 ;如果是小紅撿到了,她拿出金鑰解密,579 - 456 = 123 ,得到了正確的答案。

這就是所謂的對稱加密,加解密效率高,速度快,但是雙方任何一方不小心洩露了金鑰,那麼任何人都可以知道傳輸內容了。

講完了對稱加密,我們看看啥是非對稱加密。

非對稱加密就是有兩把金鑰,公鑰和私鑰。私鑰自己藏著,不告訴任何人;而公鑰可以公開給別人。

經過了上次作弊後,小紅發現了對稱加密如果金鑰洩露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰,然後把公鑰公開,小明就得到了公鑰。小明拿到公鑰後,把答案經過公鑰加密,然後傳輸給小紅,小紅再利用自己的私鑰進行解密,得到答案結果。如果在這個過程中,其他人得到傳輸的內容,而他們只有小紅公鑰,是沒有辦法進行解密的,所以也就得不到答案,只有小紅乙個人可以解密。

因此,相比較對稱加密而言,非對稱加密安全性更高,但是加解密耗費的時間更長,速度慢。

對稱加密和非對稱加密的具體應用我還是深有體會的,因為所在的公司是做金融支付方面的,所以加解密基本上算是天天見了。

說完加密型別後,我們再來看看 https 。

我們先來看乙個公式:

從這個公式中可以看出,https 和 http 就差在了 ssl 上。所以我們可以猜到,https 的加密就是在 ssl 中完成的。

所以我們的目的就是要搞懂在 ssl 中究竟幹了什麼見不得人的事了?

這就要從 ca 證書講起了。ca 證書其實就是數字證書,是由 ca 機構頒發的。至於 ca 機構的權威性,那麼是毋庸置疑的,所有人都是信任它的。ca 證書內一般會包含以下內容:

正好我們把客戶端如何校驗 ca 證書的步驟說下吧。

ca 證書中的 hash 值,其實是用證書的私鑰進行加密後的值(證書的私鑰不在 ca 證書中)。然後客戶端得到證書後,利用證書中的公鑰去解密該 hash 值,得到 hash-a ;然後再利用證書內的簽名 hash 演算法去生成乙個 hash-b 。最後比較 hash-a 和 hash-b 這兩個的值。如果相等,那麼證明了該證書是對的,服務端是可以被信任的;如果不相等,那麼就說明該證書是錯誤的,可能被篡改了,瀏覽器會給出相關提示,無法建立起 https 連線。除此之外,還會校驗 ca 證書的有效時間和網域名稱匹配等。

接下來我們就來詳細講一下 https 中的 ssl 握手建立過程,假設現在有客戶端 a 和伺服器 b :

伺服器 b 知道這些資訊後,然後確認一下雙方的加密演算法,然後服務端也生成乙個隨機數 b ,並將隨機數 b 和 ca 頒發給自己的證書一同返回給客戶端 a 。

客戶端 a 得到 ca 證書後,會去校驗該 ca 證書的有效性,校驗方法在上面已經說過了。校驗通過後,客戶端生成乙個隨機數3 ,然後用證書中的公鑰加密隨機數3 並傳輸給服務端 b 。

服務端 b 得到加密後的隨機數3,然後利用私鑰進行解密,得到真正的隨機數3。

最後,客戶端 a 和服務端 b 都有隨機數1、隨機數2、隨機數3,然後雙方利用這三個隨機數生成乙個對話金鑰。之後傳輸內容就是利用對話金鑰來進行加解密了。這時就是利用了對稱加密,一般用的都是 aes 演算法。

客戶端 a 通知服務端 b ,指明後面的通訊用對話金鑰來完成,同時通知伺服器 b 客戶端 a 的握手過程結束。

服務端 b 通知客戶端 a,指明後面的通訊用對話金鑰來完成,同時通知客戶端 a 伺服器 b 的握手過程結束。

ssl 的握手部分結束,ssl 安全通道的資料通訊開始,客戶端 a 和伺服器 b 開始使用相同的對話金鑰進行資料通訊。

到此,ssl 握手過程就講完了。可能上面的流程太過於複雜,我們簡單地來講:

客戶端和服務端建立 ssl 握手,客戶端通過 ca 證書來確認服務端的身份;

互相傳遞三個隨機數,之後通過這隨機數來生成乙個金鑰;

互相確認金鑰,然後握手結束;

資料通訊開始,都使用同乙個對話金鑰來加解密;

我們可以發現,在 https 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點,又利用了對稱加密速度快,效率高的好處。真的是設計得非常精妙,令人讚不絕口。

好了,https 加密原理到這就講的差不多了,不知道電腦前的你有沒有看懂呢?

bye ~~

出處:

HTTPS加密原理

http是超文字傳輸協議,是一種客戶端和伺服器端請求和應答的標準,可以使瀏覽器更加高效。https是以安全為目標的http通道,https是在http基礎上加上ssl層 https協議需要ca證書認證,費用較高 http是超文字傳輸協議,資訊是明文傳輸 https是具有安全性的ssl加密傳輸協議 使...

https 加密原理

最近因為專案需求,需要將http公升級到https,所以抽空 了下其中的加密原理。為什麼要使用https http 明文傳輸,不夠安全。竊聽風險 黑客可以獲知通訊內容。篡改風險 黑客可以修改通訊內容。冒充風險 黑客可以冒充他人身份參與通訊。為了保障訊息的保密性,後面出現了對稱加密以及非對稱加密 對稱...

https 的加密原理

1.http 協議 hypertext transfer protocol,超文字傳輸協議 是客戶端瀏覽器或其他程式與web伺服器之間的應用層通訊協議 https 協議 hypertext transfer protocol over secure socket layer 可以理解為 http s...