Condividi tramite

Panoramica della terminazione TLS e di TLS end-to-end con il gateway applicazione

  • Articolo

Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL), è la tecnologia di sicurezza standard per stabilire un collegamento crittografato tra un server Web e un browser. Questo collegamento garantisce che tutti i dati passati tra il server Web e i browser rimangano privati e crittografati. Il gateway applicazione supporta sia la terminazione TLS nel gateway che la crittografia TLS end-to-end.

Terminazione TLS

Il gateway applicazione supporta la terminazione TLS nel gateway, dopo la quale il traffico scorre generalmente non crittografato verso i server back-end. La terminazione TLS nel gateway applicazione offre numerosi vantaggi:

  • Miglioramento delle prestazioni - L'operazione con l'impatto maggiore sulle prestazioni quando si esegue la decrittografia TLS è l'handshake iniziale. Per migliorare le prestazioni, il server che esegue la decrittografia memorizza nella cache gli ID di sessione TLS e gestisce i ticket della sessione TLS. Se questa operazione viene eseguita nel gateway applicazione, tutte le richieste dallo stesso client possono usare i valori memorizzati nella cache. Se viene eseguita nei server back-end, ogni volta che le richieste del client passano a un server diverso, il client deve ripetere l'autenticazione. L'uso di ticket TLS può aiutare a mitigare questo problema, ma non sono supportati da tutti i client e possono essere difficili da configurare e gestire.
  • Utilizzo migliore dei server back-end - L'elaborazione SSL/TLS richiede un utilizzo intensivo della CPU, che aumenta con l'aumentare delle dimensioni delle chiavi. La rimozione di questa operazione dai server back-end consente loro di concentrarsi sull'operazione per cui sono più efficienti, ovvero la distribuzione di contenuti.
  • Routing intelligente - Tramite la decrittografia del traffico il gateway applicazione ha accesso al contenuto delle richieste, ad esempio intestazioni, URI e così via, e può usare questi dati per il routing delle richieste.
  • Gestione dei certificati - I certificati devono essere acquistati e installati solo nel gateway applicazione e non in tutti i server back-end. Questo consente di risparmiare tempo e denaro.

Per configurare la terminazione TLS, è necessario aggiungere un certificato TLS/SSL al listener. In questo modo il gateway applicazione può decrittografare il traffico in ingresso e crittografare il traffico di risposta al client. Il certificato fornito al gateway applicazione deve essere in formato PFX (Personal Information Exchange), che contiene sia le chiavi private che pubbliche. Gli algoritmi PFX supportati sono elencati nella funzionePFXImportCertStore.

Importante

Il certificato nel listener richiede il caricamento dell'intera catena di certificati (il certificato radice dalla CA, gli intermedi e il certificato foglia) per stabilire la catena di attendibilità.

Nota

Il gateway applicazione non offre alcuna funzionalità per creare un nuovo certificato o inviare una richiesta di certificato a un'autorità di certificazione.

Per il corretto funzionamento della connessione TLS, è necessario assicurarsi che il certificato TLS/SSL soddisfi le condizioni seguenti:

  • La data e l'ora corrente devono trovarsi all'interno dell'intervallo "Valido da" e "Valido fino a" del certificato.
  • Il "nome comune" del certificato deve corrispondere all'intestazione host nella richiesta. Se ad esempio il client effettua una richiesta a https://www.contoso.com/, il nome comune del certificato deve essere www.contoso.com.

Se si verificano errori con il nome comune del certificato back-end, vedere la guida alla risoluzione dei problemi.

Certificati supportati per la terminazione TLS

Il gateway applicazione supporta i tipi di certificati seguenti:

  • Certificato CA (autorità di certificazione): un certificato CA è un certificato digitale emesso da un'autorità di certificazione (CA)
  • Certificato EV (convalida estesa): un certificato EV è un certificato conforme alle linee guida dei certificati standard del settore. In questo modo la barra del localizzatore del browser diventa verde e viene pubblicato anche il nome della società.
  • Certificato jolly: questo certificato supporta un numero qualsiasi di sottodomini basati su *.site.com, in cui il sottodominio sostituirà *. Tuttavia, non supporta site.com, quindi, nel caso in cui gli utenti accedano al sito Web senza digitare "www", il certificato jolly non lo coprirà.
  • Certificati autofirmati: i browser client non considerano attendibili questi certificati e avvisano l'utente che il certificato del servizio virtuale non fa parte di una catena attendibile. I certificati autofirmati sono utili per i test o gli ambienti in cui gli amministratori controllano i client e possono ignorare in modo sicuro gli avvisi di sicurezza del browser. I carichi di lavoro di produzione non devono mai usare certificati autofirmati.

