| 特徵 | 適用於 |
|---|---|
| EPA | 所有支援的 Windows 作業系統 |
| EPA 稽核模式 | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
問題是什麼？
有一類針對有認證的服務的攻擊，名叫轉送攻擊。 這些攻擊可讓敵人略過驗證，並充當另一個使用者。 因為這些是服務的攻擊，而不是驗證通訊協定本身，所以由已驗證的服務來挫敗轉送攻擊。
轉送攻擊如何運作？
當服務或應用程式呼叫 API AcceptSecurityContext 來驗證用戶端時，它會將從用戶端執行 InitializeSecurityContext所收到的資料 blob 傳遞給該 API。 驗證通訊協議負責驗證提供的 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 的輸出緩衝區。
- 以透過呼叫 AcceptSecurityContext 和 SECBUFFER_CHANNEL_BINDINGS 來指定 EPA 層級和其他設定。
- （選擇性）使用旗標來控制角落案例的行為：
- ASC_REQ_ALLOW_MISSING_BINDINGS - 不要讓未傳送任何訊息的客戶端失敗，例如舊的第三方設備。 未取得 SECBUFFER_CHANNEL_BINDINGS 的明智客戶會傳送空的綁定，而不是什麼都不傳送。
- ASC_REQ_PROXY_BINDINGS - TLS 終止負載均衡器的罕見案例。 我們沒有 SECBUFFER_CHANNEL_BINDINGS 可以傳遞，但仍然希望強制要求用戶端通過 TLS 通道進行請求。 這在服務綁定中非常有用，可以確保用戶端同樣輸入到其伺服器憑證符合我們的名稱的 TLS 通道中。
如何強制執行環保法規（EPA）？
一旦服務支援 EPA，系統管理員可以控制 EPA 狀態，從稽核到完全強制執行。 這可讓服務服務評估其生態系統的環保局整備程度、補救不相容的裝置，並逐步強制執行 EPA 來保護其環境。
下列屬性和值可用來在您的環境中強制執行不同層級的 EPA：
| 名字 | 描述 |
|---|---|
| 沒有 | 不會執行通道系結驗證。 這是所有尚未更新的伺服器的行為。 |
| 允許 | 所有已更新的客戶端都必須提供通道系結資訊給伺服器。 尚未更新的用戶端不需要這麼做。 這是允許應用程式相容性的中繼選項。 |
| 需要 | 所有客戶端都必須提供通道系結資訊。 伺服器會拒絕來自未進行驗證的客戶端的驗證要求。 |
這些屬性可以結合稽核功能，以收集不同層級 EPA 強制執行裝置相容性的相關信息。 您會將所需的設定傳遞至 SspiSetChannelBindingFlags。
- 稽核 - 稽核模式可與上述任何 EPA 強制執行層級搭配使用。
如何解譯 EPA 稽核結果？
稽核結果是一組位元旗標：
| 旗 | 描述 |
|---|---|
| There are no suggested changes if the text is a technical term that should remain in English. | 用戶端指出其能夠進行通道系結。 |
| 安全通道綁定結果缺席 | 用戶端未提供外部通道的系結。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | 用戶端系結表示與伺服器不同的通道。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | 通道綁定因為 SEC_CHANNEL_BINDINGS_RESULT_ABSENT而失敗。 |
| 通道綁定結果有效匹配 | 通道已成功系結。 |
| 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相同。