Quanto sovraccarico di rete aggiunge TLS rispetto a una connessione non crittografata?

Question

(Approssimativamente) quanti più bit di dati devono essere trasferiti sulla rete durante una connessione crittografata rispetto a una connessione non crittografata?

IIUC, una volta completato l'handshake TLS, il numero di bit trasferiti è uguale a quelli trasferiti durante una connessione non crittografata. È accurato?

Come seguito, il trasferimento di un file di grandi dimensioni su https è molto più lento del trasferimento di tale file su http, dati i processori veloci e le stesse condizioni di rete (ideali)?

Answer 1

Ho ricevuto questa domanda un paio di volte, quindi ho deciso di scrivere una piccola spiegazione del sovraccarico con alcuni numeri di esempio basati su un caso comune. Puoi leggerlo sul mio blog allo http://netsekure.org/2010/03/tls-overhead/.

Riassunto dal post sul blog:

• L'overhead totale di stabilire una nuova sessione TLS viene a circa 6.5K byte in media.
• L'overhead totale per riprendere una sessione TLS esistente arriva a circa 330 byte in media.
• Il sovraccarico totale dei dati crittografati è di circa 40 byte.

Answer 2

Un ordine di grandezza. Vedi this. Questo non è troppo significativo, se l'informazione che è protetta merita di essere protetta. E ricorda che le velocità del processore possono solo aumentare, quindi le prestazioni continueranno a migliorare.

Answer 3

La risposta breve è: Il tuo Milage può variare (YMMV) - tutto dipende dal tuo schema di traffico. Ci sono una serie di fattori da tenere in considerazione:

• Le strette di mano e certs aggiuntivi aggiungerà 4-6KB al flusso TCP, questo si tradurrà in più frame Ethernet in corso attraverso il filo così
• Clienti dovrebbe scaricare il certificate revocation list. Alcuni strumenti come cURL omettono questo passaggio. Il browser può essere memorizzato nella cache dal browser, tuttavia, di solito non ha un associato di vecchia data. Verisign imposta la loro scadenza dopo quattro minuti. Nei miei test, vedo Safari su Windows che scarica lo stesso file 91KB due volte.
• TLS Session resumption può evitare la parte di scambio di chiavi pubblica dell'handshake, nonché la verifica del certificato.
• HTTP keep-alives manterrà il socket aperto, come http, ma ha più risparmi quando il socket è TLS.
• SSL compression il supporto sta iniziando a mostrare lato server, ma AFAIK, la maggior parte dei browser non sta ancora implementando questo. Inoltre, se stai già effettuando la compressione a livello http, non ci sarà molto da guadagnare qui. Potrebbero essere ottenuti guadagni potenzialmente grandi se il client invia grandi quantità di testo al server, che normalmente non è compresso a livello http.

Answer 4

Sull'overhead calcolato in http://netsekure.org/2010/03/tls-overhead/, pensi di aver ignorato il vettore di inizializzazione (IV) per AES in modalità CBC? poiché è AES128, penso che 16 byte di IV debbano essere aggiunti al sovraccarico, rendendo il totale di 56 invece di 40 byte.