支援服務中的驗證延伸保護 （EPA）
| 功能 | 適用於 |
|---|---|
| EPA | 所有支援的 Windows OS |
| EPA 稽核模式 | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
發生什麼問題？
對稱為轉送攻擊的已驗證服務有一種攻擊。 這些攻擊可讓敵人略過驗證，並充當另一個使用者。 因為這些是服務的攻擊，而不是驗證通訊協定本身，所以由已驗證的服務來挫敗轉送攻擊。
轉送攻擊如何運作？
當服務或應用程式呼叫 API AcceptSecurityContext 來驗證用戶端時，它會傳遞從用戶端呼叫 InitializeSecurityContext 所收到的數據 Blob。 驗證通訊協議負責驗證提供的 Blob 是否源自指定的使用者。 AcceptSecurityContext 無法判斷其未看到之應用程式訊息其餘部分的真實性。
應用程式中常見的安全性錯誤是在成功驗證內部驗證通訊協定 Blob 之後，將應用程式流量視為已驗證。 這最常發生在使用 TLS 進行有線通訊協定的應用程式。 TLS 通常不會使用用戶端憑證;它提供伺服器的完整性和機密性保證，但不會驗證。 內部驗證會提供客戶端驗證，但僅適用於其 Blob。 它不會驗證 TLS 通道或其中所含應用程式通訊協議的其餘部分。
攻擊者會藉由使用攻擊者製作的要求，從一個來源插入驗證 Blob，以執行轉送攻擊。 例如，攻擊者可以觀察網路上的驗證流量，並將它插入至伺服器自己的要求中。 這可讓攻擊者從擷取的驗證流量，以用戶端身分存取伺服器。
此處的主要概念是 SSPI 驗證訊息的設計目的是要透過網路公開;他們不應該保密。 這與許多使用持有人令牌的 Web 型驗證配置不同，這些令牌一律會在 TLS 通道內保密。
解決方案為何？
慣用的解決方案是使用驗證通訊協定的會話密鑰來簽署或加密 （MakeSignature， EncryptMessage） 其他流量。 由於會話金鑰是在驗證通訊協定交換期間以密碼編譯方式衍生的，因此其已驗證的數據，以及該密鑰所保護的任何流量保證都來自已驗證的用戶端。
這不一定是選項。 在某些情況下，應用程式通訊協定訊息的格式是由專為持有人令牌設計的標準所修正。 在此情況下，也稱為通道系結的「驗證延伸保護」（EPA）可以防範透過 TLS/SSL 通道的轉送。
什麼是 EPA？
EPA 會以密碼編譯方式將 TLS 會話金鑰系結至驗證通訊協定的會話金鑰，讓 TLS 提供與驗證通訊協定金鑰相同的客戶端驗證。 如需詳細資訊，請參閱 驗證擴充保護概觀 。
服務繫結
EPA 的第二個部分稱為服務系結。 不同於通道系結，這不會提供服務的密碼編譯保證，並可作為無法進行通道系結的最後手段的防禦。 此機制可讓伺服器呼叫 QueryContextAttributes 來擷取屬性 SECPKG_ATTR_CLIENT_SPECIFIED_TARGET ，其中包含傳遞至 InitializeSecurityContext 的已驗證客戶端名稱。
例如，假設位於 TLS 終止負載平衡器後方的服務。 它無法存取 TLS 會話密鑰，而且只能從通道系結中判斷客戶端的驗證是針對 TLS 保護的服務。 用戶端提供的名稱應該與用來驗證 TLS 伺服器證書的名稱相同。 藉由驗證用戶端是否向符合負載平衡器伺服器 TLS 憑證的名稱進行驗證，服務會獲得驗證來自與 TLS 通道相同用戶端的高信賴度。
本文不會討論如何支援服務系結。 如需詳細資訊，請參閱 如何：在組態 中指定服務系結。
您如何支援 EPA？
強制執行 EPA 時，服務可能會注意到客戶端因為相容性問題而無法進行驗證。 因此，我們已建立 EPA 稽核模式，讓服務能夠啟用稽核，讓系統管理員控制客戶在強制執行 EPA 之前如何回應。
支援稽核模式 Microsoft 服務 包括：
注意
您可以在下方找到啟用 EPA 稽核功能的選擇性步驟。 請注意，在不強制執行 EPA 的情況下啟用 EPA 稽核功能並不會防止轉送攻擊。 我們建議選擇先在稽核模式中啟用 EPA 的服務，稍後採取步驟來補救不相容的用戶端，並最終嚴格強制執行 EPA 以避免任何潛在的轉送攻擊。
注意
傳遞至 AcceptSecurityContext 的通道系結不需要是僅限稽核的系結，即可取得稽核結果。 服務可以在強制執行 EPA 的同時執行稽核模式。
用戶端
- 使用 QueryContextAttributes（TLS） 來取得通道系結（填入唯一與端點）
- 呼叫 InitializeSecurityContext，並在 SECBUFFER_CHANNEL_BINDINGS中 傳遞通道系結
伺服器
- 使用 QueryContextAttributes（TLS），如同在用戶端上
- （選擇性）僅透過呼叫 SspiSetChannelBindingFlags 進行稽核
- （選擇性）將通道系結結果緩衝區新增至 ASC 的輸出緩衝區。
- 使用 SECBUFFER_CHANNEL_BINDINGS呼叫 AcceptSecurityContext 來指定 EPA 層級和其他設定
- （選擇性）使用旗標來控制角落案例的行為：
- ASC_REQ_ALLOW_MISSING_BINDINGS - 不要讓沒有任何話的客戶端失敗，就像舊的第三方裝置一樣。 未取得 SECBUFFER_CHANNEL_BINDINGS 的覺察型用戶端會傳送空的系結，而不會傳送任何內容。
- ASC_REQ_PROXY_BINDINGS - TLS 終止負載平衡器的罕見案例。 我們沒有要傳遞SECBUFFER_CHANNEL_BINDINGS，但仍想要強制用戶端將要求放入 TLS 通道。 這在服務系結中非常有用，以確保用戶端也會放入伺服器憑證符合我們名稱的 TLS 通道中。
如何強制執行 EPA？
一旦服務支援 EPA，系統管理員可以控制 EPA 狀態，從稽核到完全強制執行。 這可讓服務服務評估其生態系統的環保局整備程度、補救不相容的裝置，並逐步強制執行 EPA 來保護其環境。
下列屬性和值可用來在您的環境中強制執行不同層級的 EPA：
| 名稱 | 描述 |
|---|---|
| None | 未執行通道繫結程序驗證。 此乃所有未更新之伺服器的行為。 |
| 允許 | 所有已更新的用戶端都必須向伺服器提供通道繫結資訊。 尚未更新的用戶端則沒有這個必要。 此乃顧及應用程式相容性的中繼選項。 |
| 必要 | 所有用戶端都必須提供通道繫結資訊。 用戶端若未提供此資訊，伺服器會拒絕其驗證要求。 |
這些屬性可以結合稽核功能，以收集不同層級 EPA 強制執行裝置相容性的相關信息。 您會將所需的設定傳遞至 SspiSetChannelBindingFlags。
- 稽核 - 稽 核模式可與上述任何 EPA 強制執行層級搭配使用。
如何解譯 EPA 稽核結果？
稽核結果是一組位旗標：
| 旗標 | 描述 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT | 用戶端指出其能夠進行通道系結。 |
| SEC_CHANNEL_BINDINGS_RESULT_ABSENT | 用戶端未提供外部通道的系結。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | 用戶端系結表示與伺服器不同的通道。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | 通道系結因為SEC_CHANNEL_BINDINGS_RESULT_ABSENT而失敗。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED | 通道已成功系結。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY | 用戶端表示系結至外部通道，因為ASC_REQ_PROXY_BINDINGS傳遞。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING | 通道系結因為 ASC_REQ_ALLOW_MISSING_BINDINGS而傳遞。 |
也有一組位的定義：
| 旗標 | 描述 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_VALID | 用來測試所有 SEC_CHANNEL_BINDINGS_VALID_* 案例。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID | 用來測試所有 SEC_CHANNEL_BINDINGS_NOTVALID_* 案例。 |
稽核流程
任何支持結果的OS一律會設定至少一個位的 SEC_CHANNEL_BINDINGS_RESULT_VALID 和 SEC_CHANNEL_BINDINGS_RESULT_NOTVALID。
通道系結失敗： 測試來自 SEC_CHANNEL_BINDINGS_RESULT_NOTVALID的任何位。 對於非僅限稽核的系結，這會對應至 ASC 失敗並STATUS_BAD_BINDINGS或SEC_E_BAD_BINDINGS。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH： 客戶端和伺服器都瞭解通道系結，但不同意通道。 這是攻擊案例或與攻擊無區別的不當安全性設定，因為組態已危害 HTTPS 來檢查流量（例如 Fiddler）。 它也可能是客戶端和伺服器不同意唯一與端點系結。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING分成兩種案例：
- 有了 SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT，這意味著客戶證明它知道通道系結，並說沒有頻道。 這可能是來自非 TLS 服務的轉送攻擊，但可能是在執行 TLS 但未告知內部驗證的用戶端上執行未覺察的應用程式。
- 如果沒有 SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT，它是無法進行通道系結的用戶端。 所有支援的 Windows 版本都能夠進行通道系結，因此這是第三方或登錄值 SuppressExtendedProtection 設定的系統。 如果您通過ASC_REQ_ALLOW_MISSING_BINDINGS，這會變成SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING。
通道系結成功： 這是失敗檢查的反轉，或測試 SEC_CHANNEL_BINDINGS_RESULT_VALID。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED是成功案例。 安全性保護正在運作（或如果僅啟用 EPA 作為稽核，則運作正常）。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING表示已傳遞ASC_REQ_ALLOW_MISSING_BINDINGS，因此我們允許未宣告通道系結支援的用戶端。 達到此案例的用戶端不會受到保護，因此應該進行調查，以查看錯誤。 它們必須更新以支援通道系結，或更新中斷的應用程式之後，應該清除 SuppressExtendedProtection 登錄值。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY是與旗標相關聯的特殊案例，ASC_REQ_PROXY_BINDINGS在負載平衡器終止 TLS 時使用，而不是到達伺服器。 伺服器無法確認用戶端使用與負載平衡器終止相同的 TLS 連線。 針對稽核目的，這會被視為與 SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED相同。
另請參閱
驗證擴充保護概觀 \(機器翻譯\)