Protezione di applicazioni del canale peer

Analogamente alle altre associazioni in .NET Framework 3.0, NetPeerTcpBinding ha la protezione attivata per impostazione predefinita e offre la protezione basata sul trasporto e/o sui messaggi. In questo argomento vengono illustrati questi due tipi di protezione. Il tipo di protezione viene specificato dal tag della modalità di protezione nella specifica dell'associazione (SecurityMode ).

Protezione basata sul trasporto

Il canale peer supporta due tipi di credenziali di autenticazione per la protezione del trasporto ed entrambi richiedono l'impostazione della proprietà ClientCredentialSettings.Peer sulla ChannelFactory associata:

  • Password. I client utilizzano la conoscenza di una password segreta per autenticare le connessioni. Quando viene utilizzato questo tipo di credenziale, ClientCredentialSettings.Peer.MeshPassword deve passare una password valida e, facoltativamente, un'istanza di X509Certificate2.
  • Certificato. Viene utilizzata l'autenticazione dell'applicazione specifica. Quando viene utilizzato questo tipo di credenziale, è necessario utilizzare un'implementazione concreta di X509CertificateValidator in ClientCredentialSettings.Peer.PeerAuthentication.

Protezione basata sui messaggi

Utilizzando la protezione dei messaggi, un'applicazione può firmare i messaggi in uscita in modo che tutte le parti riceventi possano verificare che il messaggio sia stato inviato da una parte attendibile e non sia stato manomesso. Il canale peer supporta attualmente solo la firma dei messaggi con la credenziale X.509.

Procedure consigliate

  • In questa sezione vengono illustrate le procedure consigliate per la protezione di applicazioni del canale peer.

Attivare la protezione con le applicazioni del canale peer

A causa della natura distribuita dei protocolli del canale peer, è difficile imporre appartenenza, riservatezza e privacy in una rete non protetta. È inoltre importante ricordare di proteggere la comunicazione tra i client e il servizio resolver. In PNRP (Peer Name Resolution Protocol) utilizzare nomi protetti per evitare lo spoofing e altri attacchi comuni. Proteggere un servizio resolver personalizzato attivando la protezione sui client di connessione utilizzati per contattare il servizio resolver, prevedendo entrambe le forme di protezione, quella basata sul trasporto e quella basata sui messaggi.

Utilizzare il modello di protezione più sicuro possibile

Ad esempio, se ogni membro della mesh deve essere identificato individualmente, utilizzare il modello di autenticazione basato sui certificati. Se ciò non è possibile, utilizzare l'autenticazione basata sulle password, seguendo i consigli correnti per mantenerle protette, tra cui sono inclusi i seguenti: condividere le password solo con parti attendibili, trasmettere le password utilizzando un canale protetto, modificare le password frequentemente e verificare che le password siano complesse, che siano cioè lunghe almeno otto caratteri e includano almeno una lettera maiuscola e una minuscola, un numero e un carattere speciale.

Non accettare mai certificati autofirmati

Non accettare mai una credenziale di certificato basata sui nomi dei soggetti. Si noti che chiunque può creare un certificato e chiunque può scegliere un nome che si sta convalidando. Per evitare la possibilità di spoofing, convalidare i certificati sulla base delle credenziali dell'autorità emittente (un'autorità emittente attendibile o un'autorità di certificazione radice).

Utilizzare l'autenticazione dei messaggi

Utilizzare l'autenticazione dei messaggi per verificare che un messaggio abbia origine da una fonte attendibile e che non sia stato manomesso durante la trasmissione. Senza l'autenticazione dei messaggi è facile per un client dannoso effettuare lo spoofing dei messaggi nella mesh o manometterli.

Esempi di codice del canale peer

Peer Channel Secure Chat

Peer Channel Custom Authentication

Peer Channel Message Authentication

Vedere anche

Concetti

Protezione del canale peer
Creazione di un'applicazione del canale peer