如何在Ruby的SSLServer中實現SSL證書的自定義驗證？

Question

我正在使用SSL在兩個對等方之間形成可信連接。每個同行都知道在給定時間期望與誰連接（或接受連接）。它只應該接受有效的證書，並且應該只接受具有某些屬性的證書（可能通過檢查規範名稱）。

到目前爲止，我可以讓雙方談論，根據the example in this question, and its answer。每一方都可以打印出另一方提供的證書。

雖然我不確定驗證這些證書的正確方法是什麼。顯而易見的方法是在連接建立後查看證書，如果連接不符合我們的期望，則放棄連接。

有沒有更正確的方法來做到這一點？是否有一個回電給予同行的提交證書，並可以給它一個大拇指或拇指向下？或者在SSL完成其工作後處理它是否正確？

Answer 1

在這種情況下，我是CA，所以相信CA並不是問題。我是 代表我的用戶簽署這些證書。規範名稱 甚至不是域名。用戶連接點對點。我希望我分發的 客戶端軟件能夠驗證連接用戶是否有我簽名的 證書，並且是合適的用戶。

它聽起來像你正在運行一個私人PKI。只需使用SSL_CTX_load_verify_locations或SSL_load_verify_locations將信任鏈的根加載到OpenSSL中即可。請確保使用SSL_PEER_VERIFY確保OpenSSL執行驗證。該電話可能看起來像SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);。如果同行驗證失敗，則connect將失敗。

有幾種方法可以確保connect成功，然後再捕獲錯誤。訣竅是設置驗證回調，使驗證回調總是返回1，然後在連接建立之後調用SSL_get_verify_result。以SSL/TLS Client爲例。

注意：在所有情況下，您仍然必須手動執行名稱檢查。 OpenSSL目前沒有這樣做（它在OpenSSL 1.1.0的HEAD中）。請參閱libcurl或PostgreSQL，瞭解可以翻錄的一些代碼。

SSL/TLS客戶端的一個例子是由OpenSSL在其wiki上提供的。見SSL/TLS Client。目前沒有服務器代碼或示例。

Answer 2

雖然我不確定驗證這些證書的正確方法是什麼。 明顯的方法是在 連接完成後查看證書，如果連接不符合我們的 期望，則刪除連接。

這裏有很多，其中一些並不明顯。我將把答案分解成幾部分，但所有部分都試圖回答你的問題。

---

首先，您可以驗證證書是否格式正確。在Web上下文中負責的組是CA /瀏覽器論壇。他們對於創建證書基線和擴展的要求：

• 基線的證書要求，https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf
• 擴展驗證證書要求，https://www.cabforum.org/Guidelines_v1_4_3.pdf

在基準文檔，你會發現，例如，IP列爲通用名稱（CN）的名稱也必須在主題備用名稱（SAN）中列出。在擴展文檔中，您會發現專用IP（根據RFC 1918保留）不能出現在擴展驗證（EV）證書中;而EV證書不能包含通配符。

---

其次，你可以根據RFC 5280進行確認的習慣，互聯網X.509公鑰基礎設施證書和證書撤銷列表（CRL）檔案，http://www.ietf.org/rfc/rfc5280.txt。

習慣性檢查是類似於主機名匹配，時間段有效性檢查以及驗證最終實體或葉證書（客戶端或服務器證書）鏈回到根的類型。在使用CA的瀏覽器中，這是任意數量的數百個受信任的根或中間體。

如果你選擇執行撤銷檢查，那麼你可能會拒絕你的應用程序（這是明顯的！）。 3G網絡上的移動客戶端無法下載和處理30MB CRL - 它肯定會掛起應用程序。當URL錯誤時，應用程序無法執行OCSP查詢 - 這肯定會失敗。

另外，如果您正在執行包含通配符的主機名匹配，那麼必須注意正確處理ccTLD。 ccTLD就像* .eu，* .us或者（nic.lk）。大約有5000個左右，Mozilla提供了一個列表http://publicsuffix.org/（或者，https://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1）。

---

第三，CA不保證任何東西，所以您從CA獲得的答案是毫無價值的。如果您不相信我，請查看他們的「認證實踐聲明」（CPS）。例如，下面是來自蘋果Certification Authority Certification Practice Statement的摘錄（2013年9月18日，第6頁）：

2.4.1. Warranties to Subscribers 
The AAI Sub-CA does not warrant the use of any Certificate to any Subscriber. 

2.4.2. CA disclaimers of warranties 
To the extent permitted by applicable law, Subscriber agreements, if applicable, 
disclaim warranties from Apple, including any warranty of merchantability or 
fitness for a particular purpose 

這意味着它們不會通過發行人的簽名保證公鑰組織的結合。這就是X509的全部目的！

---

四，DNS不提供真實答案。所以你可能會從DNS得到一個不好的答案，並且愉快地走向由你的對手控制的服務器。或者，美國控制下的13臺根DNS服務器中的10臺可能會以美國國家安全的名義勾結，給您一個錯誤的答案。

試圖從非美國服務器獲得真實響應幾乎是不可能的。 「安全的DNS」部分（無DNSSEC）仍在不斷髮展，我不知道任何主流實施。

在共謀美國服務器的情況下，法定人數將不起作用，因爲美國佔絕大多數。

---

這裏的問題是您正在根據外部服務（CA和DNS）的輸入做出安全決定。從本質上講，你所賦予的也必須相信不可靠的演員。

對PKI和PKIX問題的一個很好的解決方法是Peter Gutmann博士的工程安全，網址是www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf。請務必閱讀第1章和第6章。Gutmann博士具有幽默感，所以它不是乾燥的閱讀。另一本很棒的書是羅斯安德森的安全工程在http://www.cl.cam.ac.uk/~rja14/book.html。

---

您有幾個防禦措施，包括由PKI，PKIX和CA引起的所有問題。首先，您可以在您自己的證書頒發機構中運行私有PKI。在這種情況下，你不相信局外人。錯誤的DNS答案和流氓服務器應該被捕獲，因爲服務器的證書不會形成有效的鏈。

其次，您可以採用安全多元化戰略。葛特曼寫到在他工程安全本書，你應該訪問「安全通過多樣性」啓動292頁和「風險多樣化的互聯網應用程序」部分頁面296

三，你可以採用信託「首先使用」（TOFU）或「關鍵連續性」策略。這與Wendlandt，Anderson和Perrig的相似觀點：通過多路徑探測改進SSH式主機身份驗證或SSH的StrictHostKeyChecking選項。在這種策略中，您會進行習慣性檢查，然後插入證書或公鑰。您也可以要求其他人查看證書或公鑰。意外的證書或密鑰更改應引發警鐘。

OWASP對https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning的證書和公鑰處理有處理。注意：有些地方每隔30天左右輪換證書，因此如果可能的話，您應該使用公鑰。頻繁輪轉列表包括谷歌，其證明工具如證書巡邏的原因之一造成如此之大的噪音。