¿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.