Scelta delle suite di crittografia TLS / SSL: quali considerazioni ci sono?

Is there a generally accepted criteria for determining which ciphers to support, and in what order? Most importantly, why are those criteria important?

Caso 1: controlli entrambi gli estremi della comunicazione.

1.a. (mi dispiace di ripetere parte della tua domanda ma non hai altra scelta che) Utilizzare i componenti della suite più alti supportati dal software scelto.
 1.b. Se ciò non soddisfa le tue esigenze, crea la tua implementazione di un componente suite che non è ancora implementato, ma che è stato pubblicato e sottoposto a peer-review in ambiente accademico.
 1.c. Se ancora non soddisfa le tue esigenze, crea il tuo nuovo algoritmo e attendi che venga sottoposto a peer-review prima di implementarlo.

Caso 2.1: Non controlli il peer, ma hai bisogno di scambiare informazioni nelle sue condizioni (ad esempio, stai visitando un sito web, diciamo il tuo conto bancario online)

Accetta la combinazione più alta che il peer offre. Cerca online ogni dettaglio / debolezza dell'algoritmo e valuta quali sono le tue perdite se / quando la tua comunicazione è compromessa. Monitora costantemente i cambiamenti nell'offerta di pari.

Se ritieni che queste perdite non siano accettabili, trova i mezzi alternativi per scambiare informazioni (ad esempio, vai in banca)

Caso 2.2: non controlli il peer, ma desideri raggiungere un pubblico previsto (ad esempio stai vendendo account openvpn)

Monitora costantemente i progressi nella crittografia e offri sempre le suite più alte disponibili.
Monitorare costantemente la suite esistente in caso di debolezza (ad esempio, sottoscrivere gli avvisi relativi al software utilizzato e gli algoritmi implementati) e quando viene pubblicata una nuova vulnerabilità, valutare in che modo influisce sul numero di destinatari previsti (supponendo che si lascino cadere i vulnerabili le suite sapendo che così facendo potrebbero ridurre il pubblico)

Per riassumere tutti e tre i casi, il criterio più strong è:
In che misura una perdita o un'alterazione delle informazioni che scambio mi colpisce, i miei amici, la mia azienda o il mio / i partner / i commerciale e quanto mi interessa?

Presumably, some ciphers are tougher to crack than others. Some are faster than others. Some may have other perks or considerations I don't even know about. Are there resources for figuring this out without getting a graduate degree in cryptanalysis?

Rimani aggiornato con gli attuali suite di crittografia elenca e scegli sempre il più alto disponibile. Tieni d'occhio, ad esempio, ciò che la NSA raccomanda per il loro uso interno . Una vista estesa della risposta di @ bonsaiviking collegata nel primo commento della tua domanda è dettagliata su Blog di sicurezza online di Google

@costin offre buoni consigli nel suo commento.

Questo è un argomento profondo in cui qualsiasi "risposta rapida" tralascia, per necessità, dettagli importanti per il tuo particolare caso d'uso. Ecco perché vedi molti consigli sulle forme che citi (ad esempio, troppo generico "usa cifrari forti" o troppo specifico "incolla questa stringa" senza spiegazioni).

Detto questo, offrirò la mia risposta incompleta da un punto di vista abbastanza semplice e pratico. ; -)

Per le app Web pubbliche, in cui non controlli la connessione dell'utente finale, disattiva SSL 3.0 e versioni precedenti : vedi la mitigazione dell'attacco POODLE recente vedi POODLE PDF .

Ci sono alcuni punti deboli accademici anche in TLS 1.0, ma potrebbe essere il migliore che alcuni browser possano gestire. Tuttavia, la maggior parte delle raccomandazioni consiglia di andare alle versioni successive di TLS, se possibile.

Qualche tempo fa, RC4 è stato consigliato come mitigazione dell'attacco BEAST, ma ha i suoi punti deboli noti e tale consiglio ora è considerato non aggiornato.

Un'intera classe di "attacchi di oracle padding" è stata lanciata contro varie suite Chained-Block-Cipher (CBC), quindi in generale anche quelle non vanno bene.

L'RFC 4492 definisce Elliptic Curve Ciphers (ECC) e TLS può utilizzare Elliptic Curve Diffie-Hellman (ECDH) che sembra stia guadagnando popolarità.

Sì, ci sono trade-off di velocità / forza / memoria / prestazioni con cifre che potresti dover gestire se esegui un'applicazione web ad alto volume per un'azienda, ma per molti siti web a server singolo, questo tipo di i trade-off non ci entrano realmente.

Consigli pratici: Un buon punto di partenza per un semplice controllo dello stato è quello di analizzare il server con SSLlabs e correggere qualsiasi cosa per cui ti segnano. No, non è perfetto, né sostituirà una buona conoscenza dei compromessi di sicurezza che ti potrebbero essere richiesti, ma ti renderà più sicuro (in senso pratico) rispetto alla maggior parte degli altri siti là fuori.