Per altre informazioni, vedere Configurare la terminazione TLS con il gateway applicazione.

Dimensioni del certificato

Per informazioni sulle dimensioni massime supportate per i certificati TLS/SSL, vedere la sezione Limiti del gateway applicazione.

Crittografia TLS end-to-end

È possibile che si vogliano evitare comunicazioni non crittografate con i server back-end, per soddisfare requisiti di sicurezza o di conformità specifici o perché l'applicazione può accettare solo connessioni sicure. Il gateway applicazione di Azure include la crittografia TLS end-to-end per supportare questi requisiti.

TLS end-to-end consente di crittografare e trasmettere in modo sicuro i dati sensibili al back-end mentre si usano le funzionalità di bilanciamento del carico di livello 7 del gateway applicazione. Queste funzionalità includono l'affinità di sessione basata su cookie, il routing basato su URL, il supporto per il routing basato su siti, la possibilità di riscrivere o inserire intestazioni X-Forwarded-* e così via.

Se configurato con la modalità di comunicazione TLS end-to-end, il gateway applicazione termina le sessioni TLS nel gateway ed esegue la decrittografia del traffico utente. Applica quindi le regole configurate per selezionare un'istanza del pool di back-end adeguata su cui instradare il traffico. Il gateway applicazione avvia a questo punto una nuova connessione TLS al server back-end e crittografa nuovamente i dati usando il certificato di chiave pubblica del server back-end prima di trasmettere la richiesta al back-end. Eventuali risposte dal server Web subiscono lo stesso processo in ritorno verso l'utente finale. Per abilitare TLS end-to-end si imposta la configurazione del protocollo nell'impostazione HTTP di back-end su HTTPS. Questa impostazione viene quindi applicata a un pool back-end.

Nei gateway SKU del gateway applicazione v1, i criteri TLS applicano la versione TLS solo al traffico front-end e alle crittografie definite sia alle destinazioni front-end che back-end. Nei gateway SKU del gateway applicazione v2, i criteri TLS si applicano solo al traffico front-end, le connessioni TLS back-end verranno sempre negoziate tramite TLS 1.0 alle versioni di TLS 1.2.

Il gateway applicazione comunica solo con i server back-end che hanno autorizzato il proprio certificato ad essere nell’elenco riconosciuto dal gateway applicazione o i cui certificati sono firmati da autorità CA note e il nome comune del certificato corrisponde al nome host nelle impostazioni back-end HTTP. Questi includono i servizi di Azure attendibili, come Servizio app di Azure/App Web e Gestione API di Azure.

Se i certificati dei membri nel pool back-end non sono firmati da autorità CA note, ogni istanza del pool back-end con TLS end-to-end abilitata deve essere configurata con un certificato per consentire la comunicazione sicura. L'aggiunta del certificato garantisce che il gateway applicazione comunichi solo con istanze back-end note. proteggendo ulteriormente la comunicazione end-to-end.

Nota

Il certificato aggiunto all'impostazione HTTP di back-end per autenticare i server back-end può essere lo stesso del certificato aggiunto al listener per la terminazione TLS nel gateway applicazione o diverso per maggiore sicurezza.

end to end TLS scenario

In questo esempio, le richieste che usano TLS1.2 vengono instradate ai server back-end in Pool1 con TLS end-to-end.

TLS end-to-end e consentire l'elenco dei certificati

Il gateway applicazione comunica solo con i server back-end che hanno autorizzato il proprio certificato ad essere nell’elenco riconosciuto dal gateway applicazione o i cui certificati sono firmati da autorità CA note e il nome comune del certificato corrisponde al nome host nelle impostazioni back-end HTTP. Esistono alcune differenze nel processo di configurazione di TLS end-to-end a seconda della versione del gateway applicazione usata. La sezione seguente illustra le versioni singolarmente.

TLS end-to-end con lo SKU v1

Per abilitare TLS end-to-end con i server back-end e in modo che il gateway applicazione instradi le richieste a tali server, i probe di integrità devono avere esito positivo e restituire una risposta di integrità.

Per i probe di integrità HTTPS, lo SKU v1 del gateway applicazione usa una corrispondenza esatta del certificato di autenticazione (chiave pubblica del certificato del server back-end e non del certificato radice) da caricare nelle impostazioni HTTP.

Sono quindi consentite solo le connessioni ai back-end noti e consentiti. I backend rimanenti sono considerati non integri dai probe di integrità. I certificati autofirmati vengono usati a scopo di test e non sono consigliati per i carichi di lavoro. Questi certificati devono essere aggiunti all'elenco dei consentiti nel gateway applicazione, come descritto nei passaggi precedenti, prima di poter essere usati.

