Alcuni attacchi (ad esempio BEAST, CRIME) sono efficaci solo contro HTTPS.
Ci sono suite di crittografia che sono "buone" solo quando sono in uso su HTTPS?
C'è qualche "buona" suite di crittografia HTTPS (cioè ChaCha20-Poly1305, AES-GCM, ..) che non è "buona" per altri protocolli come IMAP, SMTP, SSH, ecc.?
Some attacks (e.g. BEAST, CRIME) are only effective against HTTPS.
Non proprio. I problemi di base dei cipher o dell'uso della compressione non sono specifici di HTTPS, solo alcune caratteristiche di HTTP hanno permesso di sfruttare questi problemi perché è stato possibile aggiungere il testo in chiaro alla crittografia, ecc. Si potrebbero trovare exploit per altri protocolli che sono basati sulle stesse idee.
Is there any "good" HTTPS cipher suites (i.e. ChaCha20-Poly1305, AES-GCM, ..) which is not "good" for other protocols like IMAP, SMTP, SSH, etc.?
In base a ciò che ho scritto sopra, la domanda non sarebbe se sono validi codici per HTTPS che sono negativi per altri protocolli. Invece si potrebbe chiedere se si tratta di algoritmi con problemi noti, in cui questi problemi non possono essere sfruttati da HTTPS ma possono essere sfruttati con altri protocolli. Poiché i tipici metodi di attacco come il testo in chiaro scelto sono probabilmente più facili da fare con HTTPS che con altri protocolli, direi che i cifrari sicuri per HTTPS sono probabilmente sicuri anche per altri protocolli, almeno per i protocolli comuni che hai citato.
Ma potresti anche chiedere se puoi costruire un protocollo in un modo, che anche la protezione offerta da buoni codici può essere elusa. Sono abbastanza sicuro che tu possa farlo e potrebbero esserci protocolli o applicazioni là fuori che lo fanno. Ma questo non è il problema della cifratura o di TLS, ma dell'uso. Controlla Analisi dei tempi delle sequenze di tasti e degli attacchi a tempo su SSH o So perché sei andato in clinica: Rischi e realizzazione dell'analisi del traffico HTTPS per esempi su quale tipo di analisi si potrebbe fare anche se le cifre stesse vanno bene. E potresti sicuramente progettare protocolli in un modo che rende questo tipo di analisi del canale laterale ancora più semplice (ma anche che lo rende più difficile).
È stato affermato che un client di posta elettronica, che utilizza il protocollo POP3 su SSL, si ricollegherà regolarmente e invierà la password di autenticazione in un punto prevedibile all'interno del flusso, vicino all'inizio. Pertanto, se viene utilizzata una suite di crittografia basata su RC4, un attaccante passivo può semplicemente osservare e attendere, in modo che i piccoli bias noti di RC4 rivelino gradualmente la password. In questo senso, POP3-over-SSL (con autenticazione basata su password di base) sarebbe particolarmente vulnerabile alla scelta di una suite di crittografia basata su RC4, più di HTTPS a causa delle specificità del protocollo (con HTTPS, anche in situazioni dove i client si ricollegano ripetutamente a un determinato server, i "segreti interessanti" come i cookie HTTP sono più in basso nell'intestazione HTTP, dove i bias RC4 non sono così grandi).
Come spiega @Steffen, i problemi noti con alcuni pacchetti di crittografia e versioni di protocollo in SSL / TLS non sono specifici in HTTPS; ma HTTPS significa Web e Web significa browser Web e browser Web significa Javascript e Javascript significa "codice potenzialmente ostile sul lato client", aprendo l'area molto ricca di attacchi di testo normale adattati . Sui protocolli in cui i client non eseguono regolarmente il codice fornito dall'attentatore stesso, lo sfruttamento delle vulnerabilità è più difficile.
(Si noti che SSH non è basato su SSL e il concetto di "suite di crittografia" non si applica immediatamente ad esso.)
Leggi altre domande sui tag tls