TLS end-to-end con Frontdoor di Azure

  • Articolo

Transport Layer Security (TLS), noto in precedenza come SSL (Secure Sockets Layer), è la tecnologia di sicurezza standard per stabilire un collegamento crittografato tra un server Web e un client, come un Web browser. Questo collegamento garantisce che tutti i dati passati tra il server e il client rimangano privati e crittografati.

Per soddisfare i requisiti di sicurezza o conformità, Frontdoor di Azure supporta la crittografia TLS end-to-end. L'offload TLS/SSL di Frontdoor termina la connessione TLS, decrittografa il traffico in Frontdoor di Azure e crittografa nuovamente il traffico prima di inoltrarlo all'origine. Quando le connessioni all'origine usano l'indirizzo IP pubblico dell'origine, è consigliabile configurare HTTPS come protocollo di inoltro in Frontdoor di Azure. Usando HTTPS come protocollo di inoltro, è possibile applicare la crittografia TLS end-to-end per l'intera elaborazione della richiesta dal client all'origine. L'offload TLS/SSL è supportato anche se si distribuisce un'origine privata con Frontdoor di Azure Premium usando la funzionalità collegamento privato.

Questo articolo illustra il funzionamento di Frontdoor di Azure con le connessioni TLS. Per altre informazioni su come usare i certificati TLS con domini personalizzati, vedere HTTPS per domini personalizzati. Per informazioni su come configurare un certificato TLS nel proprio dominio personalizzato, vedere Configurare un dominio personalizzato in Frontdoor di Azure usando il portale di Azure.

Crittografia TLS end-to-end

TLS end-to-end consente di proteggere i dati sensibili durante il transito all'origine, sfruttando al tempo stesso le funzionalità di Frontdoor di Azure, come il bilanciamento del carico globale e la memorizzazione nella cache. Alcune delle funzionalità includono anche il routing basato su URL, la suddivisione TCP, la memorizzazione nella cache nella posizione perimetrale più vicina ai client e la personalizzazione delle richieste HTTP nella rete perimetrale.

Frontdoor di Azure esegue l'offload delle sessioni TLS al perimetro e decrittografa le richieste client. Applica quindi le regole di routing configurate per instradare le richieste all'origine appropriata nel gruppo di origine. Frontdoor di Azure avvia quindi una nuova connessione TLS all'origine e crittografa nuovamente tutti i dati usando il certificato dell'origine prima di trasmettere la richiesta all'origine. Qualsiasi risposta dall'origine viene crittografata tramite lo stesso processo all'utente finale. È possibile configurare Frontdoor di Azure per l'uso di HTTPS come protocollo di inoltro per abilitare TLS end-to-end.

Versioni di TLS supportate

Frontdoor di Azure supporta quattro versioni del protocollo TLS: TLS versioni 1.0, 1.1, 1.2 e 1.3. Tutti i profili Frontdoor di Azure creati dopo settembre 2019 usano TLS 1.2 come minimo predefinito con TLS 1.3 abilitato, ma TLS 1.0 e TLS 1.1 sono ancora supportati per la compatibilità con le versioni precedenti.

Anche se Frontdoor di Azure supporta TLS 1.2, che ha introdotto l'autenticazione client/reciproca in RFC 5246, attualmente Frontdoor di Azure non supporta ancora l'autenticazione client/reciproca (mTLS).

È possibile configurare la versione minima di TLS in Frontdoor di Azure nelle impostazioni HTTPS del dominio personalizzato usando il portale di Azure o l'API REST di Azure. Attualmente è possibile scegliere tra 1.0 e 1.2. Di conseguenza, specificando TLS 1.2 come versione minima controlla la versione minima accettabile di Frontdoor di Azure per TLS accettata da un client. Per la versione minima di TLS 1.2, la negoziazione tenterà di stabilire TLS 1.3 e quindi TLS 1.2, mentre per la versione minima di TLS 1.0 verranno tentate tutte e quattro le versioni. Quando Frontdoor di Azure avvia il traffico TLS verso l'origine, tenterà di negoziare la versione TLS migliore che l'origine può accettare in modo affidabile e coerente. Le versioni TLS supportate per le connessioni di origine sono TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3.

Nota

  • I client con TLS 1.3 abilitato sono necessari per supportare una delle curve EC conformi a Microsoft SDL, tra cui Secp384r1, Secp256r1 e Secp521, per effettuare correttamente richieste con Frontdoor di Azure con TLS 1.3.
  • È consigliabile che i client usino una di queste curve come curva preferita durante le richieste per evitare un aumento della latenza di handshake TLS, che può comportare più round trip per negoziare la curva EC supportata.

Certificati supportati

Quando si crea il certificato TLS/SSL, è necessario creare una catena di certificati completa con un'autorità di certificazione (CA) consentita che fa parte dell'elenco ca attendibile Microsoft. Se si usa una CA non consentita, la richiesta verrà rifiutata.

I certificati provenienti da autorità di certificazione interne o certificati autofirmati non sono consentiti.

Associazione OCSP (Online Certificate Status Protocol)

L'associazione OCSP è supportata per impostazione predefinita in Frontdoor di Azure e non è necessaria alcuna configurazione.

