2010-11-30 55 views
1

到目前爲止,我還沒有真正研究安全通信,我有一些基本問題。假設有一個瀏覽器(客戶端)和一個服務器。據我所知,服務器既有公鑰也有私鑰。公鑰由每個人都知道,而私鑰只能由服務器識別。因此,當客戶端向服務器發送消息時,它會使用服務器的公鑰進行加密,並且只有服務器才能解密(導致只有服務器擁有私鑰)。安全通信基礎知識

現在我的問題:當服務器想要發送消息到客戶端會發生什麼?服務器使用其私鑰對消息進行加密,客戶端使用公鑰對其進行解密(它是衆所周知的)。到現在爲止還挺好。但是如果有人嗅探流量,他也可以解密該消息,讓每個人都知道公鑰。它如何安全?我相信,我不明白真正的基礎在這裏:(

感謝的東西提前

最好的問候, 斯托

+0

這是如何離題? – 2010-11-30 13:22:52

+0

這是一個編程問答網站,而不是協議問答網站。有些人會考慮你的問題脫離主題,其他人不會。 – 2010-11-30 21:41:43

+0

我會鼓勵閱讀[RFC 2246(TLS 1.0)](http://www.rfc-editor.org/rfc/rfc2246.txt)。爲了簡化目的,您可以忽略不適用於RSA或DHE_RSA密碼套件的所有內容。首先閱讀第7.3節,並在閱讀其餘部分時閱讀第一張標有圖1的圖。 – 2010-11-30 21:48:42

回答

3

安全通信不僅涉及加密(這實際上是簡單的部分),而且更重要的是認證。

可以在兩方之間建立加密通信而無需事先交換任何密鑰(例如,參見Diffie–Hellman key exchange)。

困難的部分是確保您與誰交談是值得信賴的。這是公鑰和私鑰進來

所以工作流去有點像這樣:

  1. 一個連接客戶機和服務器之間進行。
  2. 客戶端已經知道服務器的公鑰(不對稱密碼術),因此它可以證明另一端點是他們自稱的對象:公鑰用於解密一個令牌,該令牌在驗證時表明它確實用服務器的私鑰加密。
  3. 鑑定完成後,雙方使用上面的Diffie-Hellman等方法建立shared secret
  4. 此共享密鑰用作客戶端/服務器會話剩餘部分的所有數據交換的加密/解密密鑰(對稱密碼術)。
  5. 當連接關閉時,上面的加密密鑰被丟棄。如果建立了新連接,則上述算法將爲該新會話生成一個新的加密密鑰。
5

簡化了很多:客戶端生成對稱加密密鑰並把它發送使用服務器的公鑰對其進行加密 以這種方式進行安全密鑰交換 從客戶端和服務器使用對稱加密和交換的密鑰 標準方式是Diffie-Helman key exchange這是一個小的比給出的例子更復雜