所有SSL專家的問題:通過比較證書指紋進行SSL身份驗證?
我們有一個嵌入式設備,它上面有一個小型的Web服務器,我們可以在其上安裝我們自己的SSL自簽名證書。客戶端是用.NET編寫的(但這並不重要)。
如何在.NET中驗證設備?是否足夠比較指紋的證書與數據庫中的已知條目?
我的理解是指紋是整個證書的散列,包括公鑰。僞裝成我的設備的設備當然可以發送相同的公共證書,但它不知道私鑰,對嗎?
或者我是否必須建立自己的信任鏈,創建自己的CA根證書,簽署Web服務器證書並將其安裝在客戶端上?
所有SSL專家的問題:通過比較證書指紋進行SSL身份驗證?
我們有一個嵌入式設備,它上面有一個小型的Web服務器,我們可以在其上安裝我們自己的SSL自簽名證書。客戶端是用.NET編寫的(但這並不重要)。
如何在.NET中驗證設備?是否足夠比較指紋的證書與數據庫中的已知條目?
我的理解是指紋是整個證書的散列,包括公鑰。僞裝成我的設備的設備當然可以發送相同的公共證書,但它不知道私鑰,對嗎?
或者我是否必須建立自己的信任鏈,創建自己的CA根證書,簽署Web服務器證書並將其安裝在客戶端上?
你的建議原則上沒問題。例如在key signing parties期間使用。在這裏參與者通常只是交換他們的公鑰的名字和指紋,並確保參加聚會的人確實是他/她所聲稱的人。驗證指紋比驗證長公鑰要容易得多。
另一個例子是所謂的self certifying file system。這裏再次只有公鑰的哈希通過安全通道進行交換。 (即,這些散列嵌入在URL中)。在這種方案中,公鑰不必安全地發送。接收者只需檢查公鑰的哈希值是否與嵌入在URL中的哈希匹配。當然,接收器還必須確保這些URL來自可信來源。
這個方案和你的建議比使用CA更簡單。但有一個缺點。你必須確保你的數據庫使用散列是真實的。如果你的數據庫很大,那麼這將很困難。如果您使用CA,那麼您只需確保根密鑰是真實的。這通常顯着簡化了密鑰管理,當然也是一個原因,爲什麼基於CA的方案比例如上面提到的自我認證文件系統。
以同樣的方式,您不應該也不應該認爲兩個對象因爲它們的哈希碼匹配而相等,您不應該認爲證書是真實的,僅僅因爲它的指紋出現在「已知證書指紋「。
碰撞是一種散列算法,即使是好的算法也是生活中的一個現實,你應該防範動機的攻擊者可能用匹配的指紋哈希製作一個流氓證書的可能性。防止出現這種情況的唯一方法是檢查證書本身的有效性,即檢查信任鏈,就像您在上次聲明中所暗示的那樣。
簡稱:
那麼在理論上你那麼做的正是一個證書頒發機構爲你做。所以它應該沒問題。
長:
當證書頒發機構簽署您的公鑰/證書/證書請求時,它不簽字整個證書數據。但只是整個證書數據的計算哈希值。 這使簽名保持較小。
如果您不想建立自己的CA或使用商業/免費的 - 通過比較指紋和您信任的指紋,您將獲得第二個最值得信賴的配置。最值得信賴的解決方案是通過比較整個證書,因爲它還可以保護您免受散列衝突攻擊。
至於其他人說在這裏你應該確保使用安全/安全散列算法。 SHA-1不再安全。
更詳細的信息到這個話題:
咦?加密散列函數(如SHA1)的設計使得找到兩個散列到相同輸出的輸入是不可行的。因此,如果他們的散列匹配,那麼假設輸入相等是安全的。因此,假設有動機的攻擊者不能製作具有匹配散列的兩個證書(至少只要散列未被破壞)也是安全的。 此外,僅僅檢查自簽名證書的簽名是不夠的。您需要能夠信任簽名密鑰。 – Accipitridae 2009-07-09 06:35:40
碰撞*是散列算法的一個生活事實。儘管這些算法中的一些已經以最好的意圖進行設計,但MD5已經被廢,了,並且SHA-1也被證明也有弱點。 請參閱http://www.crn.com/security/212700354和http://www.rsa.com/rsalabs/node.asp?id=2834。我認爲最好徹底檢查一下證書,而不要僅僅依靠指紋。 – 2009-07-09 11:38:40