Después de muchos años de revisiones y 28 borradores, el protocolo TLS (Transport Layer Security) ha sido oficialmente aprobado como estándar por el Grupo de Trabajo de Ingeniería de Internet (Internet Engineering Task Force – IETF). La IETF es una entidad sin ánimo de lucro que se encarga de normalizar especificaciones de protocolos y procedimientos que definen la arquitectura de internet a través de monográficos de ingeniería conocidos como “Petición de comentarios” (“Request for Comments” – RFC).  El documento ya está disponible para revisión a espera de la asignación de un número de RFC oficial.

Como tal, TLS es el sucesor del protocolo SSL (“Secure Sockets Layer”) que data de 1995 y que está orientado a la prevención de captura no autorizada de tráfico, manipulación y falsificación de mensajes. Debido a una gran cantidad de vulnerabilidades (logjam, FREAK, POODLE, HEARTBLEED, BREACH, CRIME, BEAST, etc.), el protocolo SSL (en todas sus versiones) y el protocolo TLS en sus versiones 1.0 (publicado en 1999) y 1.1 (publicado en 2006) fueron catalogados como inseguros y por ello se requiere la migración a la versión 1.2 de TLS (publicada en 2008) o a la nueva versión 1.3. No obstante, esto ha implicado cambios lentos y costosos de migración e integración tanto a nivel de cliente como de servidores.

¿Qué cambios nuevos incluye TLS 1.3?

La nueva versión 1.3 de TLS incluye las siguientes mejoras:

  • Mejoras en los tiempos de conexión debido a la simplificación de los pasos en el establecimiento inicial de la conexión (“handshake”) y el uso de características como TLS False Start y Zero Round Trip Time (0-RTT).

Establecimiento inicial de conexión en TLS 1.2 y TLS 1.3

  • Se han removido algoritmos inseguros y características de seguridad de TLS 1.2 consideradas obsoletas:
    • SHA-1
    • RC4
    • DES
    • 3DES
    • AES-CBC
    • MD5
    • Grupos arbitrarios de Diffie-Hellman
    • Cifrados con limitaciones de exportación (EXPORT-strength ciphers)
  • Los algoritmos soportados por TLS 1.3 utilizan funcionalidades adicionales de seguridad denominadas “Authenticated Encryption with Associated Data (AEAD)“.
  • Las funciones de derivación de claves (“Key Derivation Functions”) han sido rediseñadas para emplear HKDF (HMAC-based Extract-and-Expand Key Derivation Function) como primitiva.
  • Se incluyen funcionalidades para prevenir ataques basados en la reducción de características de seguridad para compatibilidad entre protocolos (“downgrade”) que eran aprovechadas por atacantes para comprometer protocolos con configuraciones inseguras.
  • Durante el proceso de revisión de los borradores de los RFC se evitó la incorporación de puertas traseras (“backdoors”) en el protocolo, como fue solicitado por algunos sectores de la industria.

Un análisis detallado de todos los nuevos cambios se puede encontrar en el artículo “An overview of TLS 1.3 and Q&A” de Cloudflare o en el siguiente video:

¿Cómo afecta TLS 1.3 al cumplimiento de PCI DSS?

Al día de hoy (abril de 2018), el PCI SSC no se ha pronunciado respecto a la implementación de la nueva versión de TLS debido a su reciente publicación oficial. Sin embargo, se espera que en la revisión que el Council realice al estándar PCI DSS a mediados de año se incluyan referencias a esta versión. Es importante tener presente que de forma implícita cualquier versión de TLS superior a la versión 1.2 (aceptada actualmente) se considera como aceptable dentro de un entorno PCI DSS.

Por lo pronto, servidores web como ngnix (a partir de la versión 1.13), servicios de CDN como Cloudflare, CDN 77 y Akamai y navegadores web como Chrome y Firefox ya soportan TLS 1.3 de forma nativa. Igualmente, servicios como SSL labs y High-Tech Bridge SSL/TLS Server Configuration ya permiten validar de forma remota si un servidor soporta TLS v1.3.

NOTA: Este artículo fue publicado inicialmente en el blog de Internet Security Auditors.