CDN SSL/TLS | Sicurezza CDN

CDN strategies for mitigating vulnerabilities include proper SSL/TLS encryption and specialized encryption hardware.

Obiettivi di apprendimento

Dopo aver letto questo articolo sarai in grado di:

  • Scopri come funziona CDN SSL/TLS
  • Scopri le ottimizzazioni CDN per SSL/TLS
  • Vedi in che modo una CDN può migliorare un certificato SSL/TLS obsoleto
  • Scopri come una CDN può contribuire a mitigare gli attacchi DDoS

Argomenti correlati


Vuoi saperne di più?

Ricevi un riepilogo mensile degli approfondimenti Internet più popolari!

Fai riferimento all'Informativa sulla privacy di Cloudflare per scoprire come raccogliamo ed elaboriamo i tuoi dati personali.

Copia link dell'articolo

Quali sono i rischi per la sicurezza per una CDN?

Like all networks exposed to the Internet, CDNs must guard against on-path attacks, data breaches, and attempts to overwhelm the network of the targeted origin server using DDoS attacks. A CDN can have multiple strategies for mitigating vulnerabilities including proper SSL/TLS encryption and specialized encryption hardware.

Cos'è la crittografia SSL/TLS?

Transport Layer Security (TLS) is a protocol for encrypting data that is sent over the Internet. TLS grew out of Secure Sockets Layer (SSL), the first widely-adopted web encryption protocol, in order to fix most of the earlier protocol’s security flaws. The industry still uses the terms somewhat interchangeably for historical reasons. Any website that you visit starting with https:// rather than http:// is using TLS/SSL for communication between a browser and a server.

Proper encryption practices are a necessity in order to prevent attackers from accessing important data. Because the Internet is designed in such a way that data is transferred across many locations, it is possible to intercept packets of important information as they move across the globe. Through the utilization of a cryptographic protocol, only the intended recipient is able to decode and read the information and intermediaries are prevented from decoding the contents of the transferred data.

Il protocollo TLS è progettato per fornire 3 componenti:

  1. Autenticazione: la possibilità di verificare la validità delle identità fornite
  2. Crittografia: la capacità di offuscare le informazioni inviate da un host ad un altro
  3. Integrità: la possibilità di rilevare falsificazione e manomissione

What is an SSL certificate?

Per utilizzare il TLS, un sito ha bisogno di un certificato SSL e della chiave corrispondente. I certificati sono file che contengono informazioni sul proprietario di un sito e la metà pubblica di una coppia di chiavi asimmetrica. Un'autorità di certificazione (CA) firma digitalmente il certificato per verificare che le informazioni in esso contenute siano corrette. Riconoscendo l'attendibilità del certificato, si ha fiducia che l'autorità di certificazione abbia eseguito la sua due diligence.

Grafica di errore SSL/TLS

I sistemi operativi e i browser in genere dispongono di un elenco di autorità di certificazione che ritengono implicitamente attendibili. Se un sito Web presenta un certificato firmato da un'autorità di certificazione non attendibile, il browser avvisa il visitatore che potrebbe esserci qualcosa sotto.

I certificati e il modo in cui vengono implementati possono anche essere valutati indipendentemente in base alla resistenza, al supporto del protocollo e ad altre caratteristiche. Le valutazioni possono cambiare nel tempo, a misura che implementazioni più recenti o migliorate diventano disponibili, o che altri fattori determinano una riduzione nella sicurezza complessiva di un'implementazione di certificazione. Se un server di origine ha un'implementazione di sicurezza SSL di livello inferiore più datata, in genere verrà valutato peggio e potrebbe essere vulnerabile a compromissioni.

Una rete CDN presenta il vantaggio aggiunto di fornire protezione ai visitatori delle proprietà ospitate all'interno della propria rete utilizzando un certificato fornito dalla CDN. Poiché i visitatori si connettono solo alla CDN, un certificato precedente o meno sicuro in uso tra il server di origine e la CDN non influirà sull'esperienza del cliente.

Diagramma autofirmato SSL/TLS

In realtà, questa sicurezza più debole tra server e perimetro rappresenta comunque una vulnerabilità e dovrebbe essere evitata, a maggior ragione considerata la facilità con cui è possibile aggiornare la sicurezza di un server di origine tramite la crittografia di origine gratuita.

Diagramma autofirmato SSL/TLS

Una sicurezza adeguata è importante anche ai fini della ricerca organica; le proprietà Web crittografate si traducono in un ranking migliore nelle ricerche di Google.

Una connessione SSL/TLS funziona in modo diverso rispetto a una tradizionale connessione TCP/IP. Una volta eseguite le fasi iniziali della connessione TCP, si verifica uno scambio separato per impostare la connessione sicura. Questo articolo farà riferimento al dispositivo che richiede la connessione sicura come "client" e al dispositivo che serve la connessione sicura come "server", come nel caso di un utente che carichi una pagina Web crittografata con SSL/TLS.

Per prima cosa, l'handshake TCP/IP viene eseguito in 3 passaggi:

  1. Il client invia un pacchetto SYN al server per avviare la connessione.
  2. Il server risponde a questo pacchetto iniziale con un pacchetto SYN/ACK attraverso il quale conferma esplicitamente la comunicazione.
  3. Infine, il client restituisce un pacchetto ACK per confermare a sua volta la ricezione del pacchetto dal server. Dopo aver completato questa sequenza di invio e ricezione di pacchetti, la connessione TCP è aperta e in grado di inviare e ricevere dati.
Diagramma del processo a tre vie dell'handshake TCP

Una volta avvenuto l'handshake TCP/IP, ha inizio l'handshake di crittografia TLS. I processi dettagliati che sottendono all'implementazione di un handshake TLS esulano dall'ambito di questa guida. Ci concentreremo invece sullo scopo principale dell'handshake e sul tempo necessario per completare il processo.

