¿Existe una suite de cifrado que solo sea "buena" cuando se usa con HTTPS, pero no "buena" con otros protocolos?

  

Algunos ataques (por ejemplo, BEAST, CRIME) solo son efectivos contra HTTPS.

En realidad no. Los problemas subyacentes de los cifrados o del uso de la compresión no son específicos de HTTPS, solo algunas características de HTTP hicieron posible explotar estos problemas porque pudo agregar el texto sin formato elegido al cifrado, etc. Es posible que encuentre vulnerabilidades para otros protocolos que se basan en las mismas ideas.

  

¿Hay algún "buen" conjunto de cifrado HTTPS (es decir, ChaCha20-Poly1305, AES-GCM, ...) que no sea "bueno" para otros protocolos como IMAP, SMTP, SSH, etc.?

Según lo que escribí anteriormente, la pregunta no sería si hay algún cifrado bueno para HTTPS que sea malo para otros protocolos. En su lugar, puede preguntar si hay algún cifrado con problemas conocidos, donde HTTPS no puede explotar estos problemas, pero puede explotarse con otros protocolos. Dado que los métodos de ataque típicos como el texto sin formato elegido son probablemente más fáciles de hacer con HTTPS que con otros protocolos, diría que los cifrados seguros para HTTPS también son seguros para otros protocolos, al menos para los protocolos comunes que ha mencionado.

Pero también podría preguntar si podría construir un protocolo de alguna manera, que incluso la protección ofrecida por los buenos cifrados pueda ser evadida. Estoy bastante seguro de que puedes hacerlo y podría haber protocolos o aplicaciones que hagan esto. Pero este no es el problema del cifrado o de TLS, sino del uso. Echa un vistazo a Análisis de tiempo de pulsaciones y ataques de tiempo en SSH o Sé por qué fue a la clínica: Riesgos y realización del análisis de tráfico HTTPS para ver qué tipo de análisis se podría hacer, incluso si los cifrados en sí están bien. Y definitivamente podría diseñar protocolos de una manera que accidentalmente haga que este tipo de análisis de canal lateral sea aún más fácil (pero que también lo haga más difícil).

Se ha argumentado que un cliente de correo electrónico, que utiliza el protocolo POP3 sobre SSL, se volverá a conectar regularmente y enviará la contraseña de autenticación a un lugar predecible dentro del flujo, cerca del comienzo. Por lo tanto, si se usa un conjunto de cifrado basado en RC4, un atacante pasivo puede simplemente observar y esperar, de modo que los pequeños sesgos conocidos de RC4 revelan gradualmente la contraseña. En ese sentido, POP3 sobre SSL (con autenticación básica basada en contraseña) sería especialmente vulnerable a la elección de un conjunto de cifrado basado en RC4, más que a HTTPS debido a las especificidades del protocolo (con HTTPS, incluso en situaciones). donde los clientes se vuelven a conectar repetidamente a un servidor dado, los "secretos interesantes" como las cookies HTTP están más abajo en el encabezado HTTP, donde los sesgos RC4 no son tan grandes).

Como lo explica @Steffen, los problemas conocidos con algunos conjuntos de cifrado y versiones de protocolo en SSL / TLS no son específicos para HTTPS; pero HTTPS significa web, y web significa navegador web, y navegador web significa Javascript, y Javascript significa "código potencialmente hostil en el lado del cliente", abriendo el área muy rica de ataques de texto simple adaptados elegidos . En los protocolos donde los clientes no ejecutan rutinariamente el código proporcionado por el atacante, la explotación de la vulnerabilidad es más difícil.

(Tenga en cuenta que SSH no se basa en SSL, y el concepto de "conjunto de cifrado" no se aplica de inmediato a él).