SSL/TLS è il protocollo crittografico più utilizzato su internet. Tecnicamente, TLS è il successore di SSL, anche se i termini vengono talvolta utilizzati 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 bilanciatore del carico. 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.
Questa pagina illustra i certificati SSL e la crittografia in transito tra un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete proxy che utilizza SSL e i relativi client. Per maggiori dettagli sulla crittografia in transito tra il bilanciatore del carico Google Cloud e i relativi backend, consulta Crittografia dei backend.
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 uno 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.
| Bilanciatore del carico | Metodo di configurazione del certificato | |||
|---|---|---|---|---|
| Certificati SSL di Compute Engine | Certificate Manager (mappa dei certificati) | Certificate Manager (certificati individuali) | ||
| Bilanciatori del carico delle applicazioni (proxy HTTPS di destinazione) | ||||
| Bilanciatore del carico delle applicazioni esterno regionale |
Gestito autonomamente Gestito da Google |
Gestito autonomamente Gestito da Google |
||
| Bilanciatore del carico delle applicazioni interno regionale |
Gestito autonomamente Gestito da Google |
Gestito autonomamente Gestito da Google |
||
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, di cui esegui il provisioning e che rinnovi autonomamente. I certificati autogestiti possono essere di uno dei seguenti tipi di certificato di chiave pubblica:
- Domain Validation (DV)
- Organization Validation (OV)
- Certificati Extended Validation (EV)
Puoi creare certificati SSL autogestiti utilizzando le risorse dei certificati SSL di Compute Engine. Per saperne di più, consulta Utilizza i certificati SSL autogestiti.
Tipi di chiavi supportati
Per i certificati SSL 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
Utilizza certificati con chiavi ECDSA
Questa sezione esamina il motivo per cui consigliamo ECDSA rispetto a 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, prestazioni eccellenti per le operazioni di firma e un utilizzo efficiente della larghezza di banda della rete.
Ecco alcuni dei possibili motivi per utilizzare altri tipi di chiavi di 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 fornisce una sicurezza più elevata per unità di chiave e, in alcuni casi, una migliore efficienza computazionale rispetto a RSA.
Ad esempio:
- Una chiave ECDSA a 256 bit fornisce un livello di sicurezza simile a una chiave RSA-3072.
- Una chiave ECDSA a 384 bit offre un livello di sicurezza superiore rispetto a qualsiasi dimensione di chiave RSA ampiamente supportata.
Vantaggi principali di ECDSA:
Prestazioni: le operazioni di firma ECDSA sono molto meno intensive dal punto di vista computazionale rispetto alle operazioni RSA che forniscono un livello di sicurezza equivalente. In questo modo si riducono il carico della CPU e la latenza, il che è fondamentale per i sistemi con throughput elevato 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
La seguente procedura 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 SNI (Server Name Indication) al bilanciatore del carico nell'ambito di questa negoziazione. I dati del nome host SNI vengono talvolta 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, viene utilizzato quel certificato 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 suo
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 che non corrisponde 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 sia con gli attributi del certificato del nome comune (CN) sia con quelli del nome alternativo del soggetto (SAN). I nomi di dominio negli attributi CN e SAN devono contenere solo caratteri minuscoli. I certificati con caratteri maiuscoli nei nomi di dominio vengono restituiti solo se impostati come certificato principale nel proxy di destinazione.
Se un solo certificato corrisponde al nome host SNI, il bilanciatore del carico seleziona quel certificato. Se più certificati corrispondono al nome host SNI, il bilanciatore del carico li assegna in ordine di priorità:
Corrispondenza esatta del nome host: le corrispondenze esatte con il CN o il SAN hanno la precedenza sulle corrispondenze con caratteri jolly.
Corrispondenza del nome host con caratteri jolly: se non esiste una corrispondenza esatta, il bilanciatore del carico verifica la presenza di una corrispondenza CN o SAN con caratteri jolly. Un carattere jolly (
*) corrisponde solo al sottodominio di primo livello (ad esempio,*.pets.example.comcorrisponde acats.pets.example.comanziché a*.example.com).Tipo di chiave del certificato: i certificati ECDSA sono preferiti rispetto ai certificati RSA.
Dimensioni della catena di certificati: se più certificati hanno la stessa specificità di corrispondenza e lo stesso algoritmo di chiave pubblica, il bilanciatore del carico dà la priorità al certificato con la catena di certificati di dimensioni inferiori (in byte) per ridurre al minimo la larghezza di banda della rete durante il TLS handshake.
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
- CN:
Certificato B
- CN:
dogs.pets.example.com - SAN:
dogs.pets.example.com,*.pets.example.com,*.example.com
- CN:
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 e sia il certificato A sia il certificato B corrispondono a*.pets.example.comnell'elenco dei SAN. Se entrambi i certificati utilizzano lo stesso algoritmo di chiave pubblica, il bilanciatore del carico seleziona il certificato con la dimensione della catena di certificati più piccola. Se anche le dimensioni della catena di certificati sono identiche, il bilanciatore del carico seleziona il certificato A o il certificato B e non puoi controllare quale certificato viene selezionato.
Dopo aver selezionato un certificato, il bilanciatore del carico lo invia al client 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 di chiave pubblica (ECDSA o RSA) del certificato selezionato dal bilanciatore del carico.