HTTPS是否實現了Diffie Hellman秘鑰互動演算法來防重放攻擊?

時間 2021-05-29 22:39:46

1樓:

呃,不知道該怎麼回答。。。實話說,問題的描述裡有太多錯誤。

首先,HTTPS是HTTP over TLS,通訊的安全是TLS來保證的;

其次,TLS是通過完整的協議實現來保證通訊安全的,不能簡單概括為RSA+AES加密。從原理上說,加密演算法的使用分兩部分:通過非對稱密碼演算法(RSA)協商/交換金鑰,然後將金鑰用於對稱密碼演算法(AES)以實現傳輸中的資料加密。

同時,還有身份認證、訊息完整性校驗、訊息摘要等等。具體到TLS,還有會話(session)和連線(connection)的區別。幾句話說不完,要真正了解,最好的辦法還是去看RFC。

問題中提到的其他幾點,也隨便說說:

a. 「AES金鑰是瀏覽器端隨機生成的」。這句話本身沒錯,隨機生成的目的是為了保證資料傳輸的安全性,和防重放攻擊沒有關係。

重放攻擊針對的是TLS報文(record),應對的方式是視窗期和時間戳;防止密碼重用的是完美前向保密(Perfect Forward Secrecy,PFS)機制。

b. Diffie-Hellman演算法。DH演算法用於金鑰交換,並不用於防重放攻擊,在TLS中是PFS的基礎。

2樓:Rix Tox

首先重放攻擊有兩個攻擊點:

第一種是當中間人截獲到 TLS 會話過程中的乙份訊息時,重放這條單一的訊息。

TLS 通過給每個訊息計算乙個 MAC(資訊驗證碼)來防止這個層面的重放攻擊。MAC 的計算用到乙個 Sequence Number 是每條訊息遞增的,如果攻擊者重放一條訊息,那同乙個 Sequence Number 會被重複使用,接收方會拒絕處理。

第二種是當中間人接獲到整個 TLS 會話,從握手階段就開始重放。這樣的話 Sequence Number 會被重置,無法防禦這種攻擊。因此必須防止握手階段的重放攻擊。

這個即使用 RSA Key Exchange 也是可以防止的,在握手階段服務端會生成乙個隨機數,客戶端的簽名要包含這個隨機數才行,因此每乙個握手會話都是被繫結到了當前的這個會話的。如果攻擊者要重放,他會面臨乙個新的服務端生成的隨機數,除非他撞大運遇到了相同的值,否則他截獲的握手會話是無效的。

用 Diffie-Hellman 的話能進一步提公升握手會話的隨機性,因為不單是服務端要生成隨機數,客戶端也要生成隨機數,攻擊者更加難實施重放攻擊。

總的來說 Diffie-Hellman 不是為了解決重放攻擊才用的,而是任何 Key Exchange 協議都必須要能防禦重放攻擊才行。

3樓:李欣宜

HTTPS依賴的TLS/SSL協議確實用到了部分實現DH交換的,不過用的不是static DH,而是Diffie-Hellman Ephemeral(DHE)生成臨時的共享秘鑰(TLS1.2的相關標準可以見https://

tools.ietf.org/html/rfc

5246#section-7.4.3

),伺服器端並不長期持有某個public key,每次握手會生成新的,同樣也不會長期保留或者記錄任何private key,DHE確實起到一定的anti-replay attack的效果,不過TLS/SSL在這方面還是主要靠random nonce……

除了DHE以外還有一些其他的DH變體也被應用到了TLS/SSL協議,我不怎麼了解它們分別怎麼用,如果你對它的應用方法感興趣可以參考

4樓:

HTTPS用到的 - SSL協議,並沒有使用Diffie-Hellman進行金鑰交換。

如果你說的重放攻擊指的是攻擊者重放金鑰交換的請求,來獲取金鑰,那麼SSL是足夠防禦重放攻擊的。

SSL交換金鑰 --其實並沒有真正的交換了金鑰,而是雙方分別生成了一樣的金鑰。建立連線的過程中,會有幾個階段:

1. Client傳送乙個明文的隨機數random1到Server

2. Server傳送乙個明文的隨機數random2到Client

3. Client用Server的公鑰加密乙個隨機數pre_master,發給Server

此時,雙方同時使用random1,random2和pre_master三個隨機數,來生成乙個金鑰。

此處可見,攻擊者是可以擷取到明文的random 1和random 2,但沒有私鑰無法解密pre_master 裡的第三個隨機數,因此無法生成金鑰。這是SSL協議安全的關鍵。

那如何防止重放?靠隨機數的隨機性。

server和client發出的random1和random2,在每時每刻都會變化。攻擊者即使重放了,server返回了不一樣的random2,沒有pre_master的隨機數,他一樣無法偽造生成通訊過程中的金鑰。

這裡RSA用於SSL協議中加密pre_master,而對稱演算法則是在生成了金鑰後,用於加密後續的通訊。

不用 https 自己實現對 http請求的內容的 rsa 加密,這樣足夠安全嗎?

王絮飛 題主想自己實現乙個HTTPS,然後有人回答能實現,再然後有的答主說回答能實現的是資訊保安沒學好的,嗯,搞HTTPS的人是資訊保安沒學好的。 B乎一下 不能第一要想獲得Https的方便性你還是要在web伺服器端和瀏覽器端實現你說的這個協議一般很難辦到如果不這樣那麼金鑰怎麼儲存?第二 Https...

https到底把什麼加密了

立馬吳山 ssl是傳輸層協議,它並不曉得應用層的東西,什麼url,header,body.反正把整個資料報都加密就完事了。 loco HTTPS是在建立完加密通道後,將整個請求報文 包 通過加密通道進行傳輸的,抓包 攻擊 者在沒有解密用的金鑰的情況下,在建立完加密通道後看不到除了伺服器IP位址以外的...

HTTPS 下 Web 前端密碼非對稱加密是否有意義?

最近被這個問題折騰了好久。我來說說我的看法吧。首先,前端非對稱加密幹的人不多。而且就算幹了的站點比如google我都不知道他的加密演算法是什麼。然後,這個事情是有意義的,因為這樣可以證明服務端絕對不會拿到你的真實密碼,給客戶安全感。最後,我也不知道我該用單次的sha256 鹽還是PBKDF2 sha...