問題的快速版

Gmail，TD（加拿大銀行），皇家銀行（加拿大銀行）都使用ssl。當你檢查他們的證件他們都有使用證書進行SSL身份驗證：證書是否應具有主機名？

Common Name (CN) mail.google.com

或者更一般地說：

Common Name (CN) <url>

難道這需要防止中間人攻擊？

摘要

JBoss允許客戶端和服務器使用證書和ssl進行身份驗證。有一件看起來很奇怪的事情是，你不需要在證書上給你的主機名。

我認爲這意味着如果服務器B在您的信任庫中，Sever B可以僞裝成他們想要的任何服務器。

（以及類似：如果客戶B在您的信任...）

我失去了一些東西在這裏？

認證步驟

（Summary of Wikipeida Page）

Client             Server 
================================================================================================= 
1) Client sends Client Hello 
     ENCRIPTION: None 
     - highest TLS protocol supported 
     - random number 
     - list of cipher suites 
     - compression methods 

                 2) Sever Hello 
                   ENCRIPTION: None 
                   - highest TLS protocol supported 
                   - random number 
                   - choosen cipher suite 
                   - choosen compression method 

                 3) Certificate Message 
                   ENCRIPTION: None 
                   - 

                 4) ServerHelloDone 
                   ENCRIPTION: None 

5) Certificate Message 
     ENCRIPTION: None 

6) ClientKeyExchange Message 
     ENCRIPTION: server's public key => only server can read 
       => if sever can read this he must own the certificate 
     - may contain a PreMasterSecerate, public key or nothing (depends on cipher) 

7) CertificateVerify Message 
     ENCRIPTION: clients private key 
     - purpose is to prove to the server that client owns the cert 


         8) BOTH CLIENT AND SERVER: 
           - use random numbers and PreMasterSecret to compute a common secerate 


9) Finished message 
     - contains a has and MAC over previous handshakes 
       (to ensure that those unincripted messages did not get broken) 


                 10) Finished message 
                   - samething

Sever的誰知

客戶端具有發送證書的公鑰（步驟7）
客戶端的證書是有效的，因爲：
- 已經由CA（威瑞信）簽署
- 它已經自簽名，但它是在服務器的信任
它不是一個重放攻擊，因爲大概是隨機數（步驟1或2）與每個消息一起發送

客戶端知道

服務器爲發送證書（步驟6步驟8）公鑰
服務器的證書是有效因爲無論：
- 已經由CA（Verisign所簽發）
- 已自簽名，但它是在客戶端的信任
它不是一個重放攻擊，因爲presu馬布利的隨機數（步驟1或2）與每個消息

潛在問題

發送假設客戶機的truststore中有證書：
- 服務器A
- 服務器B（惡蘋果）
服務器A主機名www.A.com
服務器B主機www.B.com
假設：客戶端試圖連接到服務器A，但服務器B在中間推出一個男人攻擊。
由於服務器B：
- 具有將被髮送到客戶端證書的公鑰
- 有一個「有效證書」（在信任一個證書）
由於：
- 證書中沒有主機名字樣

看起來服務器B可以很容易地假裝爲服務器A.

有什麼，我失蹤？

來源

2010-04-08 sixtyfootersdude

這看起來不像一個編程問題。投票轉移到服務器故障。 – 2010-04-08 19:04:40

我認爲這是與算法有關...？ – sixtyfootersdude 2010-04-08 19:28:09

@david，是的這是一個編程問題。 ServerFault上的人員不完全理解安全因爲他們不是程序員。 – rook 2010-04-08 19:29:47

你能指出一些文字說JBoss在證書中不需要主機名，還是僅僅是你的觀察？我認爲'主機名'是指通用名稱（CN）或可分辨名稱（DN）？

通常應用程序應該檢查的X.509證書：

有效的日期範圍
用法（例如，服務器授權）
鏈接到受信任根
CN ==目標的DNS名稱主機（它可能是另一個名字，而不僅僅是DNS）
沒有被撤銷（使用CRL或OCSP）

從技術上講，一個應用程序可以選擇忽略任何這些，只是表示ŧ帽子一切都很好與證書....但這是不好的:)

來源

2010-04-09 02:23:58

嗨邁克爾，我按照這個教程：http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/Server_Configuration_Guide/html/Using_JBoss_Login_Modules-BaseCertLoginModule.html。它沒有明確說明主機名不需要在生成的證書中，但是它也沒有聲明。我現在有「認證和加密」的東西，但我只是意識到它沒有服務器的主機名。這會成爲一個安全漏洞嗎？有什麼方法可以強制它檢查主機名。這是必要的嗎？ – sixtyfootersdude 2010-04-12 13:47:16

嘿，如果你沒有檢查'另一端'的名字，那麼你會受到中間人攻擊。如果您查看鏈接的文檔，您會看到他們在證書中有名稱，這是CN =和OU =引用。 – 2010-04-12 22:47:43

CN == DNS檢查不是SSL/TLS的嚴格組成部分。相反，它是是否信任某個站點的特定證書的政策的一部分。在某些情況下，這是一件完全合理的事情（但您擔心某個CA默認信任的某個地方是否會欺騙爲服務器簽名虛假證書），而在其他情況下則不然（特別是當您只信任單個，限制性CA;對於客戶端不是標準瀏覽器的Intranet應用來說，這是一種可行的方法）。 – 2010-04-13 13:50:55

我想你錯過了一些東西，但我不知道如果我理解你的推理。

但是，當服務器B試圖在中間攻擊中啓動一個人時，您說它有一個公鑰。這是真的，但要建立一個ssl連接，你還應該有一個屬於該公鑰的私鑰。此外，所使用的證書與DNS名稱（在https的情況下）相結合。因此，一個客戶端嘗試連接到A，他在www.a.com中鍵入。既然我們假設B不知道A的私鑰，他將擁有另一個密鑰對。他永遠不會收到來自主要CA的有效（即可信）證書，該證書與他不屬於的域相關聯。

因此，B永遠不會得到一個通用名稱的證書www.A.com，因此，B不能在中間人攻擊中執行一個人。

來源

2010-04-13 13:38:17 Henri

使用證書進行SSL身份驗證：證書是否應具有主機名？

問題的快速版

摘要

認證步驟

Sever的誰知

客戶端知道

潛在問題

回答

相關問題