2011-11-18 66 views
2

我一直在閱讀互聯網上關於SSL如何工作的幾個網站,但我不明白它如何確保安全。可能因爲我不完全理解它是如何工作的。什麼使SSL安全?

讓我從SSL的核心思想開始。它用於加密HTTP連接,但爲了客戶端和服務器與加密數據進行通信,當然需要共享加密密鑰。如果有人竊聽你的連接,他們是不是可以抓住這個密鑰並在解密數據的同時繼續收聽?如果我們談論的是長期連接,我可以想象這種技術會起作用,但HTTP請求通常在半秒內完成。

讓我們假設這是以某種方式照顧。 SSL的另一個用途是驗證服務器是否與其說的完全一樣。什麼能夠防止惡意服務器僞造由根證書提供者簽名的證書?在我讀過的所有描述中,瀏覽器實際上都聯繫了其中一個權威機構來與他們覈實證書。假設證書由根證書頒發機構用私鑰加密,瀏覽器如何在不知道解密密鑰的情況下驗證此證書中的數據?或者解密密鑰與加密密鑰不同?

這些問題的一個解決方案我可以想象的是,如果證書和密鑰只發送一次,並與您的瀏覽器中的域名和IP地址一起存儲。

感謝您提前解釋。

+3

這是一個有趣的領域。這篇維基百科文章應該爲您提供一個很好的起點:http://en.wikipedia.org/wiki/Public-key_cryptography – Russell

回答

9

首先,關於公共密鑰加密技術的一些基本概念:

  • 這依賴於一對密鑰。一個是公鑰(可以分發);另一個是私鑰,旨在保密。
  • 你可以用加密數據使用公鑰,私鑰可以解密/解密
  • 您可以使用私鑰簽署數據,並且此簽名可以使用公鑰驗證驗證

要確保您與正確的實體進行通信,您需要將身份綁定到密鑰對。這是證書進入的地方。公鑰證書是包含主題身份(名稱)和主題公鑰的簽名文檔。 例如,www.google.com的證書包含其公鑰和名稱www.google.com。它已經使用認證中心的私鑰(在這種情況下是Thawte)進行簽名。在X.509術語(用於HTTPS的證書的通用標準)中,CA是證書的頒發者,並且在名稱,主體的公鑰(以及其他屬性)旁邊也將其名稱放入證書中。發行人是爲了驗證他們簽發證書的身份。

您不一定會看到您的瀏覽器從CA獲取信息的原因是許多商業(或政府)CA證書與您的瀏覽器或操作系統捆綁在一起。您默認信任它們。這可以被認爲是「信仰的飛躍」,但任何信任機制都需要這種起點。

您可能需要閱讀更多有關TLS handshake,但在短:

  • 客戶端通過查看其證書獲取服務器的公鑰。
  • 客戶端使用該公鑰對祕密進行加密並將其發送到服務器。這個細節取決於密碼套件(可能基於Diffie-Hellman),但是這個結果應該是共享加密密鑰的列表(使用對稱加密而不是公鑰加密)。
  • 這些共享密鑰只有客戶端和服務器已知,並且它們用於加密/解密。

對於SSL/TLS是安全的,你至少需要3點:

  • 合適的加密套件,以及一個成功的握手。
  • 驗證客戶端是否信任服務器證書(通常是通過PKI model中的已知CA)。
  • 驗證證書是否屬於客戶端打算聯繫的服務器(hostname verification)。

(這是對於絕大多數SSL/TLS的用法的情況下(特別是HTTPS),但它也可以使用比用TLS X.509證書的其他機制,例如OpenPGP的證書或Kerberos加密這是不太常見的,據我所知)

+0

非常好的回答,有一個很好的從上到下的描述,瞭解SSL如何在加密方面的適當級別的細節上工作。 –

2

爲了加密連接,你必須同意一些共享的祕密。這可以通過diffie-hellman完成。爲了防止中間人攻擊,所以你還需要一個證書機制。

對於加密或簽名(證書),您可以使用異步密鑰。這意味着你有兩個不同的密鑰(公鑰和私鑰)進行加密/解密。通常你用公鑰加密你的數據,並且有人可以用他的私鑰解密。簽名使用您的私鑰完成,其他人可以使用公鑰檢查。

所以你看,僞造證書並不容易,因爲你沒有根證書提供者的私鑰。

+1

中間人*攻擊的漏洞並不是Diffie-Hellman的特定缺陷。當找到共享密鑰而沒有雙方現有的信息時,這是一個普遍的問題。 –

+0

@halo:你說的沒錯。 – duedl0r

0

當使用諸如Diffie-Hellman key exchange這樣的協議時,通信雙方都生成一個隨機數,以某種方式轉換它,並將轉換後的版本發送給另一方派對。這種轉換是這樣的,即第一個數字與第二個數字的轉換版本的結合將產生與第二個數字與第一個數字的轉換版本相同的結果。然而,只有變換數字的對手無法找到任何一個變換的版本,也沒有辦法計算將一個數字的(不可用的)未變換版本與(可用)另一個的轉換版本。

Diffie-Hellman密鑰交換本身足以防止所有形式的被動攻擊或歷史攻擊(也就是說,如果攻擊者沒有采取措施在發生通信之前攔截通信,它不會在晚些時候被攻破,除非通過執行一些計算,在任何類似於當今技術的情況下,都不能在任何可行的時間內進行計算)。其問題在於它不能很好地防止攻擊者(例如Z)可以攔截參與者之間的所有通信(例如X和Y)並替換他自己的情況。在那種情況下,X會和Z建立聯繫 - 把他想到Y--除了他和Z都可以解碼的人。然後,Z會 - 假裝成X - 與Y建立聯繫。

如果X和Y具有彼此共享信息的任何預先存在的手段,使得它們可以比Z快得多地解碼信息,即使它不是非常安全的,這可能足以防止上述中間人攻擊。所有需要發生的事情是讓X和Y相互問問他們正在使用的密鑰。如果Z能夠認識到這個問題並用自己的答案替代,那麼它就能夠繼續下去。另一方面,如果以這樣一種方式詢問問題,即合法方能夠比冒名頂替者做出更快的反應,Z可能會被扼殺。例如,如果爲每個參與者顯示了有關協商密鑰的語音電話應用程序,並且一方要求另一方「讀取您的密鑰的數字12至18,爲Elmer Fudd留下最好的印象」(選擇現場,要讀取的數字以及要使用的語音),合法的參與者將能夠立即作出反應,但攻擊者需要時間對指示的人進行虛假記錄)。

1

確實需要共享加密密鑰。如果有人竊聽你的連接,他們是不是隻能抓住這個密鑰

不可以。密鑰永遠不會傳輸。它在兩端通過密鑰協議算法獨立計算。

防止惡意服務器僞造由根證書提供程序簽名的證書的原因是什麼?

證書與私鑰一起發送的數字簽名一起發送,並由對端通過證書自己的公鑰驗證。服務器需要它僞裝的服務器的私鑰。

+0

你可以擴展密鑰協議算法嗎? – 5arx