A cosa serve TLS Session Resumption – Session Reuse

Introduzione

TLS Session Resumption (o session reuse) è un metodo per ridurre le chiamate tra client e web server in una connessione cifrata HTTPS. Session reuse è uno dei più importanti meccanismi per migliorare le performance di una connessione SSL.

In pratica la Session resumption è un metodo per evitare una “full TLS handshake” e lo si ottiene memorizzando due dati nascosti (chiamati Session ID e Session Ticket). Questo parametro permette di identificare l’utente che precedentemente si era collegato al webserver e viene usato quando l’utente si riconnette all’host la volta successiva. Grazie a questa scorciatoia si risparmiano molti cicli della CPU e si riduce la latenza di navigazione per l’utente finale.

Cosa vuol dire full TLS handshake?

L’handshake (che in italiano significa stretta di mano) SSL/TLS è il processo con cui si “presentano” la prima volta client e server sotto connessione HTTPS. Il processo prevede una serie di passaggi attraverso i quali entrambe le parti si convalidano a vicenda e iniziano a comunicare attraverso il tunnel SSL/TLS sicuro.

La “stretta di mano” comporta una serie di passaggi che partono dalla convalida dell’identità delle parti e si conclude con la generazione di una chiave segreta comune.

Fondamentalmente, l’handshake SSL non è altro che una conversazione tra due parti (client e server) che vogliono raggiungere lo stesso scopo: proteggere la comunicazione con l’aiuto della crittografia simmetrica.

Immagina questa handshake.

• Client: Ciao. Voglio stabilire una comunicazione sicura tra noi due. Ecco i miei cipher suits* e la versione compatibile SSL/TLS. Una cipher suite – suite di crittografia è un insieme di algoritmi che aiutano a proteggere una connessione di rete che utilizza Transport Layer Security (TLS) o Secure Socket Layer (SSL). L’insieme di algoritmi che le suite di crittografia contengono di solito include: un algoritmo di scambio di chiavi, un algoritmo di crittografia di massa e un algoritmo di codice di autenticazione dei messaggi (MAC).
• Server: Ciao Client. Ho controllato i tuoi chiper suits e la versione SSL/TLS. Possiamo procedere, ecco il mio certificato e la mia chiave pubblica. Controllali.
• Client: Fammi verificare il tuo certificato. (Dopo un po’ …) Ok, sembra a posto, ma ho bisogno di verificare la tua chiave privata. Quello che farò sarà generare e cifrare una chiave pre-master (chiave segreta condivisa) usando la tua chiave pubblica. Decifralo usando la tua chiave privata e useremo la chiave master per cifrare e decifrare le informazioni.
• Server: Fatto.
• [Ora che entrambe le parti sanno con chi stanno parlando, le informazioni trasferite tra di loro saranno protette usando la chiave principale. Tieni presente che una volta terminata la parte di verifica, la crittografia viene eseguita solo tramite la chiave master. Questa è la crittografia simmetrica.]
• Client: Ti sto inviando questo messaggio di esempio per verificare che la nostra chiave principale funzioni. Inviami la versione decrittografata di questo messaggio. Se funziona, i nostri dati sono in buone mani.
• Server: Sì, funziona. Penso che abbiamo raggiunto quello che stavamo cercando.

Come funziona un handshake

Per stabilire una connessione SSL, devono essere scambiati quattro messaggi tra client e server. Con una latenza di 50 ms ad esempio, abbiamo 200 ms di ritardo per stabilire una connessione (più la connessione TCP). Inoltre, sia client che server devono archiviare la public-key.

Cosa cambia con TLS Session Resumption

Per evitare una “full SSL handshake” ogni volta che il client richiede una risorsa, è possibile per il client richiedere una “abbreviated handshake“, guadagnando un giro completo di richieste (100 ms) ed evitando la parte più costosa di una “full SSL handshake”.

L’efficacia della Session resumption dipende da cosa viene trasmesso attraverso la connessione SSL. In questo articolo tratto il caso di un web server che invia pagine HTML.

