Panoramica tecnica di SSP Schannel

Articolo
09/02/2016

Data di pubblicazione: agosto 2016

Si applica a: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

Questo argomento di riferimento per i professionisti IT descrive SSP (Security Support Provider) Schannel (Secure Channel) e i servizi di autenticazione forniti tramite i protocolli TLS (Transport Layer Security) e SSL (Secure Sockets Layer).

Questo argomento include le sezioni seguenti:

Informazioni su TLS, SSL e Schannel
Scenari TLS e SSL comuni
Schannel SSP Technical Overview
Dipendenze tra TLS e SSL

Nota

Il protocollo TLS è descritto nell'argomento Protocollo di sicurezza a livello di trasporto.

DTLS, incluso in SSP Schannel, è descritto nell'argomento Protocollo di datagramma Transport Layer Security.

Informazioni su TLS, SSL e Schannel

Uno dei problemi da affrontare quando si amministra una rete riguarda la protezione dei dati inviati tra le applicazioni su una rete non attendibile. È possibile usare TLS/SSL per autenticare i server e i client e quindi per crittografare i messaggi tra le entità autenticate.

I protocolli TLS, SSL, DTLS e il protocollo PCT (Private Communications Transport) sono basati su crittografia a chiave pubblica. La suite di protocolli di autenticazione Schannel include questi protocolli. Tutti i protocolli Schannel usano un modello client e server. Per un elenco di protocolli supportati, vedere Pacchetti di crittografia e protocolli supportati in SSP Schannel.

Nel processo di autenticazione, un computer client TLS/SSL invia un messaggio a un server TLS/SSL e il server risponde con le informazioni necessarie per la propria autenticazione. Il client e il server eseguono un scambio di chiavi della sessione aggiuntivo e il dialogo di autenticazione termina. Al termine dell'autenticazione, può iniziare la comunicazione SSL tra il server e il client con le chiavi di crittografia simmetrica stabilite durante il processo di autenticazione.

Per l'autenticazione dei server con i client, TLS/SSL non richiede l'archiviazione delle chiavi del server nei controller di dominio o in un database, ad esempio Servizi di dominio Active Directory. I client verificano la validità delle credenziali del server con i certificati dell'autorità di certificazione radice attendibile, che vengono caricati quando si installa un sistema operativo Windows Server. Di conseguenza, a meno che l'autenticazione utente non sia richiesta dal server, gli utenti non devono definire gli account prima di creare una connessione protetta con un server.

Cronologia e standard per TLS e SSL

SSL è stato sviluppato da Netscape Communications Corporation nel 1994 per proteggere le transazioni sul World Wide Web. Poco dopo, Internet Engineering Task Force (IETF) ha iniziato a sviluppare un protocollo standard che fornisce la stessa funzionalità. SSL 3.0 è stato usato come base di questa iniziativa e si è evoluto nel protocollo TLS. L'implementazione del protocollo TLS, a partire da Windows Server 2003, è strettamente conforme alla specifica definita nelle specifiche seguenti elencate nel database IETF RFC:

SSL e TLS sono ampiamente riconosciuti come i protocolli che offrono transazioni HTTP sicure (HTTPS) per Internet tra Web browser e server Web. TLS/SSL può essere usato anche per altri protocolli a livello di applicazione, ad esempio FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol) e SMTP (Simple Mail Transfer Protocol). TLS/SSL abilita l'autenticazione server, l'autenticazione client, la crittografia dei dati e l'integrità dei dati su reti come il World Wide Web.

Differenze tra TLS e SSL

Anche se esistono alcune lievi differenze tra SSL 3.0 e le versioni di TLS, questa guida di riferimento si riferisce al protocollo come TLS/SSL.

Nota

TLS e SSL 3.0 non sono intercambiabili, anche se le differenze sono minime. Se lo stesso protocollo non è supportato dal client e server, devono negoziare un protocollo comune per comunicare in modo corretto.

