CDN e SSL/TLS

Secure Sockets Layer (SSL) è un protocollo utilizzato per stabilire connessioni protette, in genere tra un server e un browser Web. Tutte le informazioni inviate tramite una connessione SSL sono crittografate, quindi possono essere accessibili solo dal destinatario previsto. Ciò facilita lo scambio sicuro di dati sensibili, inclusi dettagli di accesso, informazioni sulla carta di credito e contenuto e-mail, contrastando così il rischio di essere intercettati da terzi in un attacco “man-in-the-middle”.

A partire dal 2015, l’ultima versione di SSL (3.0) è stata ufficialmente deprecata. È stata sostituita da TLS (Transport Layer Security), che fornisce una crittografia più forte svolgendo al contempo una funzione simile. Tuttavia, il nome originale è rimasto; molti si riferiscono ancora a TLS come “SSL/TLS” o semplicemente “SSL”.
Introdotto per la prima volta nel 1995, SSL/TLS svolge un ruolo importante nell’evoluzione di Internet, fornendogli il fattore di fiducia necessario per fungere da luogo di lavoro. Google ha ufficialmente aggiunto TLS al suo elenco di fattori di ranking nel 2014, rafforzando ulteriormente l’importanza del protocollo e accelerandone l’adozione già ampia.

C’è molto altro da dire su SSL/TLS dal punto di vista della sicurezza e del business. In questa guida, tuttavia, ci concentreremo sugli aspetti di prestazioni e sicurezza dell’utilizzo di SSL insieme alla rete di distribuzione dei contenuti (CDN), una scelta sempre più popolare per molti proprietari di siti web.

Come una CDN può rafforzare le prestazioni SSL/TLS

Il problema: il sovraccarico dell’handshake SSL/TLS
Per capire come l’utilizzo di una CDN può migliorare le prestazioni SSL, esaminiamo prima in che modo una connessione SSL differisce dalla sua controparte TCP normale.

Una tipica connessione TCP viene stabilita tramite un processo noto come handshake a tre vie. In esso, un client invia una richiesta di connessione (SYN), riceve un riconoscimento (SYN/ACK) e quindi risponde con un proprio riconoscimento (ACK). Ciò chiude il ciclo e stabilisce la connessione. Supponendo che non ci siano intoppi, il tempo necessario per completare l’handshake dovrebbe essere esattamente uguale a un singolo round trip time (RTT).

D’altro canto, la negoziazione di una connessione SSL/TLS richiede alcuni ulteriori avanti e indietro. Questo perché il browser e il server ora devono anche:

• Concordare un metodo di crittografia reciprocamente compatibile.
• Eseguire un processo di verifica reciproca.
• Generare chiavi simmetriche, utilizzate per codificare e decodificare tutte le informazioni scambiate durante la sessione.
• Queste interazioni extra aggiungono sovraccarico al processo, con conseguenti due round trip aggiuntivi, o più, a seconda della configurazione del server.

Ad esempio

Se il tempo di andata e ritorno da San Francisco al server di Londra è di 50 ms, stabilire un handshake SSL/TLS richiederà almeno 150 ms.

Soluzione: utilizzare una CDN per ridurre Round Trip Time

Per la maggior parte, i vantaggi della sicurezza SSL superano di gran lunga lo svantaggio di tempi di connessione più lunghi. Tuttavia, il sovraccarico può essere fastidioso, motivo per cui molte aziende online utilizzano CDN per compensare parte della latenza aggiunta.

La riduzione del tempo di andata e ritorno è una funzione fondamentale di CDN, un servizio specificamente progettato per migliorare la velocità di risposta riducendo la distanza fisica tra il tuo sito Web e i suoi utenti.

Riducendo il tempo di andata e ritorno, CDN velocizza anche tutte le interazioni durante il processo di negoziazione SSL/TLS. Poiché l’handshake richiede almeno tre round trip, ottieni tre volte l’effetto per ogni millisecondo risparmiato da una CDN.

Ad esempio

Se il tempo di andata e ritorno da San Francisco al tuo server di Mlano è di 50 ms, stabilire un handshake SSL/TLS richiederà almeno 150 ms.

Tieni d’occhio il keep-alive

Nota che lo scenario descritto sopra è vero solo se il tuo CDN ha già una connessione aperta con il server di origine. Altrimenti, dopo che la prima parte della connessione SSL/TLS è in atto, il CDN deve ancora avviare un secondo processo di negoziazione. Qui, il sovraccarico SSL rimane lo stesso (o potrebbe anche essere un po’ più lungo).

Ciò che è importante qui è assicurarsi che il tuo CDN abbia una funzionalità keep-alive, definita anche connessione persistente. Con un keep-alive, un CDN mantiene una connessione aperta con il server tra diverse sessioni utente per alcuni minuti alla volta.