Nota

L'autenticazione e la configurazione del certificato radice attendibile non sono necessarie per i servizi di Azure attendibili, ad esempio il servizio app di Azure. Vengono considerati attendibili per impostazione predefinita.

TLS end-to-end con lo SKU v2

I certificati di autenticazione sono stati deprecati e sostituiti da certificati radice attendibili nello SKU v2 gateway applicazione. Funzionano in modo analogo ai certificati di autenticazione con alcune differenze principali:

  • I certificati firmati da autorità CA note il cui CN corrisponde al nome host nelle impostazioni back-end HTTP non richiedono alcun passaggio aggiuntivo per il funzionamento di TLS end-to-end.

    Ad esempio, se i certificati di back-end sono rilasciati da un'autorità di certificazione nota il cui nome comune è contoso.com e anche il campo host delle impostazioni HTTP di back-end è impostato su contoso.com, non sono necessarie altre operazioni. Se si configura il protocollo HTTPS nell'impostazione HTTP di back-end, sia il probe di integrità che il percorso dei dati saranno abilitati per TLS. Se si usano Servizio app di Azure o altri servizi Web di Azure come back-end, anche questi sono considerati implicitamente attendibili e non sono necessari altri passaggi per TLS end-to-end.

Nota

Affinché un certificato TLS/SSL venga considerato attendibile, tale certificato del server back-end deve essere stato emesso da un'autorità di certificazione nota. Se il certificato non è stato emesso da un'autorità di certificazione attendibile, il gateway applicazione verificherà quindi se il certificato della CA emittente è stato emesso da una CA attendibile e così via fino a quando non viene rilevata una CA attendibile (e a questo punto viene stabilita una connessione sicura attendibile) o non è possibile trovare una CA attendibile (e a questo punto il gateway applicazione contrassegna il back-end come non integro). È quindi consigliabile che il certificato del server back-end contenga sia la CA radice che le CA intermedie.

  • Se il certificato del server back-end è autofirmato o firmato da autorità di certificazione/intermediari sconosciuti, per abilitare TLS end-to-end nel gateway applicazione v2 è necessario caricare un certificato radice attendibile. Il gateway applicazione comunicherà solo con back-end il cui certificato radice del certificato del server corrisponde a uno dei certificati dell'elenco dei certificati radice attendibili nell'impostazione HTTP di back-end associata al pool.

  • Oltre alla corrispondenza del certificato radice, il gateway applicazione v2 verifica anche se l'impostazione Host specificata nell'impostazione HTTP di back-end corrisponde a quella del nome comune presentata dal certificato TLS/SSL del server back-end. Quando si tenta di stabilire una connessione TLS al back-end, il gateway applicazione v2 imposta l'estensione Indicazione nome server (SNI) sull'host specificato nell'impostazione HTTP di back-end.

  • Se si sceglie selezionare il nome host dal target back-end invece del campo Host nell'impostazione http back-end, l'intestazione SNI viene sempre impostata sul nome di dominio completo del pool back-end e il nome di dominio completo del server back-end TLS/SSL deve corrispondere al nome di dominio completo. I membri del pool di back-end con indirizzi IP non sono supportati in questo scenario.

  • Il certificato radice è un certificato radice con codifica base64 dai certificati del server back-end.

Differenze di SNI per gli SKU v1 e v2

Come indicato in precedenza, il gateway applicazione termina il traffico TLS dal client nel listener del gateway applicazione (o connessione front-end), decrittografa il traffico, applica le regole necessarie per determinare il server back-end a cui deve essere inoltrata la richiesta e stabilisce una nuova sessione TLS con il server back-end (o connessione back-end).

Le tabelle seguenti illustrano le differenze di SNI tra lo SKU v1 e v2 in termini di connessioni front-end e back-end.

Connessione TLS front-end (dal client al gateway applicazione)

Scenario v1 v2
Se il client specifica l'intestazione SNI e tutti i listener multisito sono abilitati con il flag "Require SNI" (Richiedi SNI) Il certificato appropriato viene restituito e se il sito non esiste (in base al server_name), la connessione viene reimpostata. Il certificato appropriato viene restituito, se disponibile, in caso contrario, restituisce il certificato del primo listener HTTPS in base all'ordine specificato dalle regole di routing delle richieste associate ai listener HTTPS
Se il client non specifica un'intestazione SNI e se tutte le intestazioni multisito sono abilitate con "Require SNI" (Richiedi SNI) Reimposta la connessione Il certificato del primo listener HTTPS viene restituito in base all'ordine specificato dalle regole di routing delle richieste associate ai listener HTTPS
Se il client non specifica l'intestazione SNI e se è configurato un listener di base con un certificato Restituisce il certificato configurato nel listener di base al client (certificato predefinito o di fallback) Il certificato configurato nel listener di base viene restituito