Poiché SSL era vulnerabile ai crescenti attacchi alla sicurezza, IETF ha sviluppato standard Internet per un protocollo più sicuro, ovvero TLS. L'elenco seguente descrive i miglioramenti a TLS che vanno oltre la capacità di SSL di proteggere le comunicazioni su reti non attendibili.

L'algoritmo HMAC di hash con chiave (Keyed-Hash Message Authentication Code) sostituisce l'algoritmo SSL MAC (Message Authentication Code).
TLS è standardizzato ed è uno standard Internet, mentre SSL presenta numerose varianti.
TLS contiene messaggi di avviso aggiuntivi.
SSL richiede i certificati emessi dalla CA radice o concatenati ad essa. Quando si usa TLS, non è sempre necessario includere i certificati concatenati alla CA radice. È possibile usare un'autorità di intermedia.
Gli algoritmi Fortezza non sono inclusi nella RFC TLS perché non sono aperti alla revisione pubblica.

Vantaggi di TLS e SSL

TLS/SSL offre numerosi vantaggi rispetto all'uso di altri metodi di autenticazione per client e server. La tabella seguente descrive alcuni di questi vantaggi:

Vantaggio	Descrizione
Autenticazione avanzata, riservatezza dei messaggi e integrità.	TLS/SSL può facilitare la protezione dei dati trasmessi usando la crittografia. TLS/SSL esegue l'autenticazione dei server e, facoltativamente, dei client per dimostrare l'identità dei sistemi coinvolti in una comunicazione protetta. Fornisce anche l'integrità dei dati tramite un valore di controllo integrità. Oltre alla protezione contro la divulgazione dei dati, è possibile usare il protocollo di sicurezza TLS/SSL per proteggersi da attacchi di mascheramento, attacchi man-in-the-middle o attacchi bucket brigade, di tipo rollback e di riproduzione.
Interoperabilità	TLS/SSL funziona con la maggior parte dei Web browser e la maggior parte dei sistemi operativi e dei server web. È spesso integrato in lettori di news, server LDAP e una varietà di altre applicazioni disponibili in commercio.
Flessibilità degli algoritmi	TLS/SSL fornisce opzioni per i meccanismi di autenticazione, gli algoritmi di crittografia e gli algoritmi hash usati durante la sessione protetta.
Facilità di distribuzione	Molte applicazioni usano TLS/SSL in modo trasparente nei sistemi operativi Windows Server. Si può usare TLS per un'esplorazione più protetta tramite Internet Explorer e Internet Information Services (IIS). Se nel server è già installato un certificato del server, si deve solo selezionare la casella di controllo in Internet Explorer.
Facilità d'uso	Poiché si implementa TLS/SSL nel livello dell'applicazione, la maggior parte delle operazioni è completamente invisibile al computer client. In questo modo, pur avendo una conoscenza limitata o nulla della sicurezza delle comunicazioni, il client è comunque protetto da eventuali autori di attacchi.

Limitazioni di TLS e SSL

Esistono due limitazioni all'uso di TLS/SSL, come illustrato nella tabella seguente.

Limitazione	Descrizione
Aumento del carico del processore	Questa è la limitazione più significativa all'implementazione di TLS/SSL. La crittografia, in particolare per le operazioni a chiave pubblica, richiede un utilizzo elevato della CPU. Le prestazioni variano di conseguenza quando si usa SSL. Purtroppo, non esiste un modo per conoscere il livello di prestazioni che andrà perso. Le prestazioni variano a seconda della frequenza e della durata delle connessioni. TLS usa la quantità maggiore di risorse durante la configurazione delle connessioni.
Sovraccarico amministrativo	Un ambiente TLS/SSL è complesso e richiede attività di manutenzione. L'amministratore di sistema deve configurare il sistema e gestire i certificati.

Aumento del carico del processore

