L'essenza di "TLS false start" è che, alla fine di un normale handshake TLS, ciascuna parte invia un messaggio Finished al peer e deve attendere dal Finished di quel peer prima di inviare i dati dell'applicazione . "False start" rimuove "dovrebbe aspettare". Ciascuna parte può quindi inviare i dati dell'applicazione immediatamente. Ciò implica una latenza inferiore se la parte che invia il Finished per prima è anche quella che invierà prima i dati applicativi.
Si noti che esistono due tipi di handshake TLS, le strette di mano "complete" e "abbreviate". Quest'ultimo viene utilizzato per "riprendere" una sessione TLS, vale a dire per ricalcolare una nuova chiave di sessione su una chiave master già scambiata; la stretta di mano abbreviata utilizza solo la crittografia simmetrica e richiede meno scambi di rete. Un punto che vale la pena notare è che in una stretta di mano completa, il client invia per primo il suo messaggio Finished , mentre in una stretta di mano abbreviata, il server invia il suo messaggio Finished per primo.
Nel contesto di HTTPS e siti Web, il client (un browser Web) avvia normalmente un singolo handshake TLS completo. Quindi il client può anche aprire alcune altre connessioni parallele, questa volta usando strette di mano abbreviate. Ogni connessione verrà utilizzata per inviare diverse richieste HTTP. Se si interrompe una connessione, il browser ne aprirà uno nuovo usando ancora una volta una stretta di mano abbreviata. Poiché HTTPS è HTTP-in-TLS e HTTP inizia con una richiesta dal client , l'ottimizzazione "false start" produce miglioramenti solo per la prima richiesta HTTP all'interno della primissima connessione TLS al server . Questo non è davvero un pranzo gratis, piuttosto un aperitivo gratuito, al massimo.
Crittograficamente parlando, ciò che accade con false start è che il client accetta di inviare i suoi dati (la richiesta HTTP) prima di avere la conferma che ha realmente parlato con il vero server: a quel punto, dal punto di vista del client, il server è implicitamente autenticato . I dati applicativi sono crittografati con una chiave di sessione derivata da uno scambio di chiavi che utilizzava la chiave pubblica del server autenticato (quella del certificato del server), quindi non vi è alcun rischio reale che un aggressore che impersona l'identità possa ottenere informazioni in questo modo, almeno fino a quando l'algoritmo di scambio delle chiavi e l'algoritmo di crittografia simmetrica sono sicuri. Tuttavia, il client non ha alcuna prova, quando invia la sua richiesta, che il server previsto è realmente a conoscenza del tentativo di connessione. Questo è innocuo nel contesto di HTTPS . Sarebbe coraggioso presumere che non ci sia alcun danno genericamente .