Perché più siti Web non implementano il segreto perfetto in avanti?

In realtà la maggior parte dei siti Web fa implementa inoltro segreto , cioè almeno uno dei " DHE "(o" ECDHE ") suite di crittografia. La maggior parte delle implementazioni SSL li supporta immediatamente e la maggior parte dei certificati server SSL è adeguata (con una suite di crittografia DHE, la chiave del server viene utilizzata per una firma , ma quasi tutti usano RSA e quasi tutti i certificati RSA consentire l'uso della chiave per le firme).

Tuttavia, la maggior parte delle implementazioni SSL sono anche cortesi , in quanto il server segue le preferenze del client. Ciò significa che, nella lista delle suite di cifratura annunciate come supportate dal client (nel messaggio ClientHello ), il server di solito seleziona il primo che è anche supportato sul lato server. Poiché la maggior parte dei clienti tende a mettere le suite di crittografia non DHE per prime, le suite DHE rimangono inutilizzate.

Il costo aggiuntivo sostenuto dalle suite di crittografia DHE è lieve e quasi sempre trascurabile:

• Il costo computazionale per l'handshake è circa raddoppiato. Ciò significa che un server di base può eseguire "solo" 1000 handshake al secondo invece di 3000, in base alla CPU disponibile. Poiché i server di solito non vantano 1000 nuovi client al secondo, su un singolo PC, questa limitazione non è mai una vera limitazione nella pratica.

• La larghezza di banda extra è piccola: meno di 1 kilobyte di overhead indotto dall'uso di una suite di crittografia DHE. Anche in questo caso, questo sovraccarico è solo per una stretta di mano completa, cioè la prima connessione tra un client e un server; le connessioni successive useranno la "stretta di mano abbreviata", che è più efficiente e completamente priva di impatti dall'effettiva suite di crittografia.

Quindi, per riassumere, inoltrare la segretezza è già lì ed è sottoutilizzata solo a causa del comportamento tradizionale di client e server (ordine di preferenza) che rimane invariato per nessun motivo tecnico valido, solo inerzia . In alcuni casi, gli sviluppatori o gli amministratori di sistema disattivano il supporto DHE sulla base di alcune voci infondate su come DHE sia "molto costoso" e "potrebbe avere un strong impatto sulle prestazioni", ma questi miti vengono facilmente dissipati con alcuni benchmark effettivi e sono ancora rari. I browser e i server scelgono le suite di crittografia non DHE soprattutto perché questo è il comportamento predefinito e nessuno si sente abbastanza motivato per fare qualcosa al riguardo.

Per essere completo, è un effetto extra: quando è stato pubblicato l'attacco BEAST, le persone si sono lasciate prendere dal panico, e il mantra comune era: "usa RC4, è immune". SSL non ha una suite di crittografia DHE con RC4 (non c'è incompatibilità tra DH e RC4, ma succede che non è stata definita alcuna suite di crittografia standard). Ciò ha comportato clienti e server che preferivano suite di crittografia RC4, il che implica indirettamente non utilizzando le suite di crittografia DHE.

L'handshake DHE è molto costoso e quindi potrebbe avere un strong impatto sulle prestazioni del server. ECDHE è molto migliore (solo un sovraccarico di circa il 15% con implementazioni ottimizzate) ma è necessaria una libreria che la supporti. OpenSSL, ad es. la libreria che si trova dietro la maggior parte dei server Web basati su UNIX, ha aggiunto il supporto con 1.0.1 - e sì, questa è esattamente la versione che ha aggiunto l'estensione heartbeat che ha permesso il famoso attacco heartbleed. Quindi, se il tuo server richiede OpenSSL e vuoi usare PFS efficace ed essere immune da questo grave attacco, devi usare una versione OpenSSL vecchia di qualche giorno o correggere la tua versione.

Quindi alla fine potrebbe essere una buona cosa che molti siti web siano troppo pigri per aggiungere PFS:)

Ecco alcuni motivi per cui i siti non implementano il segreto in avanti (chiamato anche Perfect Forward Secrecy o PFS).

Per definizione, solo il server che termina TLS e il client possono decrittografare il payload effettivo. Ciò significa che altri processi, che possono avere una ragione legittima per decodificare il testo cifrato, sono esclusi dalla conversazione. Ci sono molti motivi validi per farlo, e qui ci sono alcuni esempi.

• PFS interromperà un sistema di monitoraggio della disponibilità che periodicamente tocca il traffico, lo decrittografa, controlla i codici di stato e quindi contrassegna la rete come "su" o "giù". Per questo motivo ho visto interi datacenter andare al buio.
• Gli strumenti di diagnostica, come "ssldump", non funzionano più con PFS. Supponiamo che un cliente finale dica "Inserisco il mio nome utente e la mia password, e il sistema dice che sono connesso, ma non lo sono. Cosa sta succedendo?" Con PFS, l'amministratore non può acquisire una connessione specifica e quindi decrittografarla per vedere l'HTML all'interno.
• Gli acceleratori WAN ottengono ogni chiave di sessione e quindi eseguono la deduplicazione dei dati per un intero ufficio nelle configurazioni spoke-and-hub. Gli acceleratori WAN hanno migliorato le prestazioni e ridotto la larghezza di banda. Immagina 50 persone in un ufficio del campus che si connettono al quartier generale per scaricare lo stesso file PDF da 5 Mb (ad esempio il nuovo listino prezzi). La deduplicazione significava che il PDF è stato trasferito dall'ufficio centrale esattamente una volta, e chiunque altro accedesse dal sito del campus avrebbe silenziosamente ricevuto la copia locale memorizzata nell'acceleratore WAN. PFS lo interrompe e ora il PDF deve essere trasferito 50 volte.

• I sistemi ad alta disponibilità (HA) che condividono chiavi SSL possono essere violati da PFS. Supponiamo che tu stia scaricando un file ISO di gigabyte su una connessione TLS lenta e che il server TLS si spenga improvvisamente. In un sistema HA, un altro server TLS può calcolare la chiave di sessione e può silenziosamente "prelevare" la connessione e mantenere il download in corso. PFS può rompere i sistemi HA più vecchi. Nota: i siti HA SSL sono piuttosto rari ma sono disponibili.

  Ho visto tutti gli esempi con i clienti. Sì, ci sono modi per aggirarli, ma tutti implicano un lavoro extra.

Quando un amministratore del sito o un fornitore TLS sta provando a dare la priorità a correzioni e caratteristiche, possono decidere che il vantaggio del segreto d'inoltro (che impedisce agli Stati nazionali di spionaggio) non giustifica le modifiche della rete o l'aumento della larghezza di banda in questo momento. / p>

Detto questo, se si misurano gli indirizzi IP (e non il rank di alexa) la maggior parte di Internet (50% +) supporta TLS perché sono semplici server one-box che non hanno questi requisiti più complicati.