A finales del mes de marzo de este año se aprobó de manera oficial TLS 1.3, el nuevo y último estándar de seguridad, que además de una seguridad más robusta en las comunicaciones, añade también una mayor rapidez. El pasado viernes 10 de agosto se publicó de manera oficial TLS 1.3 con su RFC 8446 que lo define, en este artículo te contamos los principales cambios que tenemos al navegar por Internet con TLS 1.3.
Durante los últimos 5 años, la organización que se encarga de definir los protocolos de Internet (IETF), ha estado trabajando en la estandarización de la última versión del protocolo TLS (Transport Layer Security), en la versión TLS 1.3.
El protocolo TLS no solo se utiliza para que las comunicaciones con las páginas web bajo HTTPS tengan confidencialidad, autenticidad e integridad, sino que también usamos TLS, por ejemplo, en OpenVPN, el popular software cliente/servidor de redes privadas virtuales. Esta nueva versión de TLS 1.3 no solo brinda una mayor seguridad a los usuarios, sino también un rendimiento nunca antes visto.
Historias de terror con TLS: las vulnerabilidades
En los últimos años, investigadores de seguridad han descubierto una gran cantidad de problemas en la implementación del propio protocolo TLS en las diferentes librerías criptográficas, el más popular fue sin lugar a dudas, “Hearbleed”, pero también ha habido otros como el “goto fail”. Algunos defectos de diseño en el propio protocolo hicieron que los ataques teóricos, se convirtieran en prácticos, como WeakDH, LogJam, FREAK y SWEET32, aunque los más peligrosos fueron otros como POODLE y BEAST.
En la web de Qualys SSL Labs se pueden hacer pruebas tanto a página web, como a los navegadores web de los usuarios, permitiéndonos saber si estamos afectados o nos podrían atacar utilizando algunos de estos fallos de seguridad ya conocidos.
Hace unos años la mayoría de páginas web solo utilizaban la seguridad TLS para iniciar sesión o enviar información muy privada, como por ejemplo los datos de la tarjeta de crédito para pagar por Internet, dejando el resto de datos totalmente expuestos a que cualquier usuario malintencionado los capturase y leyese. De hecho, si no se utiliza TLS en toda la comunicación, la cookie de sesión se enviaría en claro, haciendo muy fácil la suplantación de sesión sin necesidad de conocer el usuario y la contraseña.
En los últimos años se ha realizado una mejora muy importante en la seguridad, y es que el crecimiento de HTTPS ha sido espectacular, sobre todo gracias a Google que “obliga” a las diferentes webs a adoptar HTTPS si no quieren que su posicionamiento se vea afectado. Let’s Encrypt también ha hecho mucho por el Internet seguro, ya que gracias a esta Autoridad de Certificación ya no hace falta pasar por caja y comprar un certificado SSL, sino que es completamente gratis y está reconocida esta CA por todos los navegadores web. Además de esto, también se han lanzado otros protocolos como el HSTS para proteger HTTPS de ataques como SSLstrip, además de HPKP y Certificate Transparency para los certificados SSL de las webs.
Mejoras introducidas en TLS 1.3
En el nuevo protocolo TLS 1.3 se han mejorado dos partes esenciales en la comunicación segura: la propia seguridad, y el rendimiento.
Seguridad
El protocolo TLS es un sistema híbrido, es decir, utiliza tanto la criptografía de clave simétrica, como criptográfica de clave asimétrica. Protocolos como SSH, OpenVPN, IPsec o Signal utilizan este sistema híbrido. La criptografía asimétrica o de clave pública, se usa para establecer un secreto compartido entre ambas partes, y posteriormente se utiliza la criptografía simétrica para el cifrado y descifrado de los datos entre un origen y un destino. Como regla general, la criptografía de clave pública es mucho más lenta y costosa que la criptografía de clave simétrica.
Gran parte del trabajo en TLS ha consistido en mejorar esta primera parte, el handshake, donde se utilizan las claves públicas para establecer las claves simétricas. En TLS 1.3 únicamente tenemos la posibilidad de utilizar DHE (Diffie-Hellmann Ephemeral) como protocolo de intercambio de claves, dejando el intercambio de claves RSA completamente de lado, y además, solo permite utilizar grupos DH que se saben actualmente que son seguros de utilizar, no permitiendo todos ellos. De hecho, actualmente TLS 1.3 soporta:
- (ECDHE): secp256r1, secp384r1, secp521r1, x25519, x448.
- (DHE): dhe2048, 3072, 4096, 6144 y 8192 bits.
Respecto al cifrado simétrico, en cualquier comunicación segura es necesario cumplir tanto la confidencialidad (cifrado de los datos), como también integridad (que los datos no se hayan modificado). En TLS 1.2 y anteriores esta operación se realizaba por separado, no todo en el mismo algoritmo (excepto si usabas AES-GCM).
En TLS 1.3 se han eliminado todos los cifrados y modos de cifrado problemáticos, como por ejemplo el modo CBC, o el cifrado de flujo RC4. Actualmente el único cifrado simétrico permitido en TLS 1.3 debe ser AEAD, combinando el cifrado y la integridad de los datos en una sola operación, como por ejemplo AES-GCM que ya teníamos en TLS 1.2. De hecho, actualmente la suite de cifrados compatible sería esta:
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
Otra parte muy importante de TLS es la autenticación entre el cliente y el servidor. En TLS 1.3 se han retirado PKCS#1v1.5 a favor de RSA-PSS, haciendo que los anteriores ataques contra PKCS#1v1.5 no afecte a TLS 1.3. En la versión TLS 1.2 y anteriores, tan solo se firmaba el handshake, y no las partes de negociación de los protocolos de cifrado, ahora en TLS 1.3 se firma todo, para evitar ataques como FREAK que reducían la seguridad de TLS 1.2 forzando a que los clientes se conectasen con el protocolo más inseguro (y no con el más seguro).
Por último, debido a que han desaparecido algoritmos, se ha simplificado también la forma de mostrar la configuración de un enlace TLS.
Rendimiento
El “apretón de manos” o también conocido como “handshake” en TLS, se ha mantenido casi sin cambios desde los inicios de este protocolo en 1999. Este handshake requiere dos viajes adicionales entre el navegador y el servidor web antes de poder enviar cualquier dato cifrado, o un handshake al reanudar una conexión previamente establecida. Esto hace que las conexiones HTTPS sean más lentas en comparación con HTTP, sobre todo si nos conectamos a una página web cuyo servidor está geográficamente muy lejos de nosotros, y es que tendremos una grandísima latencia en la conexión, lo mismo ocurre si por ejemplo nos metemos en una web a través de una red 3G o 4G, redes cuya latencia está entorno a los 40 – 100 ms aproximadamente.
El IETF ha mejorado esta parte del protocolo TLS para hacerlo más rápido, y es que ahora tenemos el modo 1-RTT, haciendo muchísimo más simple la negociación al haber reducido los protocolos soportados, por tanto, el navegador web puede enviar en el primer mensaje esta información, sin esperar a que el servidor web le conteste como ocurría anteriormente, y que directamente el servidor cuando recibe la clave DH le devuelva directamente. En caso de que el cliente envíe una negociación que el servidor no entienda, el servidor le enviará un mensaje para que el cliente sepa qué grupos admite. En este último caso, los tiempos de ida y vuelta son iguales que TLS 1.2, pero se espera que rara vez suceda este caso.
Respecto a la reanudación de la sesión, en TLS 1.2 teníamos 1-RTT, sin embargo con TLS 1.3 podremos tener 0-RTT, es decir, que directamente cuando el cliente quiera reanudar la sesión TLS, pueda hacerlo sin preguntarle al servidor. Ambas partes comparten un secreto principal de reanudación, por tanto, no es necesario volver a intercambiar las claves y estar en el escenario anterior, excepto si queremos proporcionar Forward Secrecy. La parte negativa de esta técnica es que un atacante puede capturar este paquete 0-RTT y reenviarlo al servidor web con un ataque Replay, aunque hay formas para mitigarlo.
Actualmente todos los navegadores y servidores web soportan TLS 1.3, es cuestión de tiempo que poco a poco vayamos haciendo la transición a este nuevo protocolo de seguridad.
Te recomendamos leer este completo artículo sobre la RFC 8446 en el blog de CloudFlare, y también leer la propia RFC 8446 para que conozcas en detalle todas las características del protocolo.