Suggerimento

Il flag SNI può essere configurato con PowerShell o usando un modello di Resource Manager. Per altre informazioni, vedere RequireServerNameIndication e Avvio rapido: Indirizzare il traffico Web con il gateway applicazione di Azure - Modello di Resource Manager.

Connessione TLS back-end (gateway applicazione al server back-end)

Per il traffico probe

Scenario v1 v2
Intestazione SNI (server_name) durante l'handshake TLS come FQDN Imposta come FQDN dal pool back-end. In base a RFC 6066, gli indirizzi letterali IPv4 e IPv6 non sono consentiti nel nome host SNI.
Nota: il nome di dominio completo nel pool back-end deve risolvere il DNS nell'indirizzo IP del server back-end (pubblico o privato)		 L'intestazione SNI (server_name) è impostata come nome host dal probe personalizzato associato alle impostazioni HTTP (se configurato) oppure dal nome host indicato nelle impostazioni HTTP oppure dal nome di dominio completo indicato nel pool back-end. L'ordine di precedenza è il probe personalizzato > impostazioni HTTP > del pool back-end.
Nota: Se i nomi host configurati nelle impostazioni HTTP e il probe personalizzato sono diversi, in base alla precedenza, SNI verrà impostato come nome host dal probe personalizzato.
Se l'indirizzo del pool back-end è un indirizzo IP (v1) o se il nome host del probe personalizzato è configurato come indirizzo IP (v2) SNI (server_name) non verrà impostato.
Nota: In questo caso, il server back-end deve essere in grado di restituire un certificato di fallback predefinito e deve essere nell’elenco delle impostazioni HTTP come certificato di autenticazione. Se nel server back-end non sono configurati certificati predefiniti/di fallback ed è previsto SNI, il server potrebbe reimpostare la connessione con conseguenti errori di probe		 Nell'ordine di precedenza sopra indicato, in presenza di un indirizzo IP come nome host, l'indicazione SNI non verrà impostata come da RFC 6066.
Nota: L’Indicazione nome server non verrà impostata neanche nei probe v2 se non è configurato alcun probe personalizzato e non viene impostato alcun nome host nelle impostazioni HTTP o nel pool back-end

Nota

Se non è configurato un probe personalizzato, il gateway applicazione invia un probe predefinito nel formato <protocollo>://127.0.0.1:<porta>/. Un probe HTTPS predefinito, ad esempio, verrà inviato come https://127.0.0.1:443/. Si noti che la versione 127.0.0.1 indicata qui viene usata solo come intestazione host HTTP e, in base a RFC 6066, non verrà usata come intestazione SNI. Per altre informazioni sugli errori relativi ai probe di integrità, vedere la guida alla risoluzione dei problemi di integrità di back-end.

Per il traffico in tempo reale

Scenario v1 v2
Intestazione SNI (server_name) durante l'handshake TLS come FQDN Imposta come FQDN dal pool back-end. In base a RFC 6066, gli indirizzi letterali IPv4 e IPv6 non sono consentiti nel nome host SNI.
Nota: il nome di dominio completo nel pool back-end deve risolvere il DNS nell'indirizzo IP del server back-end (pubblico o privato)		 L'intestazione SNI (server_name) viene impostata come nome host dalle impostazioni HTTP; in caso contrario, se l'opzione PickHostnameFromBackendAddress viene scelta o se non viene menzionato alcun nome host, quest’ultimo verrà impostato come nome di dominio completo nella configurazione del pool back-end
Se l'indirizzo del pool back-end è un indirizzo IP o un nome host non è impostato nelle impostazioni HTTP SNI non verrà impostato in base a RFC 6066 se la voce del pool back-end non è un nome di dominio completo L'indicazione SNI verrà impostata come nome host dal nome di dominio completo di input dal client e il CN del certificato back-end deve corrispondere a questo nome host.
Il nome host non viene fornito in Impostazioni HTTP, ma un nome di dominio completo viene specificato come destinazione per un membro del pool back-end L'indicazione SNI verrà impostata come nome host dal nome di dominio completo di input dal client e il CN del certificato back-end deve corrispondere a questo nome host. L'indicazione SNI verrà impostata come nome host dal nome di dominio completo di input dal client e il CN del certificato back-end deve corrispondere a questo nome host.

Passaggi successivi

Dopo avere appreso i concetti di TLS end-to-end, passare a Configurare TLS end-to-end usando un gateway applicazione con PowerShell per creare un gateway applicazione usando TLS end-to-end.