Quando ci si connette a un sito Web HTTPS che utilizza un "certificato problematico" (ad esempio uno non emesso da una CA riconosciuta, un certificato scaduto o un certificato che non contiene il nome del server così come appare nell'URL ), il browser chiede conferma all'utente. Questo può accadere solo dopo che il certificato del server è stato recuperato, come parte di un handshake SSL. Questo rappresenta almeno una connessione iniziale con l'handshake.
Mantenere aperta una connessione SSL utilizza alcune risorse sul server; così i server chiudono automaticamente le connessioni dopo un po 'di inattività e i browser cercano di non mantenere le connessioni aperte troppo a lungo. La visualizzazione dell'avviso sul certificato non valido implica l'attesa che l'utente umano prenda una decisione (fare clic o non fare clic, questa è la domanda). Questo richiederà del tempo; gli umani sono lenti . Pertanto, il browser prima chiuderà la sua connessione SSL iniziale, quella utilizzata per ottenere il certificato del server - non ancora HTTP, ma solo l'handshake SSL. Quando l'utente umano decide di connettersi nonostante l'avviso spaventoso, il browser aprirà una nuova connessione, con un nuovo handshake SSL, e in quello ci sarà un po 'di HTTP (come "dati dell'applicazione").
Come per la altra connessione (la "connessione iniziale" è in realtà due connessioni fatte in parallelo): Chrome è noto per aprire connessioni speculative in modo da velocizzare le richieste successive; in generale, una pagina Web include immagini che dovranno essere scaricate prontamente. Chrome sembra troppo zelante a volte . Lo scenario plausibile è quindi:
- Chrome apre due connessioni con gli handshake SSL.
- Chrome rileva che il certificato è instabile e richiede l'intervento umano. Chiude le due connessioni senza fare alcun HTTP all'interno dei tunnel SSL.
- Quando l'utente decide di aprire la pagina, Chrome apre una terza connessione, esegue un handshake SSL e questa volta prosegue con la finestra di dialogo HTTP.