Integrity and Privacy

Client/service communications that require mutual authentication must also take care to protect the traffic they exchange after successful authentication. It does no good to mutually authenticate at the time of the initial connection to the service if the traffic is later subject to modification by an attacker. SSPI, RPC, and COM all provide facilities for digitally signing and encrypting messages. Applying digital signatures prevents modified traffic from going undetected and discourages eavesdropping. Traffic can be intercepted of course, but decrypting the traffic is sufficiently difficult to deter most attackers.

Unless performance requirements are very stringent, use of both signing and encryption is highly recommended, especially for administrative functions. Even when performance is an issue, some customers choose tighter security over better performance. In such cases, make integrity and privacy configurable options with higher security the default and higher performance the option.

RPC clients can specify the level of integrity and privacy when they call the RpcBindingSetAuthInfoEx function to set the authentication information for the RPC binding. Use RPC_C_AUTHN_LEVEL_PKT_INTEGRITY for signing and RPC_C_AUTHN_LEVEL_PKT_PRIVACY for encryption. For sample code that shows the use of these flags, see How a Client Authenticates an RpcNs Service.

Services that use an SSPI package for mutual authentication can query the package to determine whether it supports the MakeSignature, VerifySignature, EncryptMessage, and DecryptMessage functions for signing and encrypting messages. For sample code that illustrates the use of these functions, see Ensuring Communication Integrity During Message Exchange in the SSPI documentation.