Panoramica dei certificati SSL

SSL/TLS è il protocollo crittografico più utilizzato su internet. Tecnicamente, TLS è il successore di SSL, anche se i termini vengono a volte usati in modo intercambiabile, come in questo documento.

Transport Layer Security (TLS) viene utilizzato per criptare le informazioni durante l'invio su una rete, garantendo la privacy tra un client e un server o un load balancer. Un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete proxy che utilizza SSL richiede almeno una chiave privata e un certificato SSL.

Metodo di configurazione del certificato

Per i bilanciatori del carico delle applicazioni che utilizzano proxy HTTPS di destinazione, il proxy di destinazione del bilanciatore del carico deve fare riferimento a un numero compreso tra 1 e 15 certificati SSL di Compute Engine. Ogni risorsa del certificato SSL di Compute Engine contiene la chiave privata, il certificato corrispondente e, facoltativamente, i certificati CA.

Supporto del bilanciatore del carico

La tabella seguente mostra i metodi di configurazione dei certificati supportati da ciascun bilanciatore del carico.

Tipi di certificati

Puoi creare certificati SSL autogestiti per i tuoi bilanciatori del carico.

Certificati SSL autogestiti

I certificati SSL autogestiti sono certificati che ottieni, esegui il provisioning e rinnovi personalmente. I certificati autogestiti possono essere di uno dei seguenti tipi di certificato di chiave pubblica:

• Convalida del dominio (DV)
• Convalida dell'organizzazione (OV)
• Certificati Extended Validation (EV)

Puoi creare certificati SSL autogestiti utilizzando le risorse dei certificati SSL di Compute Engine. Per ulteriori informazioni, vedi Utilizzare i certificati SSL autogestiti.

Tipi di chiavi supportati

Per i certificati SSL di Compute Engine autogestiti a livello di regione sono supportati i seguenti tipi di chiavi:

• RSA-2048
• RSA-3072
• RSA-4096
• ECDSA P-256
• ECDSA P-384

Utilizzare certificati con chiavi ECDSA

Questa sezione esamina perché consigliamo ECDSA anziché RSA come best practice per le chiavi di firma dei certificati.

Quale tipo di chiave utilizzare

ECDSA P-256 è il tipo di chiave consigliato per la maggior parte dei certificati TLS, in quanto offre una solida sicurezza crittografica, oltre a prestazioni eccellenti per le operazioni di firma e un uso efficiente della larghezza di banda di rete.

Di seguito sono riportati alcuni dei possibili motivi per utilizzare altri tipi di chiavi del certificato:

• Se devi supportare client legacy che non supportano i certificati ECDSA, puoi fornire certificati RSA-2048 oltre ai certificati ECDSA P-256.
• Se hai requisiti di conformità specifici che richiedono l'utilizzo di chiavi di dimensioni maggiori o di tipi di chiavi particolari, puoi utilizzare le chiavi ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Perché scegliere ECDSA anziché RSA

Il vantaggio principale di ECDSA risiede nella sua capacità di fornire un livello di sicurezza crittografica equivalente con chiavi significativamente più piccole rispetto a RSA. Questa efficienza si traduce in vantaggi tangibili in termini di prestazioni e risorse. Una chiave più piccola non implica una sicurezza più debole: ECDSA si basa sul problema del logaritmo discreto della curva ellittica, che offre una maggiore sicurezza per unità di chiave e, in alcuni casi, una migliore efficienza computazionale rispetto a RSA.

Ad esempio:

• Una chiave ECDSA a 256 bit offre un livello di sicurezza simile a una chiave RSA-3072.
• Una chiave ECDSA a 384 bit offre un livello di sicurezza maggiore rispetto a qualsiasi dimensione della chiave RSA ampiamente supportata.

Vantaggi principali di ECDSA:

• Prestazioni: le operazioni di firma ECDSA sono significativamente meno intensive dal punto di vista computazionale rispetto alle operazioni RSA, fornendo un livello di sicurezza equivalente. Ciò riduce il carico della CPU e la latenza, il che è fondamentale per i sistemi ad alta velocità effettiva o sensibili alla latenza.

