雙向SSL驗證

我想了解雙向SSL驗證的詳細信息。我想知道的是當一個客戶收到另一個客戶的證書時進行的驗證。（請參閱下面的圖像中的驗證圓）雙向SSL驗證

Two way verification http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/topic/com.ibm.itim.infocenter.doc/images/imx_twowaysslcacert.gif

是否有人擁有所有的步驟清單？有沒有我可以指出的標準文件？每臺服務器是否以不同的方式實施？

主要是什麼我問的是...服務器是否做對其他服務器的主機名驗證VS證書通用名（CN）？

來源

2011-06-16 Ryan H

[RFC 5246]（http://tools.ietf.org/html/rfc5246）是規範，如果你想要協議本身的血統細節。 – Nemo 2011-06-17 01:26:23

@Nemo，鏈接到TLS RFC的好點（關於步驟列表）。我會添加[RFC 5280（PKIX）]（http://tools.ietf.org/html/rfc5280）用於證書驗證（驗證它是可信的）和[RFC 6125]（http://tools.ietf.org/html/rfc6125）用於驗證證書是否與服務器的預期標識匹配。儘管這些RFC在大多數情況下傾向於一起使用，但它們是獨立的，並且根據應用可以有其他驗證模型。 – Bruno 2011-06-17 17:47:36

正如@ user384706所說，它是完全可配置的。

你在談論該方案是其中一臺機器既是服務器和客戶端（並且是客戶端儘可能的SSL/TLS連接而言）。

你不一定通過驗證的連接從所提供的證書的CN（或者主題備用名稱）發起獲得更安全。

有幾個問題：

如果SSL/TLS服務器是指由都是最終用戶和服務器本身客戶端使用，你將有兩個不同的規則具體取決於您對特定證書的期望類型。您可以根據客戶端證書是否具有「服務器」擴展密鑰使用擴展或者僅具有客戶端證書的規則來制定規則，但這會變得有點複雜（爲什麼不）。
客戶端（也是服務器）可能會通過代理服務器，具體取決於它所在的網絡，在這種情況下，源IP地址將與您所期望的不匹配。
通常情況下，客戶端證書身份驗證依賴於一個事實，即假定私鑰保存保護。如果私鑰被服務器上的攻擊者破解，則攻擊者在進行連接時（或直接與受感染的服務器建立連接）也可能具有欺騙源IP地址的能力。這就是說，服務器傾向於擁有不受密碼保護的私鑰，所以如果它被分散地複製，它可能會有所幫助。

我覺得有些工具是如此嚴格，他們不僅驗證CN是傳入連接的FQDN：他們也確認它是源IP地址反向DNS條目。這在實踐中會導致很多問題，因爲某些服務器可能在DNS中有多個CNAME條目，在這種情況下，CN將是合法的，但不一定是該IP地址的主要FQDN。

這一切都取決於系統的總體協議和一般體系結構。

RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS))最近發佈，認爲這種情況超出了範圍。

我能想到的最接近的參考是SIP。

來源

2011-06-16 22:30:09 Bruno

主要是什麼我問的是...請問服務器也針對其他服務器的主機名VS的證書通用名（CN）驗證？

這是可配置的。
它可以配置嚴格檢查和不接受發送證書的CN並不儘管該證書被認爲是可信的匹配FQDN實體連接（例如，通過信任的CA簽名）。
可以放鬆一下，不要做這個檢查並接受證書或委託決定給用戶。例如。 IE顯示彈出警告，指出證書名稱與FQDN不匹配。你想繼續嗎？
從安全的角度來看，最安全的是做嚴格的驗證

來源

2011-06-16 21:24:35 Cratylus

回答

相關問題