Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si usa HTTP come trasporto, la sicurezza viene fornita da un'implementazione SSL (Secure Sockets Layer). SSL viene ampiamente usato su Internet per autenticare un servizio a un client e quindi per fornire riservatezza (crittografia) al canale. Questo articolo illustra il funzionamento di SSL e il modo in cui viene implementato in Windows Communication Foundation (WCF).
SSL di base
Il funzionamento di SSL è illustrato meglio tramite uno scenario tipico, in questo caso, il sito Web di una banca. Il sito consente a un cliente di accedere con un nome utente e una password. Dopo l'autenticazione, l'utente può eseguire transazioni, ad esempio visualizzare i saldi del conto, pagare le fatture e spostare denaro da un account a un altro.
Quando un utente visita per la prima volta il sito, il meccanismo SSL inizia una serie di negoziati, denominati handshake, con il client dell'utente (in questo caso, il Web browser). SSL autentica innanzitutto il sito bancario al cliente. Si tratta di un passaggio essenziale perché i clienti devono prima sapere che comunicano con il sito effettivo e non uno spoofing che tenta di attirarli nella digitazione del nome utente e della password. SSL esegue questa autenticazione usando un certificato SSL fornito da un'autorità attendibile, ad esempio VeriSign. La logica funziona così: VeriSign garantisce l'identità del sito bancario. Poiché il browser considera VeriSign attendibile, il sito è attendibile. Se si vuole controllare con VeriSign, è possibile farlo anche facendo clic sul logo VeriSign. Che presenta una dichiarazione di autenticità con la sua data di scadenza e a chi è destinata (vale a dire, il sito bancario).
Per avviare una sessione sicura, il client invia l'equivalente di un "hello" al server insieme a un elenco di algoritmi crittografici che può usare per firmare, generare hash e crittografare e decrittografare con. In risposta, il sito invia un riconoscimento e la sua scelta di uno dei pacchetti di algoritmi. Durante questo handshake iniziale, entrambe le parti inviano e ricevono i nonces. Un nonce è una parte di dati generata in modo casuale, in combinazione con la chiave pubblica del sito, per creare un hash. Un hash è un nuovo numero derivato dai due numeri usando un algoritmo standard, ad esempio SHA1. Il client e il sito scambiano anche messaggi per accettare quale algoritmo hash usare. L'hash è univoco e viene usato solo per la sessione tra il client e il sito per crittografare e decrittografare i messaggi. Sia il client che il servizio hanno il nonce originale e la chiave pubblica del certificato, in modo che entrambe le parti possano generare lo stesso hash. Pertanto, il client convalida l'hash inviato dal servizio da (a) usando l'algoritmo concordato per calcolare l'hash dai dati e (b) confrontandolo con l'hash inviato dal servizio; se le due corrispondenze, il client ha la garanzia che l'hash non sia stato manomesso. Il client può quindi usare questo hash come chiave per crittografare un messaggio che contiene ancora un nuovo hash. Il servizio può decrittografare il messaggio usando l'hash e recuperare questo hash penultimo. Le informazioni accumulate (nonces, chiave pubblica e altri dati) sono ora note a entrambi i lati e è possibile creare un hash finale (o chiave master). Questa chiave finale viene inviata crittografata usando l'hash successivo all'ultimo. La chiave master viene quindi usata per crittografare e decrittografare i messaggi per il resto della sessione. Poiché sia il client che il servizio usano la stessa chiave, questa operazione viene chiamata anche chiave di sessione.
La chiave di sessione è anche caratterizzata da una chiave simmetrica o da un "segreto condiviso". La presenza di una chiave simmetrica è importante perché riduce il calcolo richiesto da entrambi i lati della transazione. Se ogni messaggio richiedesse un nuovo scambio di nonce e hash, le prestazioni peggiorerebbero. Pertanto, l'obiettivo finale di SSL è quello di usare una chiave simmetrica che consente ai messaggi di fluire liberamente tra i due lati con un maggiore grado di sicurezza ed efficienza.
La descrizione precedente è una versione semplificata di ciò che accade, perché il protocollo può variare da sito a sito. È anche possibile che sia il client sia il sito generino dei nonce che vengono combinati in modo algoritmico durante l'handshake per aggiungere maggiore complessità e quindi maggiore protezione al processo di scambio dei dati.
Certificati e infrastruttura a chiave pubblica
Durante l'handshake, il servizio invia anche il certificato SSL al client. Il certificato contiene informazioni, ad esempio la data di scadenza, l'autorità emittente e l'URI (Uniform Resource Identifier) del sito. Il cliente compara l'URI con quello che aveva originariamente contattato per garantire una corrispondenza e controlla anche la data e l'autorità emittente.
Ogni certificato ha due chiavi, una chiave privata e una chiave pubblica e i due sono noti come coppia di chiavi di scambio. In breve, la chiave privata è nota solo al proprietario del certificato mentre la chiave pubblica è leggibile dal certificato. Entrambe le chiavi possono essere usate per crittografare o decrittografare un digest, un hash o un'altra chiave, ma solo come operazioni contrarie. Ad esempio, se il client esegue la crittografia con la chiave pubblica, solo il sito può decrittografare il messaggio usando la chiave privata. Analogamente, se il sito esegue la crittografia con la chiave privata, il client può decrittografare con la chiave pubblica. Ciò garantisce al client che i messaggi vengono scambiati solo con il possessore della chiave privata perché solo i messaggi crittografati con la chiave privata possono essere decrittografati con la chiave pubblica. Il sito è certo che sta scambiando messaggi con un client che ha crittografato usando la chiave pubblica. Questo scambio è sicuro solo per un handshake iniziale, ma questo è il motivo per cui si fa molto di più per creare la chiave simmetrica effettiva. Tuttavia, tutte le comunicazioni dipendono dal servizio con un certificato SSL valido.
Implementazione di SSL con WCF
La sicurezza del trasporto HTTP (o SSL) viene fornita esternamente a WCF. È possibile implementare SSL in uno dei due modi seguenti: il fattore di scelta è il modo in cui l'applicazione è ospitata:
Se si usa Internet Information Services (IIS) come host WCF, usare l'infrastruttura IIS per configurare un servizio SSL.
Se si crea un'applicazione WCF self-hosted, è possibile associare un certificato SSL all'indirizzo usando lo strumento di HttpCfg.exe.
Uso di IIS per la sicurezza del trasporto
IIS 7.0
Per configurare IIS 7.0 come host sicuro (tramite SSL), vedere Configurazione di Secure Sockets Layer in IIS 7.0.
Per configurare i certificati da usare con IIS 7.0, vedere Configurazione dei certificati del server in IIS 7.0.
IIS 6.0
Per configurare IIS 6.0 come host sicuro (tramite SSL), vedere Configurazione di Secure Sockets Layer.
Per configurare i certificati da usare con IIS 6.0, vedere Certificates_IIS_SP1_Ops.
Uso di HttpCfg per SSL
Se stai creando un'applicazione WCF ospitata autonomamente, usa lo strumento HttpCfg.exe.
Per altre informazioni sull'uso dello strumento HttpCfg.exe per configurare una porta con un certificato X.509, vedere Procedura: Configurare una porta con un certificato SSL.