CDN SSL/TLS | CDN security

Le strategie CDN per mitigare le vulnerabilità includono una crittografia SSL/TLS adeguata e un hardware di crittografia specializzato. Esplora la guida alla CDN.

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

Copia link dell'articolo

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 aggressori 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

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.

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

For illustrative purposes it can be said the TCP handshake takes about 50ms, the TLS handshake may take about 110ms. This is largely a result of the time it takes for data to be sent both ways between the client and server. The idea of round-trip time (RTT), which is the amount of time it takes for information to travel from one device to another and back again, can be used to quantify how “expensive” a connection is to create. If left unoptimized and without the use of a CDN, additional RTT represents an increase in latency and a reduction in load time for end-users. Luckily, there are optimizations that can be made to improve total load time and reduce the number of trips back and forth.

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

The overall cost of a session resumption is less than 50% of a full TLS handshake, mainly because session resumption only costs one round-trip while a full TLS handshake requires two. Additionally, a session resumption does not require any large finite field arithmetic (new sessions do), so the CPU cost for the client is almost negligible compared to that in a full TLS handshake. For mobile users, the performance improvement by session resumption means a much more reactive and battery-life-friendly surfing experience.

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 è 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

One of the most substantial security vulnerabilities of web properties on the modern Internet is the use of distributed denial-of-service (DDoS) attacks. Over time DDoS attacks have increased in size and complexity, with attackers utilizing botnets to target websites with attack traffic. A large and properly configured CDN has the potential benefit of scale as a protective factor against DDoS; by having enough data center locations and sizable bandwidth capabilities, a CDN is able to withstand and mitigate an amount of incoming attack traffic that would easily overwhelm the targeted origin server.

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.