¿Es confiable la seguridad TLS para el servidor web o sufre una falla de diseño importante?

0

Las mejores prácticas en términos de seguridad para la web son aplicadas por actores importantes como Google o Mozilla, pero se siente un poco como si algo estuviera desordenado en el diseño global.

Para mitigar a todos los usuarios intermedios y otros tipos de ataques a SSL / TLS, se han creado muchos nuevos protocolos y prácticas como:

  • grapado OCSP
  • No use comodines utilice certificados multidominio
  • No utilice este conjunto de cifrado ya que es demasiado antiguo (todavía es muy difícil de romper pero es demasiado viejo)
  • aumentar DHGroup
  • ponga un registro DNSCAA en su DNS
  • y la lista puede continuar

¿Estas "mejoras" son el resultado de que SSL / TLS tiene defectos fundamentales?

¿Existe algún plan para reemplazar este protocolo con algo más confiable, o es que la mayoría de los problemas se basan en la implementación y todas esas mejores prácticas / RFC están ahí para mitigar posibles errores humanos?

    
pregunta Kiwy 14.02.2018 - 15:28
fuente

2 respuestas

2
  

¿Existe algún plan para reemplazar este protocolo con algo más confiable, o es que la mayoría de los problemas se basan en la implementación y todas esas mejores prácticas / RFC están ahí para mitigar posibles errores humanos?

No hay una respuesta simple aquí, así que respondería "sí y no a todo lo anterior". Hay muchos factores en juego.

¿TLS es defectuoso?

Al igual que cualquier otro protocolo (tome HTTP o HTML por ejemplo) SSL / TLS es un estándar en evolución. Como cualquier otro protocolo, evoluciona para incluir:

  • nuevas características (por ejemplo, DNS CAA u OCSP que brindan mayor seguridad)
  • mejoras de rendimiento (por ejemplo, grapado OCSP y muchas de las cosas de TLS 1.3 para mejorar la velocidad y el uso de ancho de banda)
  • nuevos casos de uso que reflejan la forma cambiante en que se construye Internet (por ejemplo, comodín frente a múltiples dominios frente a certificados múltiples en un contexto de servidor de nube con equilibrio de carga).

A diferencia de otros protocolos, TLS también necesita mantenerse al día con los aumentos en el poder de la CPU disponible para los piratas informáticos y la investigación criptográfica (tanto la investigación de nuevos algoritmos como la investigación sobre cómo romper los algoritmos existentes). Es por eso que se agregan nuevos cifrados, se eliminan los antiguos y aumenta gradualmente el tamaño de las claves.

No diría que TLS tiene fallas, sino que, al igual que con cualquier otro software, TLS está mejorando con el tiempo para reflejar el cambio de Internet.

Errores de implementación

Tiene razón al señalar que la mayoría de las vulnerabilidades notorias en TLS no se deben a un problema con la especificación de TLS, sino a los programadores que no siguen esa especificación correctamente. Dos ejemplos vienen a la mente:

Extracción de sus Ps y Qs

[Documento]

El problema aquí es (principalmente) con dispositivos integrados pequeños (piense en enrutadores domésticos o cámaras web con acceso a Internet) que necesitan generar claves de servidor TLS en el primer arranque. Resulta que todos estos dispositivos salen de fábrica casi idénticos, lo que significa que las claves que generan en el primer arranque no son muy aleatorias.

Esto es ciertamente una vulnerabilidad de TLS, pero no es culpa de la especificación de TLS.

ROBOT

[página principal del proyecto]

Aquí, la especificación TLS ( RFC 5246 sección 7.4.7.1 ) ofrece instrucciones muy claras. para saber cómo evitar los ataques de estilo Bleichenbacher:

As described by Klima [KPR03], these vulnerabilities can be avoided
by treating incorrectly formatted message blocks and/or mismatched
version numbers in a manner indistinguishable from correctly
formatted RSA blocks.  In other words:

  1. Generate a string R of 46 random bytes

  2. Decrypt the message to recover the plaintext M

  3. If the PKCS#1 padding is not correct, or the length of message
     M is not exactly 48 bytes:
        pre_master_secret = ClientHello.client_version || R
     else If ClientHello.client_version <= TLS 1.0, and version
     number check is explicitly disabled:
        pre_master_secret = M
     else:
        pre_master_secret = ClientHello.client_version || M[2..47]

Son 3 pasos bastante sencillos. Resulta que los desarrolladores de software detrás de un gran número de implementaciones de TLS no hicieron estos pasos correctamente, lo que lleva a vulnerabilidades.

Nuevamente, la suya es ciertamente una vulnerabilidad de TLS, pero no es culpa de la especificación de TLS.

    
respondido por el Mike Ounsworth 14.02.2018 - 16:05
fuente
1
  

¿Estas "mejoras" son el resultado de que SSL / TLS tiene defectos fundamentales?

     

Grapado OCSP

El grapado OCSP es solo OCSP con mejor rendimiento y menos impacto en la privacidad. Esto no soluciona un problema en TLS per se.

  

No utilice comodines utilice certificados multidominio

No conozco esta "mejor práctica". Si se deben usar comodines o varios dominios, depende del caso de uso. No es un problema de TLS.

  

No utilice este conjunto de cifrado ya que es demasiado antiguo (todavía es muy difícil de romper pero es demasiado antiguo)

Que las computadoras se vuelvan más rápidas y obtengamos avances en la criptografía y que, por lo tanto, los sistemas de cifrado tengan un tiempo limitado donde la seguridad es normal. Esto tampoco es una falla en TLS. Por el contrario, TLS es flexible, ya que permite usar cifrados más nuevos si es necesario. Aún así, TLS 1.3 prohíbe explícitamente algunos de los cifrados más antiguos.

  

aumentar DHGroup

Lo mismo que usar cifrados actualizados.

  

ponga un registro DNSCAA en su DNS

Esto solo le permite a CA verificar si se les permite emitir certificados para el dominio específico. No soluciona un problema de TLS, pero mejora la administración de la PKI que se usa en el contexto de TLS para validar certificados.

  

y la lista puede continuar

Hasta ahora no hay problemas de TLS en sí donde se menciona. Pero en realidad hubo problemas en los antiguos estándares SSL / TLS y es por eso que tiene versiones más nuevas de TLS. Y, el desarrollo de TLS no se ha detenido, pero se están desarrollando nuevas versiones.

De nuevo, esto no significa que haya un defecto fundamental . Si este fuera el caso, abandonaríamos TLS y no continuaríamos desarrollándolo.

    
respondido por el Steffen Ullrich 14.02.2018 - 15:57
fuente

Lea otras preguntas en las etiquetas