Securing Peer Channel Applications

Artigo
08/31/2009

Like other bindings under the .NET Framework 3.0, NetPeerTcpBinding has security enabled by default and offers both transport- and message-based security (or both). This topic discusses these two types of security. The type of security is specified by the security mode tag in the binding specification (Security Mode).

Transport-Based Security

Peer Channel supports two types of authentication credentials for securing transport, both of which require setting out the ClientCredentialSettings.Peer property on the associated ChannelFactory:

Password. Clients use knowledge of a secret password to authenticate connections. When this credential type is used, ClientCredentialSettings.Peer.MeshPassword must carry a valid password and optionally an X509Certificate2 instance.
Certificate. Specific application authentication is used. When this credential type is used, you must use a concrete implementation of X509CertificateValidator in ClientCredentialSettings.Peer.PeerAuthentication.

Message-Based Security

Using message security, an application can sign outgoing messages so that all receiving parties can verify the message is sent by a trusted party and that the message was not tampered with. Currently, Peer Channel supports only X.509 credential message signing.

Best Practices

This section discusses the best practices for securing Peer Channel applications.

Enable Security with Peer Channel Applications

Due to the distributed nature of the Peer Channel protocols, it is hard to enforce mesh membership, confidentiality, and privacy in an unsecured mesh. It is also important to remember to secure communication between clients and the resolver service. Under Peer Name Resolution Protocol (PNRP), use secure names to avoid spoofing and other common attacks. Secure a custom resolver service by enabling security on the connection clients use to contact the resolver service, including both message- and transport-based security.

Use the Strongest Possible Security Model

For example, if each member of the mesh needs to be individually identified, use certificate-based authentication model. If that is not possible, use password-based authentication following current recommendations to keep them secure. This includes sharing passwords only with trusted parties, transmitting passwords using a secure medium, changing passwords frequently, and ensuring that passwords are strong (at least eight characters long, include at least one letter from both cases, a digit, and a special character).

Never Accept Self-Signed Certificates

Never accept a certificate credential based on subject names. Note that anyone can create a certificate, and anyone can choose a name that you are validating. To avoid the possibility of spoofing, validate certificates based on issuing authority credentials (either a trusted issuer or a root certificate authority).

Use Message Authentication

Use message authentication to verify that a message originated from a trusted source and that no one has tampered with the message during transmission. Without message authentication, it is easy for a malicious client to spoof or tamper with messages in the mesh.