A livello generale, sono tre i componenti principali di un handshake TLS:

  1. Il client e il server negoziano le versioni TLS e il tipo di codice crittografico da utilizzare nella comunicazione.
  2. Il client e il server adottano misure per garantire una comunicazione reciprocamente autentica.
  3. Viene scambiata una chiave da utilizzare nelle comunicazioni crittografate future.

Nel seguente diagramma vengono visualizzate le rispettive fasi di un handshake TCP/IP e di un handshake TLS. Si tenga presente che ogni freccia rappresenta una comunicazione separata che deve spostarsi fisicamente tra il client e il server. Poiché il numero totale di messaggi ricevuti e inviati aumenta quando si utilizza la crittografia TLS, i tempi di caricamento delle pagine Web aumentano a loro volta.

Diagramma dell'handshake SSL/TLS

A scopo illustrativo si può affermare che l'handshake TCP richiede circa 50 ms, mentre l'handshake TLS potrebbe richiedere circa 110 ms. Ciò è dovuto in gran parte al tempo necessario per l'invio dei dati in entrambe le direzioni tra client e server. Il concetto di round-trip time (RTT), ovvero la quantità di tempo necessaria alle informazioni per viaggiare da un dispositivo all'altro e viceversa, può essere impiegato per quantificare quanto sia "costosa" la creazione di una connessione. Se non ottimizzato e senza l'utilizzo di una rete CDN, l'ulteriore RTT rappresenta per gli utenti finali un aumento della latenza e una riduzione del tempo di caricamento. Per fortuna si possono implementare delle ottimizzazioni per migliorare il tempo di caricamento totale e ridurre il numero di viaggi in entrambe le direzioni.

Come può essere migliorata la latenza SSL?

Le ottimizzazioni SSL possono ridurre il RTT e migliorare il tempo di caricamento della pagina. Ecco tre dei modi in cui si può ottimizzare una connessione TLS:

Ripresa della sessione TLS: una CDN può mantenere attiva la connessione tra il server di origine e la rete CDN più a lungo riprendendo la stessa sessione per ulteriori richieste. Mantenere attiva la connessione consente di risparmiare il tempo dedicato alla rinegoziazione della connessione tra la CDN e il server di origine quando il client richiede un recupero origine non memorizzato nella cache. A condizione che il server di origine riceva ulteriori richieste mentre viene mantenuta la connessione alla CDN, gli altri visitatori del sito sperimenteranno una latenza inferiore.

Infografica sulla ripresa della sessione in tempo reale

Il costo complessivo di una ripresa della sessione è inferiore al 50% di un handshake TLS completo, principalmente perché la ripresa della sessione costa solo un roundtrip, mentre un handshake completo TLS ne richiede due. Inoltre, la ripresa di una sessione non richiede un'aritmetica del campo finito di grandi dimensioni (come le nuove sessioni), per cui il costo della CPU per il client è quasi trascurabile rispetto a quello di un handshake TLS completo. Per gli utenti di dispositivi mobili, il miglioramento delle prestazioni dovuto alla ripresa della sessione si traduce in un'esperienza di navigazione molto più reattiva e di qualità superiore.

Infografica sui tempi di ripresa della sessione per la CPU

Attivazione di TLS False Start: se un visitatore sta visualizzando il sito per la prima volta, la ripresa della sessione menzionata sopra non sarà di aiuto. TLS False Start consente al mittente di inviare i dati dell'applicazione senza un handshake TLS completo.

Diagramma dell'handshake SSL/TLS False Start

La funzione False Start non modifica il protocollo TLS in sé, ma solo la tempistica di trasferimento dei dati. Una volta che il client avvia lo scambio di chiavi, è possibile garantire la crittografia e avviare il trasferimento dei dati. Questa modifica riduce il numero totale di roundtrip, tagliando di 60 ms la latenza richiesta.

Zero Round Trip Time Resumption (0-RTT): 0-RTT consente la ripresa della sessione senza apportare latenza RTT alla connessione. Nel caso di connessioni riprese tramite TLS 1.3 e 0-RTT, la velocità di connessione risulta migliorata, garantendo un'esperienza Web più rapida e fluida per i siti Web che gli utenti visitano regolarmente. Questo potenziamento della velocità è particolarmente evidente sulle reti mobili.

0-RTT is an effective improvement, but is not without some security tradeoffs. To overcome the risk of what is known as a replay attack, a CDN service may implement restriction on the type of HTTP requests and the allowed parameters. To learn more, explore an introduction to 0-RTT.

CDN protection from DDoS attacks

Una delle vulnerabilità di sicurezza più significative delle proprietà Web nell'Internet moderno è rappresentata dall'impiego di attacchi DDoS (Distributed Denial of Service). Nel tempo gli attacchi DDoS sono aumentati in termini di dimensioni e complessità, con aggressori che utilizzano botnet per prendere di mira i siti Web con traffico dell'attacco. Una rete CDN di grandi dimensioni e correttamente configurata ha il potenziale vantaggio della scalabilità come fattore di protezione dagli attacchi DDoS; grazie alla presenza di un numero sufficiente di postazioni di datacenter e alle ampie capacità di larghezza di banda, una rete CDN è in grado di resistere e mitigare una quantità di traffico di attacco in ingresso che potrebbe facilmente congestionare il server di origine target.

Per proteggere una connessione TLS è possibile eseguire altri passaggi. Maggiori informazioni su Cloudflare CDN e su come proteggersi dagli attacchi TLS . Controlla il corretto utilizzo di HTTPS sul tuo sito Web nel Centro di Diagnostica Cloudflare.