The other day a customer was sending unauthenticated messages to a service and the requests were timing out over WsDualHttp. When using WsHttpBinding or NetTcpBinding, the customer received an authentication MessageFault.  Why was there no Fault returned over WsDualHttpBinding?

The reason has to do with securing composite-duplex channels. WsDualHttp uses two HTTP connections to provide its duplex nature, and messages are correlated between these two connections based on WS-Addressing (ReplyTo/MessageId).  Because of this, the server behavior is entirely dependent on data received from the client. If this client is malicious, then he can cause the server to do a couple of things:

• Initiate arbitrary outbound connections
• Cause a "bouncing DOS" attack. For example, consider a server A that can send messages to server B that’s behind a firewall. Suppose that client C can send messages to A, but cannot send messages directly to server B (due to the firewall). Now suppose that the client sends a badly secured message to server A, with a ReplyTo equal to server B. If we send back a fault for unsecured messages over WsDualHttp, this would result in C being able to DOS server B due to bounce-assistance from server A.

In addition, since these are two one-way channels, the HTTP response (202 Accepted) has already returned prior to the Security channel (or any higher-layer in the channel/dispatcher stack) being called. So we cannot simply piggy-back the fault over the HTTP back channel.