¿Existe alguna solución para los problemas de seguridad en curso con ssl / tls? [cerrado]

-2

Parece que los métodos que utilizamos para garantizar el intercambio seguro de información con los servidores fallan continuamente. Dados los problemas actuales con SSL / TLS y los métodos siempre cambiantes para solucionar problemas como:

  • Fijación de clave pública HTTP: para delinear mejor la clave pública correcta por su firma.
  • Transparencia del certificado: una extensión del certificado X509
  • en desuso o eliminación de versiones de SSL y TLS
  • varias otras correcciones para otras vulnerabilidades del sistema

Parece seguro decir que la infraestructura PKI se encuentra en un mal estado de cosas (al borde del colapso) cuando parece que ni siquiera podemos decir qué certificado / clave pública es válida.

Entonces, ¿existe realmente una solución realista para los problemas actuales de SSL / TLS?

Hay mucho movimiento, pero no hay indicios de que los problemas se estén resolviendo.

    
pregunta Surly Canuck 31.05.2018 - 23:45
fuente

1 respuesta

12

TL; TR: TLS no se rompe más allá de la esperanza y no se necesita "corregir los problemas de seguridad en curso con ssl / tls" . Sin embargo, se necesitan mejoras regulares, pero también se hacen.

  

Parece que los métodos que utilizamos para garantizar el intercambio seguro de información con los servidores fallan continuamente.

"fallar continuamente" es, en mi opinión, una interpretación muy pesimista e incorrecta. El hecho es que la mayoría del uso de SSL / TLS es bastante seguro, es decir, es mucho más éxito que fracaso. Pero no es perfecto, principalmente porque el mundo de hoy es diferente de cuando se diseñó inicialmente SSL / TLS. Y a medida que el mundo está cambiando, SSL / TLS necesita adaptarse a los cambios y, por lo tanto, necesita mejoras continuas: hace años el estado de la técnica era TLS 1.0, ahora es TLS 1.2 y TLS 1.3 también está llegando.

Las mejoras en el protocolo TLS y en los cifrados utilizados se realizan generalmente antes de que surjan problemas potenciales a un problema. Si bien hubo muchos problemas en el pasado (CRIMEN, INCUMPLIMIENTO, POODLE ...), estos fueron simplemente ataques teóricos en ese momento, es decir, solo en un caso de uso limitado y generalmente inusual y / o necesitaron recursos considerables. Yo diría que ninguno de estos problemas causó ningún problema de seguridad en la práctica cuando se encontraron, pero podrían haber causado tales problemas más tarde si no se hubieran solucionado. Los ataques se vuelven más fáciles con el tiempo, tanto porque los ataques se mejoran como los recursos necesarios (potencia de cómputo, ancho de banda) son más fáciles y baratos de adquirir.

Al contrario de esto, los errores en las implementaciones de protocolo eran mucho más graves, es decir, cosas como Heartbleed , goto fail o la vulnerabilidad de Schannel causó problemas reales. Pero estos no eran errores en el protocolo tal como fueron diseñados, sino errores en la implementación.

En cuanto a los problemas con la validación de certificados: en realidad no son problemas de SSL / TLS, ya que la validación no forma parte del protocolo TLS. Sin embargo, son problemas a tener en cuenta cuando prácticamente se usa SSL / TLS dentro de HTTPS o similar en Internet.

El problema con la validación de certificados es en realidad menos técnico, pero más humano: en quién confiar y cómo escalar la confianza y cuánto confiar. En los días iniciales de uso de HTTPS solo había unas pocas autoridades de certificación que tenían una gestión de certificados estricta. La suplantación de sitios con sus certificados no era un problema real en este momento, ya que ningún sitio realmente requiere HTTPS, es decir, el atacante simplemente podría usar HTTP si es necesario.

Hoy en día, la situación es diferente: la mayoría de los sitios importantes requieren HTTPS y, por lo tanto, atacar a las autoridades de certificación para suplantar los sitios se volvió más atractivo y se volvió real en muchos casos. Para disuadir tales ataques, se desarrollaron y emplearon mejoras como la transparencia de certificados, la fijación de certificados o la Autorización de autoridad de certificados (CAA) y también se cerraron varias autoridades de certificación con seguridad de mala calidad (es decir, ya no es de confianza para los principales navegadores). Métodos como el engrapado OCSP, OCSP debe staple , los CRLSets y el uso de certificados de corta duración pero que se actualizan automáticamente se propagaron para solucionar los crecientes problemas con los certificados robados que deben ser revocados. Por lo tanto, es lo mismo que con TLS: no se rompe más allá de la esperanza, pero hay espacio para que se realicen mejoras y se realicen mejoras.

Otro problema es que la confianza en TLS (HTTPS) se hizo más pequeña con los años, menos por problemas con las autoridades de certificación, pero más por el uso masivo de TLS: hoy en día es fácil y barato / gratis obtener certificados y Se espera en muchos casos que se utilice HTTPS. Esto significa que también los sitios de phishing obtienen certificados hoy y el malware es entregado por HTTPS. Mientras que el HTTPS en el pasado se comercializaba a menudo como una señal de que el sitio en sí está seguro, esto ya no es cierto y en realidad nunca lo fue. Los usuarios deben entender que HTTPS solo significa que el contenido está protegido durante la entrega, pero que el contenido protegido aún puede ser malicioso. Pero nuevamente, este es un problema sociológico y de usabilidad y no un problema de protocolo.

    
respondido por el Steffen Ullrich 01.06.2018 - 00:37
fuente

Lea otras preguntas en las etiquetas