中間情景中的組織內部人
問題。我是一名軟體開發人員。我為我的客戶設計和編寫安全系統。我的客戶最近向下指示所有進出我的伺服器的流量都通過一個新設備路由。我不知道設備是什麼。我被告知的是它會影響路由和客戶端證書。我得到了一個可以一起工作的人的名字，然後我們就走了。我們使用客戶端證書進行身份驗證，所有進出伺服器的流量都是加密的。這就是事情變得奇怪的地方。以前，我的伺服器有它自己的 SSL 證書頒發給它的目前主機名。現在，當我訪問該站點時，我會看到該站點 SSL 證書的新設備的主機名，而不是我的伺服器的主機名。還。當客戶端證書到達我的伺服器時，它不再是由我知道的原始發行人發行的。但握手期間沒有協商錯誤。瀏覽器中的一切都是綠色的。
唯一有意義的是，該設備在來自客戶端的流量到達我的伺服器之前對其進行解密，以便在重新加密並將其發送到我的伺服器之前對其進行記錄和檢查。然後，當它從伺服器獲得回复時，它同樣會解密、記錄、檢查數據，然後重新加密並轉發數據。
我對非對稱和對稱密碼學的理解在這裡正確地為我服務嗎？大多數情況下，我堅持我的應用程序的邏輯，並且對密碼學有足夠的了解，能夠做我需要做的事情並確保我的系統保持安全。但我並不熟悉它總是如何運作的來龍去脈。似乎我的組織只是在中間設備中安裝了一個內部人員用於監控目的，並沒有告訴我到底發生了什麼。
這合理嗎？
是的，你的理解是正確的。
這是一個支持 TLS（或任何其他安全傳輸協議）的代理。它的作用是動態生成站點證書。您通過代理與您的客戶端連接到一個站點，它執行一個中間人，因為 TLS 連接是在其他任何事情之前設置的。
首先它將與遠端站點連接，並使用普通伺服器證書創建與它的連接。希望它完全驗證並驗證該電腦的證書。這樣就處理了與遠端伺服器的連接。
現在要欺騙您的連接，代理必須具有特定主機名的證書（作為證書中的公用名）。它可能首先在記憶體中查找證書並將其與私鑰一起使用。如果它找不到證書，它會生成一個密鑰對並為其簽署一個臨時證書。然後它與您的客戶端建立連接。
一旦它同時執行了兩個 TLS 會話，它就可以充當普通代理。現在它可以（深入）檢查通過連接在任一方向發送的任何數據。
或者，它可以向客戶端發送重定向，以便連接到不同的主機名。這樣它就可以使用一個單一的、長期的伺服器/設備證書。當然，您的客戶必須接受此重定向才能使該方案起作用。
當然這並不容易，因為隨機證書會被您的客戶拒絕 - 沒有證書鏈到受信任的證書。基本上，這可以通過在您的信任庫中註入受信任的 CA 證書來解決。這可以是 Windows 信任庫，也可以是您正在使用的客戶端應用程序的信任庫（例如 firefox 瀏覽器）。通常，證書只是使用 Windows 組策略以及一些用於最常見瀏覽器的腳本來推送。
代理現在將充當它自己的證書頒發機構，使用它自己的 CA 證書籤署它使用私鑰生成的任何證書。一旦證書鏈被信任，您的客戶端就會亮起“綠色”，因為它看不到與任何其他鏈的區別。
或者，代理可以使用損壞的（或以其他方式控制的）CA，就像伊朗在為 Google 請求證書時對 DigiNotar CA 所做的那樣。
當然，即使是深度數據包檢測也無法檢測到所有可能的隱蔽通道，因此我將由您自行破解系統（可能會產生影響）。