• Il browser apre la prima connessione, con un “full handshake”.
• Il browser potrebbe aprire una o più connessioni extra, così che diverse richieste possano essere eseguite simultaneamente (caricare immagini e script ad esempio). Il numero di connessioni aperte dipende dalla versione del browser, dal sistema operativo, dalla versione del protocollo HTTP utilizzata e da altri parametri.
• Le nuove connessioni useranno la session resumption.
• Il browser proverà a mantenere le connessioni “alive” per maggior tempo possibile. Di solito il web server chiude le connessioni che sono state inattive per uno o due minuti, ma questo dipende dal tipo di server, dal carico di lavoro e dalla sua configurazione. Inoltre, il client potrebbe essere dietro ad un router che chiude le connessioni inattive con tempistiche che possono essere diverse dal server a cui si è connessi.
• Quando si apre una nuova connessione al server, il browser tenterà di utilizzare la session resumption. Il browser ricorda i parametri di sessione per ore, fino a che i suoi processi non vengono terminati (quando viene chiuso).
• Il web server in genere ricorda le sessioni SSL per un periodo variabile tra 5 e 20 minuti dopo la chiusura dell’ultima connessione. Questo valore può essere configurato.

Il risultato è che il client lancerà una nuova handshake solo quando aprirà una nuova connessione, che normalmente accade di raro, si otterranno alcune connessioni all’inizio e ogni volta che il client interagisce con il server dopo aver non interagito con il server per un minuto o due.

In condizioni normali e server tipici, solo la prima di queste handshake è una full handshake; tutte le altre sono handshake abbreviate. Quindi le nuove connessioni si verificano ad un ritmo che non è più di un paio di volte al minuto e meno se il client è “attivo” (ad esempio, fa clic più di una volta al minuto).

Rinunciando alla TLS Session Resumption si completano tutti gli handshake, con l’invio del certificato del server e la crittografia asimmetrica.

Vantaggi

Una full TLS handshake implica principalmente tre costi aggiuntivi:

• La latenza aumenta. Una full handshake implica un viaggio di andata e ritorno extra.
• La full handshake implica più traffico di rete, la maggior parte dei quali è la catena di certificati del server (ad esempio da 2 a 5 kilobyte).
• La crittografia asimmetrica coinvolta in un handshake richiede qualche risorsa in più del processore (CPU) del server. Si noti che un server quad-core da 3.1 GHz di alcuni anni fa può eseguire più di 3000 operazioni di chiave privata RSA al secondo (per una chiave a 2048 bit molto decente).

Dato che stiamo parlando di un paio di handshake al minuto e per cliente, i costi aggiuntivi della rete e della CPU sono probabilmente trascurabili (anche se dovrebbe essere misurato, come tutte le cose relative alle prestazioni). L’ulteriore latenza, però, può essere più problematica, perché fa parte di ciò che l’utente vede, e dipende da come l’utente è connesso a Internet (in particolare, le persone con accesso a Internet via satellite tendono ad avere una latenza elevata e sentire il costo di ogni round extra).

Conclusioni

Per un sito Web, l’influenza dell’utilizzo o meno della TLS Session Resumption sarà principalmente una questione di esperienza dell’utente in termini di latenza. Il parametro più importante sarà il tempo in cui il server accetta di mantenere attive le connessioni client inattive.

Poiché tutto ciò dipende molto dal modo in cui è organizzato il tuo sito, ad esempio:

• numero di immagini extra,
• CSS e script da caricare,
• se le interazioni sono per lo più nel client con Javascript o implicano attività client-server,
• quanto tempo ci si aspetta che un utente possa attendere prima di eseguire un click,
• come si comportano gli utenti (quante pagine guardano, quanto spesso tornano …)
• il carico di punta previsto (quanti utenti hanno connesso contemporaneamente),

le statistiche ottenute su siti diversi dal tuo non sono in grado di offrire una visione accurata di ciò che accadrà per te. Come ogni cosa nella SEO, prima di dire che una cosa “funziona” la devi testare per bene sul TUO sito web.