Questa è la limitazione più significativa all'implementazione di TLS/SSL. La crittografia, in particolare per le operazioni a chiave pubblica, richiede un utilizzo elevato della CPU. Le prestazioni variano di conseguenza quando si usa SSL. Purtroppo, non esiste un modo per conoscere il livello di prestazioni che andrà perso. Le prestazioni variano a seconda della frequenza e della durata delle connessioni. TLS usa la quantità maggiore di risorse durante la configurazione delle connessioni.

Sovraccarico amministrativo

Un ambiente TLS/SSL è complesso e richiede attività di manutenzione. L'amministratore di sistema deve configurare il sistema e gestire i certificati.

Scenari TLS e SSL comuni

Molte persone considerano SSL e TLS come protocolli usati con i Web browser per accedere a Internet in modo più sicuro. Tuttavia, sono anche protocolli di utilizzo generico che possono essere usati ogni volta che sono necessarie operazioni di autenticazione e protezione dei dati. Infatti, la possibilità di accedere a questi protocolli tramite SSPI (Security Service Provider Interface) indica che possono essere usati per quasi tutte le applicazioni. Molte applicazioni vengono modificate per sfruttare le funzionalità di TLS/SSL. La tabella seguente include esempi relativi all'uso di TLS/SSL.

Scenario	Descrizione
Transazioni SSL con un sito Web di e-commerce	Questa situazione rappresenta un uso tipico di SSL tra un browser e un server Web. Ne è un esempio un sito per acquisti e-commerce in cui i clienti devono fornire i numeri di carta di credito. Il protocollo verifica prima di tutto che il certificato del sito Web sia valido e quindi invia le informazioni della carta di credito come testo crittografato. Per questo tipo di transazione, se il certificato del server proviene da una fonte attendibile, l'autenticazione viene eseguita solo per il server. TLS/SSL deve essere abilitato per la pagina Web, ad esempio un modulo d'ordine, in cui si verificano le transazioni dati.
Accesso client autenticato a un sito Web protetto con SSL	Il client e server necessitano di certificati da un'autorità di certificazione (CA) reciprocamente attendibile. Con SSP Schannel è possibile eseguire il mapping dei certificati in base uno a uno a uno o molti a uno ad account utente o computer in un sistema operativo Windows Server. Possono quindi essere gestiti con Utenti e computer di Active Directory e gli utenti possono essere autenticati in un sito Web senza fornire una password. Il mapping molti-a-uno ha diversi usi. Ad esempio, se si vuole concedere l'accesso a materiale riservato a più utenti, è possibile creare un gruppo, eseguire il mapping dei certificati degli utenti al gruppo e assegnare al gruppo le autorizzazioni necessarie per il materiale. Nel mapping uno a uno il server ha di una copia del certificato del client e quando un utente accede dal computer client, il server verifica che siano identici. Questo tipo di mapping uno a uno viene usato in genere per materiale privato, ad esempio un sito Web di servizi bancari in cui una sola persona ha il diritto di visualizzare un account personale.
Accesso remoto	Il telelavoro rappresenta un uso comune di SSP Schannel. È possibile usare questa tecnologia per fornire l'autenticazione e la protezione dei dati quando gli utenti accedono in modalità remota a reti o sistemi basati su Windows. Gli utenti possono accedere in modo più sicuro alle applicazioni di posta elettronica o aziendali da casa o in viaggio, riducendo il rischio di esposizione delle informazioni a chiunque su Internet.
Accesso a SQL Server	È possibile richiedere l'autenticazione di un computer client quando si connette a un server che esegue SQL Server. Il client o il server può essere configurato per richiedere la crittografia dei dati trasferiti tra di essi. Le informazioni molto riservate, ad esempio database finanziari o medici, possono essere protette per impedire accessi non autorizzati e la divulgazione di informazioni in rete.
Posta elettronica	Quando si usa Exchange Server è possibile usare SSP Schannel per proteggere i dati durante lo spostamento da server a server nella rete Intranet o in Internet. La sicurezza completa end-to-end potrebbe richiedere l'uso di S/MIME (Secure/Multipurpose Internet Mail Extensions). Tuttavia, la protezione dei dati in uno scambio da server a server consente alle aziende di usare Internet per trasferire in modo sicuro la posta elettronica tra le divisioni dell'azienda stessa, le relative filiali e i partner. Questa configurazione è possibile indipendentemente dall'uso di S/MIME.