• Efficienza: chiavi e firme più piccole richiedono meno larghezza di banda e spazio di archiviazione, il che è particolarmente vantaggioso per gli ambienti con risorse limitate come i dispositivi mobili e IoT.

Più certificati SSL

Il proxy di destinazione di un bilanciatore del carico delle applicazioni può fare riferimento a un massimo di 15 certificati SSL di Compute Engine. La prima risorsa del certificato SSL di Compute Engine a cui viene fatto riferimento è il certificato predefinito (principale) per il proxy di destinazione.

Per saperne di più, consulta Proxy di destinazione e Certificati SSL nella documentazione sul bilanciamento del carico.

Procedura di selezione dei certificati

Il seguente processo di selezione dei certificati si applica ai bilanciatori del carico i cui proxy di destinazione fanno riferimento a più certificati SSL di Compute Engine.

Dopo che un client si connette al bilanciatore del carico, il client e il bilanciatore del carico negoziano una sessione TLS. Durante la negoziazione della sessione TLS, il client invia al bilanciatore del carico un elenco di crittografie TLS supportate (in ClientHello). Il bilanciatore del carico seleziona un certificato il cui algoritmo di chiave pubblica è compatibile con il client. Il client può anche inviare un nome host di indicazione nome server (SNI) al bilanciatore del carico nell'ambito di questa negoziazione. A volte i dati del nome host SNI vengono utilizzati per aiutare il bilanciatore del carico a scegliere il certificato da inviare al client.

• Se il proxy di destinazione del bilanciatore del carico fa riferimento a un solo certificato, questo viene utilizzato e il valore del nome host SNI inviato dal client non è pertinente.

• Se il proxy di destinazione del bilanciatore del carico fa riferimento a due o più certificati, il bilanciatore del carico utilizza la seguente procedura per selezionare un singolo certificato:

  • Se il client non ha inviato alcun nome host SNI nel ClientHello, il bilanciatore del carico utilizza il primo certificato nell'elenco dei certificati.

  • Se il client invia un nome host SNI che non corrisponde ad alcun nome comune (CN) del certificato e ad alcun nome alternativo del soggetto (SAN) del certificato, il bilanciatore del carico utilizza il primo certificato nell'elenco dei certificati.

  • In tutte le altre situazioni: il bilanciatore del carico seleziona un certificato utilizzando il seguente processo di corrispondenza:

    • La corrispondenza viene eseguita in base al suffisso più lungo rispetto agli attributi del certificato nome comune (CN) e nome alternativo del soggetto (SAN), con una preferenza per i certificati ECDSA rispetto ai certificati RSA.

    • Per illustrare il metodo di corrispondenza, considera un proxy di destinazione che fa riferimento ai seguenti due certificati:

      • Certificato A

        • CN: cats.pets.example.com
        • SAN: cats.pets.example.com, *.pets.example.com, *.example.com

      • Certificato B

        • CN: dogs.pets.example.com
        • SAN: dogs.pets.example.com, *.pets.example.com, *.example.com

    • Ora considera i seguenti scenari:

      • Se il nome host SNI inviato dal client è cats.pets.example.com, il bilanciatore del carico utilizza il certificato A.
      • Se il nome host SNI inviato dal client è ferrets.pets.example.com, non esiste una corrispondenza esatta, quindi il bilanciatore del carico seleziona il certificato A o il certificato B perché entrambi includono *.pets.example.com nel loro elenco SAN. In questa situazione non puoi controllare quale certificato viene selezionato.

• Una volta selezionato un certificato, il bilanciatore del carico invia al client il certificato solo se il certificato selezionato utilizza un algoritmo di chiave pubblica compatibile con una crittografia inviata dal client in ClientHello. La negoziazione TLS non va a buon fine se il client non supporta una suite di crittografia che include l'algoritmo della chiave pubblica (ECDSA o RSA) del certificato selezionato dal bilanciatore del carico.

Passaggi successivi

• Crittografia nei backend

• Crittografia dei dati in transito in Trusted Cloud white paper