掃盲https和TLS協議

2021-08-20 12:14:10 字數 2389 閱讀 1279

可靠金鑰交換的原理

ssl/tls 協議的實現

針對 https 的各種攻擊手法

各種相應的防範措施

https 協議的需求是啥?

設計 https 協議的主要難點

結尾相關背景知識

大致了解 http 和 tcp 的關係(尤其是「短連線」vs「長連線」)

大致了解加密演算法的概念(尤其是「對稱加密與非對稱加密」的區別)

大致了解 ca 證書的用途

單獨使用乙個新的協議,把 http 協議包裹起來 

(所謂的「http over ssl」,實際上是在原有的 http 資料外面加了一層 ssl 的封裝。http 協議原有的 get、post 之類的機制,基本上原封不動)

如何兼顧 http 採用的「短連線」tcp 方式?

方案1——單純用「對稱加密演算法」的可行性

方案2——單純用「非對稱加密演算法」的風險

方案2失敗的根源——缺乏【可靠的】身份認證

身份認證的幾種方式

如何解決 ssl 的身份認證問題——ca 的引入

方案3——基於 ca 證書進行金鑰交換

關於「客戶端證書」

結尾第2步 

**把 k1 保留在自己手中,把 k2 用【明文】的方式傳送給訪問者的瀏覽器。 

因為 k2 是明文傳送的,自然有可能被**。不過不要緊。即使**者拿到 k2,也【很難】根據 k2 推算出 k1 

(這一點是由「非對稱加密演算法」從數學上保證的)。

第3步 

瀏覽器拿到 k2 之後,先【隨機生成】第三個對稱加密的金鑰(簡稱 k)。 

然後用 k2 加密 k,得到 k』(k』 是 k 的加密結果) 

瀏覽器把 k』 傳送給**伺服器。

由於 k1 和 k2 是成對的,所以只有 k1 才能解密 k2 的加密結果。 

因此這個過程中,即使被第三方**,第三方也【無法】從 k』 解密得到 k

第4步 

**伺服器拿到 k』 之後,用 k1 進行解密,得到 k 

至此,瀏覽器和**伺服器就完成了金鑰交換,雙方都知道 k,而且【貌似】第三方無法拿到 k 

然後,雙方就可以用 k 來進行資料雙向傳輸的加密。

第2步 

當**傳送 k2 給瀏覽器的時候,攻擊者截獲 k2,保留在自己手上。 

然後攻擊者自己生成乙個【偽造的】金鑰對(以下稱為 pk1 和 pk2)。 

攻擊者把 pk2 傳送給瀏覽器。

第3步 

瀏覽器收到 pk2,以為 pk2 就是**傳送的。 

瀏覽器不知情,依舊隨機生成乙個對稱加密的金鑰 k,然後用 pk2 加密 k,得到密文的 k』 

瀏覽器把 k』 傳送給**。 

(以下是關鍵) 

傳送的過程中,再次被攻擊者截獲。 

因為 pk1 pk2 都是攻擊者自己生成的,所以攻擊者自然就可以用 pk1 來解密 k』 得到 k 

然後,攻擊者拿到 k 之後,用之前截獲的 k2 重新加密,得到 k」,並把 k」 傳送給**。

第4步 

**伺服器收到了 k」 之後,用自己儲存的 k1 可以正常解密,所以**方面不會起疑心。 

至此,攻擊者完成了一次漂亮的偷梁換柱,而且讓雙方都沒有起疑心。

所謂的「公鑰」,顧名思義就是可以公開的 key;而所謂的「私鑰」就是私密的 key。 

其實前面已經說過了,這裡再嘮叨一下:

「非對稱加密演算法」從數學上確保了——即使你知道某個公鑰,也很難(不是不可能,是很難)根據此公鑰推導出對應的私鑰。

第2步 

當瀏覽器訪問該**,web 伺服器首先把包含公鑰的證書傳送給瀏覽器。

第3步 

瀏覽器驗證**發過來的證書。如果發現其中有詐,瀏覽器會提示「ca 證書安全警告」。 

由於有了這一步,就大大降低了(注意:是「大大降低」,而不是「徹底消除」)前面提到的「中間人攻擊」的風險。

為啥瀏覽器能發現 ca 證書是否有詐? 

因為正經的 ca 證書,都是來自某個權威的 ca。如果某個 ca 足夠權威,那麼主流的作業系統(或瀏覽器)會內建該 ca 的「根證書」。(比如 windows 中就內建了幾十個權威 ca 的根證書) 

因此,瀏覽器就可以利用系統內建的根證書,來判斷**發過來的 ca 證書是不是某個 ca 頒發的。 

(關於「根證書」和「證書信任鏈」的概念,請參見之前的教程《數字證書及ca的掃盲介紹》)

第4步 

如果**發過來的 ca 證書沒有問題,那麼瀏覽器就從該 ca 證書中提取出「公鑰」。 

然後瀏覽器隨機生成乙個「對稱加密的金鑰」(以下稱為 k)。用 ca 證書的公鑰加密 k,得到密文 k』 

瀏覽器把 k』 傳送給**。

第5步 

**收到瀏覽器發過來的 k』,用伺服器上的私鑰進行解密,得到 k。 

至此,瀏覽器和**都擁有 k,「金鑰交換」大功告成啦。

HTTPS協議 TLS協議 證書認證過程解析

非對稱加解密 非對稱加密包含乙個金鑰對 公鑰和私鑰。公鑰可以公開,私鑰必須安全儲存。https建立連線時時非對稱加密,建立連線後是對稱加密 android官網https詳細 如上圖所示,資料可以被公鑰加密,加密後的資料只有持有私鑰才能進行解密。同理私鑰加密的資料,也只有對應的公鑰才能解密。建立htt...

HTTPS 之 TLS 效能調優

https http over ssl 是以安全為目標的 http 通道,可以理解為 http ssl tls,即在 http 下加入 ssl tls 層作為安全基礎。其中 tls 的前身是 ssl,目前廣泛使用的是 tls 1.2。tls 被普遍認為會使服務變慢,主要是早期 cpu 還很慢,只有少...

https協議 什麼是HTTPS協議?

在我們平常上網的時候我經常接觸的 應該大部分都是 或者我們知道讓他是乙個超文字傳輸協議。那麼https是個什麼?雖然http和這個https兩者只差乙個s,但是本質是大不相同的,他們是兩種不同的網路傳輸協議。千萬不要搞混淆了。http協議通過請求 響應的方式,在客戶端和服務端之間進行通訊。這一切看起...