Architettura di SSP Schannel

Nei sistemi operativi Windows Server la suite di protocolli di autenticazione Schannel include TLS. Il diagramma seguente illustra in che posizione si inserisce SSP Schannel tra queste e altre tecnologie. Le applicazioni client o server usano Secur32.dll tramite chiamate SSPI per comunicare con LSASS (Local Security Authority Subsystem Service).

Architettura di SSP Schannel

Schannel Architecture

La tabella seguente include le descrizioni degli elementi che fanno parte di TLS/SSL.

Elementi del sottosistema di sicurezza usati nell'autenticazione TLS e SSL

Elemento	Descrizione
Schannel.dll	Protocollo di autenticazione TLS/SSL. Questo protocollo fornisce l'autenticazione su un canale crittografato invece di un canale non crittografato meno sicuro.
Lsasrv.dll	LSASS applica i criteri di sicurezza e funge da Gestione pacchetto di sicurezza per l'autorità di sicurezza locale.
Netlogon.dll	Relativamente ai servizi TLS il servizio Accesso rete passa le informazioni sul certificato dell'utente tramite un canale SSL al controller di dominio per eseguire il mapping del certificato utente a un account utente.
Secur32.dll	Il provider di autenticazione multiplo che implementa SSPI.

La suite di protocolli di autenticazione è abilitata da SSP Schannel, supportato dall'API (Application Programming Interface) SSPI che fornisce i servizi di sicurezza per i sistemi operativi Windows Server.

Microsoft Security Support Provider Interface (SSPI) è la base per le operazioni di autenticazione nel sistema operativo Windows, ovvero le applicazioni e i servizi di infrastruttura che richiedono l'autenticazione usano SSPI per fornirla. Quando un client e server devono essere autenticati per poter comunicare in modo più sicuro, le richieste di autenticazione vengono indirizzate a SSPI, che completa il processo di autenticazione, indipendentemente dal protocollo di rete attualmente in uso. SSPI è l'implementazione di GSSAPI (Generic Security Services Application Programming Interface). Per altre informazioni su GSSAPI, vedere le RFC seguenti nel database IETF RFC.

Per informazioni sull'architettura SSPI per tutti gli SSP e su come si inserisce il provider Kerberos in questa architettura, vedere Security Support Provider Interface Architecture.

È possibile usare SSP Schannel per l'accesso ai servizi abilitati per il Web, ad esempio posta elettronica o informazioni personali presentate nelle pagine Web. SSP Schannel usa certificati a chiave pubblica per l'autenticazione delle entità. La suite include quattro protocolli di autenticazione. Per l'autenticazione di entità, selezionerà uno dei quattro protocolli nell'ordine di preferenza seguente:

TLS versione 1.2
TLS versione 1.1
TLS versione 1.0
SSL versione 3.0

SSP Schannel seleziona quindi il protocollo di autenticazione preferito che il client e il server possono supportare. Ad esempio, se un server supporta tutti e quattro i protocolli Schannel e il computer client supporta solo SSL 3.0, il provider Schannel userà SSL 3.0 per l'autenticazione.

Gestione delle autorità emittenti attendibili per l'autenticazione client

Prima di Windows Server 2012 e Windows 8, le applicazioni o i processi che usavano SSP Schannel (inclusi HTTP.sys e IIS) potevano fornire un elenco delle autorità emittenti attendibili supportate per l'autenticazione client. Queste informazioni venivano fornite tramite un elenco scopi consentiti ai certificati.

Quando è necessario effettuare l'autenticazione del computer client con SSL o TLS, il server può essere configurato per l'invio di un elenco di autorità di certificazione attendibili. L'elenco contiene il set di autorità di certificazione che il server considererà attendibili e indica al computer client il certificato client da selezionare se sono presenti più certificati. Inoltre, la catena di certificati che il computer client invia al server deve essere convalidata rispetto all'elenco di autorità emittenti attendibili configurate.

