It turns out that in addition to great food at Volunteer Park Café you may also encounter:
Female seeking Male
Height: 5′ 6"
A native of the Northwest, Megaen likes gourmet pizza and wine. Affable and vivacious, she enjoys good movies and has also been known to curl up with the latest Harry Potter book.
Male seeking Male
Occupation: Restaurant Manager
Height: 6′ 0"
Scott is a transplant from the mid-west and has great hope for the future of this country. He enjoys music and theater, and can make a mean cappuccino.
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.