Cosa devo sapere prima di configurare Perfect Forward Secrecy?

PFS in SSL implica che il server esegua, per ogni nuova sessione, uno scambio di chiavi Diffie-Hellman e una firma, quindi il costo della CPU dell'handshake sul server è circa raddoppiato rispetto a suite di crittografia non PFS. Ma è piuttosto infrequente che il costo della CPU della stretta di mano non sia trascurabile (i client che aprono diverse connessioni utilizzano l'abbreviazione di handshake che utilizza solo la crittografia simmetrica e un PC di base ha abbastanza potenza per gestire diverse centinaia di handshake al secondo con una singola CPU nucleo). Suggerisco di fare un punto di riferimento nel contesto.

Ancora con SSL, non esiste una suite di cifratura PFS che supporti anche la crittografia RC4. A parte questo, tutti i browser Web non arcaelogici attualmente implementati accetteranno le suite di crittografia "DHE" (che generano PFS) quindi non vi è alcun problema di interoperabilità qui; la domanda è piuttosto se vuoi RC4 o no: devi bilanciare la paura di un ulteriore compromesso chiave (contro cui PFS aggiunge una certa protezione) con la paura degli attacchi cifratici scelti (cioè BEAST, a cui le suite di crittografia RC4 sembrano immuni).

Il sistema operativo o il servizio di bilanciamento del carico potrebbe riportare statistiche sulle suite di crittografia, ma non ci scommetterei su di esso. Puoi eseguire test con OpenSSL (l'eseguibile della riga di comando, con il comando s_client ). Puoi anche utilizzare qualsiasi analizzatore di protocollo decente come Wireshark , che può dirti quale suite di cifratura viene utilizzata su una determinata connessione (l'identificatore della suite di cifratura viene inviato "in chiaro" come parte dei primi passi della stretta di mano, quindi è facile afferrarlo con uno sniffer).

L'interoperabilità era un problema in passato, in particolare in ipsec. SSL è un po 'più semplice, ma non tutti i client lo supportano. Se volessi controllare il mio traffico, probabilmente tcpdump su una porta di span e scriverò uno script per cercare la suite di crittografia accettata nell'handshake, supponendo che stiamo parlando di SSL.

What pitfalls or common mistakes should I be aware of before implementing this? Anything administrative, implementation-specific, or platform-specific? A few that spring to mind.

Esistono due algoritmi di scambio delle chiavi utilizzati nel TLS per il segreto di inoltro. DHE e ECDHE. Per ottenere la segretezza con la più ampia gamma di clienti, è necessario supportare entrambi. In generale, dovresti prefferedare ECDHE rispetto a DHE perché funziona meglio e per compatibilità con Java 7 (vedi sotto).

L'obbligo di rendere obbligatorio il segreto escluderà Internet Explorer (qualsiasi versione) su Windows XP. Mi aspetto che lo stesso sia vero per tutto ciò che usa le finestre costruite nello stack SSL / TLS su XP.

Per DHE è necessario assicurarsi di utilizzare forti parametri dh. È necessario utilizzare i parametri dh generati personalizzati con almeno un bit prime di 2048 (la sicurezza di un dh prime è paragonabile a una chiave RSA della stessa lunghezza).

Java 6 e 7 si interrompono se si negozia una crittografia DHE e si utilizzano parametri DH superiori a 1024 bit. Questo è un problema particolarmente acuto con java 6 in quanto non supporta ECDHE.

Prior to making PFS mandatory on our server, I would like to account for and prepare for the incompatibilities.

Un'opzione potrebbe essere quella di rendere prefissate le cifrarie in cifratura in avanti, ma non obbligatorie e configurare il server per registrare ciò che ciphersuite è usato per ciascuna connessione. È quindi possibile esaminare i registri e determinare quanti clienti si perderebbero se si inoltrava la segretezza.

Are there misconceptions regarding what PFS can and can't do? Could our Audit department need a reality check?

Fondamentalmente ciò che la segretezza avanzata fa è impedire a qualcuno che ha rubato la chiave di utilizzarlo per decifrare il traffico passivamente. In particolare, senza segreto d'ufficio, qualcuno che ha monitorato e archiviato il tuo traffico e in seguito ruba la tua chiave può tornare indietro e decrittografare il traffico che hanno precedentemente acquisito.

Ciò che la segretezza non farà è impedire a qualcuno che ha rubato la chiave di usarlo per impersonare te (e agire come un uomo nel mezzo o sostituire il tuo server con il loro).

La segretezza non ti aiuterà se la crittografia simmetrica è interrotta. La crittografia utilizzata per lo scambio di chiavi di segretezza potrebbe anche essere interrotta (vedere il commento sui parametri dh precedenti).

Are the benefits of PFS limited by application? (web vs smtp, etc)

I vantaggi sono gli stessi, ma è probabile che il supporto nei client non sia così comune.