In Windows Server 2012 e Windows 8 sono state apportate modifiche al processo di autenticazione sottostante in modo che:

La gestione dell'elenco di autorità emittenti attendibili basata sull'elenco scopi consentiti non sia più supportata.
Il comportamento di invio dell'elenco di autorità emittenti attendibili sia disattivato per impostazione predefinita. Il valore predefinito della chiave del Registro di sistema SendTrustedIssuerList è ora 0 (disattivato per impostazione predefinita) invece di 1.
Venga mantenuta la compatibilità con le versioni precedenti dei sistemi operativi Windows.

Questo consente una maggiore semplicità di gestione con i cmdlet esistenti per la gestione dei certificati nel provider Windows PowerShell, nonché gli strumenti da riga di comando come certutil.exe. Anche se la dimensione massima dell'elenco di autorità di certificazione attendibili supportate da SSP Schannel (16 KB) resta invariata in Windows Server 2008 R2, in Windows Server 2012 esiste un nuovo archivio certificati dedicato per le autorità emittenti per l'autenticazione client che consente di non includere nel messaggio client/server i certificati non correlati.

Come funziona

L'elenco di autorità emittenti attendibili viene configurato usando gli archivi certificati: un archivio certificati globale predefinito del computer e un archivio facoltativo per ogni sito. L'origine dell'elenco viene determinata come segue:

Se è presente un archivio credenziali specifico configurato per il sito, verrà usato come origine.
Se non esistono certificati nell'archivio definito dall'applicazione, Schannel controlla l'archivio di autorità emittenti per l'autenticazione client del computer locale. Se sono presenti certificati, Schannel usa tale archivio come origine.
Se nessuno dei due archivi locale o globale contiene certificati, SSP Schannel userà l'archivio delle autorità di certificazione radice attendibili come origine dell'elenco di autorità emittenti attendibili. Questo è anche il comportamento in Windows Server 2008 R2.

È possibile creare un elenco di nomi di probabili autorità di certificazione per forniscono all'utente finale suggerimenti su come quella da scegliere. L'elenco è configurabile con Criteri di gruppo.

Se l'archivio di autorità di certificazione radice attendibili contiene una combinazione di certificati radice (autofirmati) e di certificati dell'autorità di certificazione (CA), per impostazione predefinita verranno inviati al server solo i certificati delle autorità di certificazione.

Come configurare Schannel per usare l'archivio certificati delle autorità emittenti attendibili

Per gestire l'elenco di autorità emittenti attendibili, SSP Schannel usa gli archivi descritti sopra per impostazione predefinita. Per gestire i certificati, è comunque sempre possibile usare i cmdlet esistenti nel provider Windows PowerShell, nonché gli strumenti da riga di comando come certutil.exe.

Per informazioni sulla gestione dei certificati con il provider Windows PowerShell, vedere Cmdlet di amministrazione di Servizi certificati Active Directory in Windows.

Per informazioni sulla gestione dei certificati con l'utilità per la gestione di certificati, vedere certutil.exe.

Per informazioni sui dati, ad esempio l'archivio definito dall'applicazione, specificati per le credenziali di Schannel, vedere Struttura SCHANNEL_CRED (Windows).

Configurazione di un'applicazione o di una funzionalità per l'uso dell'archivio di emittenti per l'autenticazione client.

Per impostazione predefinita, alcune tecnologie non usano l'archivio di emittenti per l'autenticazione client. In questi casi, è necessario configurare la tecnologia per l'uso dell'archivio.

Ad esempio, con il server Web, HTTP.sys, che implementa lo stack di server HTTP di Windows, l'uso dell'archivio di emittenti per l'autenticazione client non è configurato per impostazione predefinita.

