CDN SSL/TLS | Sicurezza CDN

Quali sono i rischi per la sicurezza per una CDN?

Come tutte le reti esposte a Internet, le CDN devono proteggersi da attacchi on-path, violazioni dei dati e tentativi di congestionare la rete del server di origine target attraverso attacchi DDoS. Una rete CDN può avere più strategie per mitigare le vulnerabilità, tra cui un'adeguata crittografia SSL/TLS e hardware di crittografia specializzato.

Cos'è la crittografia SSL/TLS?

Transport Layer Security (TLS) è un protocollo per la crittografia dei dati inviati tramite Internet. TLS nasce da Secure Sockets Layer (SSL), primo protocollo di crittografia Web adottato su larga scala, con l'obiettivo di correggere la maggior parte dei difetti di sicurezza del precedente protocollo. Il settore continua a utilizzare i termini quasi indistintamente per ragioni storiche. Qualsiasi sito Web visitato che cominci con https://, anziché http://, utilizza TLS/SSL per la comunicazione tra un browser e un server.

Pratiche corrette di crittografia rappresentano una necessità per impedire agli autori di attacchi di accedere a dati importanti. Poiché Internet è progettato in modo tale che i dati vengano trasferiti in molte posizioni, è possibile intercettare pacchetti con informazioni importanti man mano che si spostano in tutto il mondo. Attraverso l'utilizzo di un protocollo di crittografia, solo il destinatario designato è in grado di decodificare e leggere le informazioni, mentre agli intermediari viene impedito di decodificare il contenuto dei dati trasferiti.

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

Scopri di più sui protocolli SSL/TLS gratuiti di Cloudflare.

Cos'è un certificato SSL?

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.

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.

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.

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.

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.

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.

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.

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.

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 è un miglioramento efficace, ma non privo di alcuni compromessi in termini di sicurezza. Per evitare il rischio di ciò che è noto come "Replay Attack", un servizio CDN potrebbe implementare restrizioni sul tipo di richieste HTTP e sui parametri consentiti. Per maggiori informazioni, consulta la sezione Introduzione a 0-RTT.

Protezione CDN da tutti gli attacchi DDoS

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.