다음을 통해 공유

Fix to Disable Transport Security with Message Credentials

  • 아티클

I've sufficiently recovered from running the last week-long series covering fixes for WCF to do another one. This week I'll again be covering fixes for WCF that may be hard to find and explaining the details behind each problem.

This is another fix that adds the feature of using message security requests in a nominally unsafe way. When message security credentials are transmitted over a binding with transport security it's expected that the binding provides certain security guarantees in order to secure the credentials. For example, if you use a username and password for your message credentials then you don't want someone to get a copy of the request and extract the password.

This protection is ordinarily enforced by scanning down the stack of binding elements until the first security binding element is found, and then examining the security capabilities of the binding elements below the security binding element to see what protection they provide. In particular, it's expected that the remaining binding elements support server authentication, encrypt and sign requests, and encrypt and sign responses.

However, you might instead have undetectable ways of securing the transmission of the credentials. For example, if you have armed guards posted along the wiring to prevent eavesdroppers from connecting, or even a VPN, then the configuration may be secure despite the transport configuration being insecure.

Some years ago I wrote how to work around this problem by lying about the capabilities of your binding. Now there's simply a setting AllowInsecureTransport that you can enable on a SecurityBindingElement to disable the check.

This fix is available for download from KB article 971831.

Comments