Per configurare HTTP.SYS per l'uso dell'archivio di emittenti per l'autenticazione client, è possibile usare il comando seguente:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Per trovare i valori di certhash e appid sul server, è possibile usare il comando seguente:

netsh http show sslcert

Impostazioni predefinite per le modalità di attendibilità

Esistono tre modalità di attendibilità dell'autenticazione client supportate da SSP Schannel. La modalità di attendibilità controlla come viene eseguita la convalida della catena di certificati del client. È un'impostazione a livello di sistema controllata da REG_DWORD "ClientAuthTrustMode" in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Valore	Modalità di attendibilità	Descrizione
0	Machine Trust (impostazione predefinita)	Richiede che il certificato client venga emesso da un'autorità di certificazione inclusa nell'elenco di autorità emittenti attendibili.
1	Exclusive Root Trust	Richiede che un certificato client sia concatenato a un certificato radice contenuto nell'archivio di emittenti attendibili specificato dal chiamante. Il certificato deve anche essere rilasciato dall'elenco di autorità emittenti attendibili.
2	Exclusive CA Trust	Richiede che un certificato client sia concatenato a un certificato della CA intermedia oppure a un certificato radice contenuto nell'archivio di autorità emittenti attendibili specificato dal chiamante.

Per informazioni sugli errori di autenticazione causati da problemi di configurazione delle autorità emittenti attendibili, vedere l'articolo 280256 della Microsoft Knowledge Base.

Dipendenze tra TLS e SSL

Per funzionare correttamente, SSL e TLS dipendono da diverse tecnologie e risorse correlate. La tabella seguente include una descrizione di queste tecnologie e risorse e un riepilogo delle rispettive relazioni con l'autenticazione TLS/SSL.

Dipendenza	Descrizione
Sistema operativo	L'autenticazione TLS e SSL si basa sulla funzionalità client incorporata nei sistemi operativi Windows Server e sistemi operativi client Windows. Se un client o server segue un sistema operativo che non supporta TLS/SSL, non potrà usare l'autenticazione TLS/SSL.
Connettività di rete TCP/IP	Per l'esecuzione dell'autenticazione TLS o SSL, deve essere disponibile la connettività di rete TCP/IP tra il client e server di destinazione. Per altre informazioni, vedere TCP/IP.
Dominio di Active Directory	Quando un'applicazione server richiede l'autenticazione client, SSP Schannel prova automaticamente a eseguire il mapping del certificato fornito dal client a un account utente. È possibile autenticare gli utenti che accedono con un certificato client creando manualmente mapping che mettono in relazione le informazioni sul certificato con un account utente di Windows. Dopo avere creato e abilitato il mapping di un certificato, ogni volta che un client presenta un certificato, l'applicazione server associa automaticamente l'utente con l'account utente corretto nel sistema operativo Windows. Se si vuole usare il mapping dei certificati, è necessario usare gli account utente in Servizi di dominio Active Directory. Per altre informazioni, vedere Panoramica di Servizi di dominio Active Directory.
Autorità di certificazione attendibili	Poiché l'autenticazione si basa sui certificati digitali, le autorità di certificazione (CA), ad esempio Verisign o Servizi certificati Active Directory, sono una parte importante di TLS/SSL. Un'autorità di certificazione è una società non Microsoft reciprocamente attendibile che conferma l'identità del richiedente di un certificato, in genere un utente o un computer, e quindi rilascia un certificato al richiedente. Il certificato associa l'identità del richiedente a una chiave pubblica. Le autorità di certificazione possono anche rinnovare e revocare i certificati in base alle esigenze. Ad esempio, se a un client viene presentato un certificato del server, il computer client potrebbe provare a trovare l'autorità di certificazione del server corrispondente nell'elenco di autorità di certificazione attendibili del client. Se la CA emittente è attendibile, il client verificherà che il certificato sia autentico e non sia stato manomesso. Per atre informazioni, vedere Panoramica di Servizi certificati Active Directory.

Vedere anche

Riferimento tecnico Provider supporto sicurezza Schannel

Share via