Ciò significa che, finché il tuo sito web viene visitato una volta ogni pochi minuti, il CDN e il server di origine non dovranno riprendere ulteriori negoziazioni SSL/TLS. Tutti i tuoi visitatori traggono vantaggio da tempi di handshake più rapidi.

Ad esempio

Dopo che la connessione SSL con il proxy di Austin è stata stabilita, in assenza di una funzionalità keep-alive, la CDN deve riaprire la connessione con il server di origine a Milano.

Il tempo di andata e ritorno tra Austin e Milano è di 30 ms, quindi ci vorranno 90 ms per negoziare la seconda connessione SSL. Ciò riporta il tempo totale di handshake a 150 ms.

Utilizzo della CDN per l’ottimizzazione immediata

Come accennato, la quantità di round trip richiesti per un handshake SSL/TLS dipende dalla configurazione del server. Ad esempio, si verificano round trip aggiuntivi quando il server non è ottimizzato per gestire record TLS di dimensioni superiori a una certa dimensione, con conseguenti interazioni avanti e indietro aggiuntive.

Inoltre, alcune configurazioni del server possono accelerare le comunicazioni SSL/TLS, tra cui:

False Start

Consente al browser di inviare dati applicativi crittografati anche prima che la negoziazione SSL sia completata.

Ripresa della sessione

Memorizza nella cache le informazioni di un visitatore e del server per ridurre i tempi di negoziazione per i visitatori abituali.

La maggior parte delle CDN moderne sono preconfigurate per comunicazioni SSL/TLS ottimizzate. Utilizzando una CDN, quindi, elimini automaticamente tutti i potenziali colli di bottiglia e trai vantaggio da prestazioni TLS ottimizzate, fin da subito.

Nota che è consigliabile rivedere anche la configurazione del server di origine. Questo serve principalmente a garantire che vengano mantenute prestazioni ottimali quando si ricollega a una CDN e apre una nuova connessione persistente.

Come le CDN possono rafforzare la sicurezza SSL/TLS

Il problema: certificati di bassa qualità e implementazioni non ottimali
Come probabilmente già saprai, le comunicazioni SSL/TLS si basano sull’esistenza di certificati SSL. Questi contengono informazioni sul tuo dominio e sulla tua organizzazione, oltre alla chiave pubblica utilizzata per avviare le comunicazioni crittografate.

Qui, è importante notare che i certificati SSL variano in termini di qualità e affidabilità.

Innanzitutto, c’è una differenza tra i certificati SSL acquistati da un’autorità di certificazione ufficiale (CA) e quelli gratuiti (autofirmati) che possono essere generati utilizzando il toolkit OpenSSL.

Dei due, un certificato CA è chiaramente un’opzione molto migliore e più affidabile, tanto che l’utilizzo di un certificato autofirmato fa sì che tutti i visitatori ricevano un messaggio allarmante ogni volta che provano ad accedere alle tue risorse HTTPS. Ciò può comportare un’enorme riduzione del traffico.

In secondo luogo, tutti i certificati SSL/TLS vengono classificati in base alla qualità della loro implementazione individuale, solitamente in base ai seguenti criteri:

• Supporto protocollo: la preferenza è data alle implementazioni che applicano i protocolli più recenti e sicuri.
• Supporto scambio chiavi: la preferenza è data alle implementazioni che utilizzano una crittografia più forte durante la codifica delle chiavi di sessione (ad esempio, parametro Diffie-Hellman a 2048 bit).
• Supporto cifratura: la preferenza è data alle implementazioni che applicano cifrature con crittografia più forte (ad esempio, 256 bit).

Poiché il tuo grado di certificato è di dominio pubblico e può essere facilmente determinato tramite SSLLabs o uno strumento simile, riflette anche l’opinione degli utenti sul tuo sito web.

Tuttavia, oltre a un impatto psicologico negativo, questo punteggio ti informa su quanto sia realmente sicura la tua implementazione SSL/TLS e quanto sia probabile che possa essere compromessa. Ovviamente quest’ultima può comportare perdite finanziarie e danni a lungo termine per il tuo marchio e la tua attività.

Soluzione: CDN per un certificato di grado A+ senza problemi

Utilizzare una CDN significa che la prima parte della tua connessione SSL/TLS viene sempre stabilita utilizzando il certificato del provider, ospitato su un proxy CDN. Ciò ha il vantaggio di ottimizzare automaticamente gli aspetti di sicurezza delle tue comunicazioni SSL.

La tua implementazione SSL potrebbe non essere ottimale e potresti utilizzare solo un certificato autofirmato gratuito. Dal momento in cui inizi a utilizzare un proxy CDN, tuttavia, tutti i tuoi visitatori saranno immediatamente protetti da un certificato di grado A+, firmato da una delle CA più affidabili al mondo.