Elección de conjuntos de cifrado TLS / SSL: ¿qué consideraciones existen?

  

¿Existe un criterio generalmente aceptado para determinar qué cifrados se deben admitir y en qué orden? Lo más importante, ¿por qué son importantes esos criterios?

Caso 1: controla ambos extremos de la comunicación.

1.a. (lamento repetir parte de su pregunta, pero no tiene más remedio que) Use los componentes más altos de la suite que son compatibles con su software elegido.
 1.b. Si eso no satisface sus necesidades, cree su propia implementación de un componente de la suite que aún no se ha implementado pero que se publica y se revisa en el entorno académico.
 1.c. Si eso todavía no satisface sus necesidades, invente su nuevo algoritmo y espere a que sea revisado por pares antes de implementarlo.

Caso 2.1: usted no controla al par, pero necesita un intercambio de información bajo sus condiciones (por ejemplo, está visitando un sitio web, digamos su cuenta bancaria en línea)

Acepta la combinación más alta que el par está ofreciendo. Busque en línea los detalles / debilidades de cada algoritmo y evalúe cuáles son sus pérdidas si / cuando su comunicación se ve comprometida. Supervisar constantemente los cambios en la oferta de compañeros.

Si considera que estas pérdidas son inaceptables, busque medios alternativos para intercambiar información (por ejemplo, vaya a la oficina del banco)

Caso 2.2: no controlas al interlocutor, pero deseas llegar a un público específico (por ejemplo, estás vendiendo cuentas abiertas)

Supervise constantemente el progreso de la criptografía y siempre ofrezca las suites más altas disponibles.
Supervise constantemente la debilidad de la suite existente (por ejemplo, suscríbase a las alertas relacionadas con el software que utiliza y los algoritmos que se implementan) y cuando se publique una nueva debilidad, evalúe cómo afecta eso a la cantidad de audiencia prevista (suponiendo que eliminará la vulnerabilidad) suites sabiendo que al hacer esto reducirá potencialmente la audiencia)

Para resumir los tres casos, el criterio más sólido es:
En qué grado me afecta a mí, a mis amigos, a mi empresa o a mi (s) socio (s) empresarial (es) una filtración o alteración de la información que intercambio y cuánto ¿Me importa?

  

Presumiblemente, algunos cifrados son más difíciles de romper que otros. Algunos son más rápidos que otros. Algunos pueden tener otros beneficios o consideraciones que ni siquiera conozco. ¿Hay recursos para resolver esto sin obtener un título de posgrado en criptoanálisis?

Solo manténgase al día con los actuales conjuntos de cifrado Listar y elegir siempre la más alta disponible. Observe, por ejemplo, lo que NSA recomienda para su uso interno . Una vista ampliada de la respuesta de @bonsaiviking vinculada en el primer comentario de su pregunta se detalla en Blog de seguridad en línea de Google

@costin ofrece buenos consejos en su comentario.

Este es un tema profundo en el que cualquier "respuesta rápida" omitirá, por necesidad, detalles importantes para su caso de uso particular. Es por eso que ve muchos consejos sobre los formularios que cita (por ejemplo, "utilice cifrados fuertes" o demasiado específicos "pegue esta cadena" sin explicaciones).

Dicho esto, ofreceré mi propia respuesta incompleta desde un punto de vista bastante básico y práctico. ;-)

Para las aplicaciones web públicas, en las que no controla la conexión del usuario final, deshabilite SSL 3.0 e inferior : vea la reciente mitigación de ataques de POODLE vea POODLE PDF .

También hay algunas debilidades académicas en TLS 1.0, pero puede ser la mejor que pueden manejar algunos navegadores. Aún así, la mayoría de las recomendaciones dicen ir a versiones posteriores de TLS si puedes.

Hace un tiempo, se recomendó RC4 como mitigación del ataque BEAST, pero tiene sus debilidades conocidas, y ese consejo ahora también se considera obsoleto.

Se ha lanzado toda una clase de "ataques de relleno de Oracle" contra varias suites de cifrado en bloque (CBC), por lo que, en general, también están fuera de favor.

RFC 4492 define Cifras de curva elíptica (ECC) y TLS puede usar la curva Diffie-Hellman (ECDH) de curva elíptica que parece estar ganando popularidad.

Sí, existen compensaciones de velocidad / fuerza / memoria / rendimiento con sistemas de cifrado con las que puede tener que lidiar si ejecuta una aplicación web de gran volumen para una empresa, pero para muchos sitios web de un solo servidor, ese tipo de Las concesiones realmente no entran en ella.

Consejos prácticos: Un buen punto de partida para un simple chequeo de salud es analizar su servidor con SSLlabs y corregir cualquier cosa que lo marque. No, no es perfecto, ni reemplazará un buen conocimiento de las compensaciones de seguridad que se le puede pedir que haga, pero lo hará más seguro (en un sentido práctico) que la mayoría de los otros sitios disponibles.