Transport vs Message Security

Transport security protects data during transit across a single physical or logical hop by wrapping the entire communication channel — for HTTP this means TLS/SSL (HTTPS), for netTcpBinding it means a TLS handshake negotiated directly over the TCP socket, and for netNamedPipeBinding it relies on the operating system's process isolation. Because encryption happens below the WCF message layer, the SOAP envelope itself is sent as plaintext into an already-encrypted pipe; anyone who could see inside the pipe (e.g., an intermediary that terminates and re-establishes TLS) would see the raw message. Message security instead operates inside WCF's channel stack, applying WS-Security standards (WS-SecureConversation, WS-Trust) to encrypt and/or digitally sign specific parts of the SOAP message before it is ever handed to the transport, so the protection is intrinsic to the message and survives being relayed through routers, queues, or intermediary services.

Transport security is generally cheaper: TLS handshakes are optimized in the OS/network stack, hardware-accelerated on many platforms, and the resulting payload has minimal overhead beyond the standard TLS record framing. It works best for simple point-to-point topologies where the client talks directly to the service with no intermediaries — a typical netTcpBinding service-to-service call inside a data center. Message security pays a real cost in CPU (asymmetric and symmetric cryptography applied per message, XML canonicalization for signing) and payload size (WS-Security headers, X.509 token references, signature blocks can add several kilobytes), but it is the only option that supports multi-hop scenarios such as routing through an intermediary like a WCF router, a message queue, or a federated identity broker, because each hop can forward the still-encrypted message without needing to decrypt and re-encrypt it.

In practice, most intranet service-to-service calls should default to Transport mode with netTcpBinding, since the network is already trusted, latency matters, and there is no intermediary to route through. Internet-facing services that must traverse proxies, gateways, or that need auditable, non-repudiable message-level signatures (for example, financial transactions requiring a durable proof of what was sent) should lean toward Message security or the TransportWithMessageCredential hybrid, accepting the extra CPU and payload cost as the price of end-to-end guarantees. A useful rule of thumb: transport protects the pipe, message protects the water — if you don't control every pipe segment between sender and receiver, protect the water itself.