Connessione TLS di origine (Frontdoor di Azure all'origine)

Per le connessioni HTTPS, Frontdoor di Azure prevede che l'origine presenti un certificato da un'autorità di certificazione (CA) valida con un nome soggetto corrispondente al nome host di origine. Ad esempio, se il nome host di origine è impostato su myapp-centralus.contosonews.net e il certificato presentato dall'origine durante l'handshake TLS non ha myapp-centralus.contosonews.net o *.contosonews.net nel nome soggetto, Frontdoor di Azure rifiuta la connessione e il client rileva un errore.

Nota

Il certificato deve avere una catena di certificati completa con certificati foglia e intermedi. La CA radice deve far parte dell'elenco ca attendibile Microsoft. Se viene presentato un certificato senza catena completa, le richieste che implicano che il certificato non funzionerà come previsto.

In alcuni casi d'uso, ad esempio per i test, come soluzione alternativa per risolvere l'errore di connessione HTTPS, è possibile disabilitare il controllo del nome soggetto del certificato per la frontdoor di Azure. Si noti che l'origine deve comunque presentare un certificato con una catena attendibile valida, ma non deve corrispondere al nome host di origine.

In Frontdoor di Azure Standard e Premium è possibile configurare un'origine per disabilitare il controllo del nome soggetto del certificato.

In Frontdoor di Azure (versione classica) è possibile disabilitare il controllo del nome soggetto del certificato modificando le impostazioni di Frontdoor di Azure nella portale di Azure. È anche possibile configurare il controllo usando le impostazioni del pool back-end nelle API frontdoor di Azure.

Nota

Dal punto di vista della sicurezza, Microsoft non consiglia di disabilitare il controllo del nome soggetto del certificato.

Connessione TLS front-end (da client a Frontdoor di Azure)

Per abilitare il protocollo HTTPS per la distribuzione sicura dei contenuti in un dominio personalizzato di Frontdoor di Azure, è possibile scegliere di usare un certificato gestito da Frontdoor di Azure o usare il proprio certificato.

Per altre informazioni, vedere HTTPS per domini personalizzati.

Il certificato gestito di Frontdoor di Azure fornisce un certificato TLS/SSL standard tramite DigiCert e viene archiviato nell'insieme di credenziali delle chiavi di Frontdoor di Azure.

Se si sceglie di usare un certificato personalizzato, è possibile eseguire l'onboarding di un certificato da una CA supportata che può essere un certificato TLS standard, un certificato di convalida estesa o anche un certificato con caratteri jolly. I certificati autofirmati non sono supportati. Informazioni su come abilitare HTTPS per un dominio personalizzato.

Autorotazione del certificato

Per l'opzione Del certificato gestito di Frontdoor di Azure, i certificati vengono gestiti e ruota automaticamente entro 90 giorni dalla frontdoor di Azure. Per l'opzione Del certificato gestito Standard/Premium di Frontdoor di Azure, i certificati vengono gestiti e ruota automaticamente entro 45 giorni di scadenza da Frontdoor di Azure. Se si usa un certificato gestito di Frontdoor di Azure e si noterà che la data di scadenza del certificato è inferiore a 60 giorni o 30 giorni per lo SKU Standard/Premium, inviare un ticket di supporto.

Per il proprio certificato TLS/SSL personalizzato:

  1. Impostare la versione privata su "Latest" per il certificato da ruotare automaticamente alla versione più recente quando è disponibile una versione più recente del certificato nell'insieme di credenziali delle chiavi. Per i certificati personalizzati, il certificato viene ruotato automaticamente entro 3-4 giorni con una versione più recente del certificato, indipendentemente dall'ora di scadenza del certificato.

  2. Se è selezionata una versione specifica, l'autorotazione non è supportata. Sarà necessario selezionare nuovamente la nuova versione manualmente per ruotare il certificato. La distribuzione della nuova versione del certificato/segreto richiede fino a 24 ore.

    Nota

    I certificati gestiti di Frontdoor di Azure (Standard e Premium) vengono ruotati automaticamente se il record CNAME del dominio punta direttamente a un endpoint frontdoor o punta indirettamente a un endpoint Gestione traffico. In caso contrario, è necessario convalidare nuovamente la proprietà del dominio per ruotare i certificati.

    È necessario assicurarsi che l'entità servizio per Frontdoor abbia accesso all'insieme di credenziali delle chiavi. Vedere come concedere l'accesso all'insieme di credenziali delle chiavi. L'operazione di implementazione del certificato aggiornata da Frontdoor di Azure non causa tempi di inattività di produzione, purché il nome soggetto o il nome alternativo del soggetto (SAN) per il certificato non sia stato modificato.

Pacchetti di crittografia supportati

Per TLS 1.2/1.3 sono supportati i pacchetti di crittografia seguenti:

  • TLS_AES_256_GCM_SHA384 (solo TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (solo TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Nota

Per Windows 10 e versioni successive, ti consigliamo di abilitare una o entrambe le suite di crittografia ECDHE_GCM per una maggiore sicurezza. Windows 8.1, 8 e 7 non sono compatibili con queste suite di crittografia ECDHE_GCM. I pacchetti di crittografia ECDHE_CBC e DHE sono stati forniti per garantire la compatibilità con tali sistemi operativi.

Quando si usano domini personalizzati con TLS 1.0 e 1.1 abilitato, sono supportati i pacchetti di crittografia seguenti:

  • TLS_AES_256_GCM_SHA384 (solo TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (solo TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Frontdoor di Azure non supporta la disabilitazione o la configurazione di pacchetti di crittografia specifici per il profilo.

Passaggi successivi