Ahora oficialmente: TLS 1.3 reconocido como est谩ndar

Anteriormente escribimos que el Consejo de Ingenier铆a de Internet (IETF) aprob贸 una nueva versi贸n de TLS - 1.3. La semana pasada, el protocolo fue reconocido como un est谩ndar. Hoy, hablemos de sus capacidades.


/ foto Charles Dyer CC

Caracter铆sticas de TLS 1.3


Comenzaron a trabajar en la actualizaci贸n del protocolo en 2014. Extraoficialmente, el trabajo en TLS 1.3 finaliz贸 en marzo de este a帽o, pero los ingenieros necesitaron unos meses m谩s para realizar verificaciones adicionales.

Los creadores afirman que la versi贸n final de TLS 1.3 es m谩s segura y productiva: todas las vulnerabilidades conocidas (hoy) de TLS 1.2 est谩n cerradas en sus algoritmos de cifrado, y el proceso de "apret贸n de manos" es el doble de r谩pido que su predecesor. Los desarrolladores tambi茅n agregaron confidencialidad y nuevas caracter铆sticas como 0-RTT.

TLS 1.3 realiz贸 el mayor n煤mero de cambios significativos en la historia del protocolo. Por esta raz贸n, algunos incluso sugirieron llamarlo TLS 2.0.

Ahora que la nueva versi贸n del protocolo TLS 1.3 ( RFC 8446 ) est谩 oficialmente aprobada, queda por implementarlo para todas las conexiones de red.

Dificultades de implementaci贸n


TLS tiene una especie de compatibilidad con versiones anteriores. Cuando se establece una conexi贸n entre el cliente y el servidor, se intercambian las versiones compatibles del protocolo y se selecciona aquella con la que ambas partes pueden trabajar. Sin embargo, esta caracter铆stica no se usa en todas partes. Con la llegada de TLS 1.3, m谩s del 3% de los servidores con soporte TLS 1.2 simplemente se desconectaron en lugar de enviar al cliente el n煤mero de versi贸n que era compatible.

Se ha producido un problema similar con los nodos intermedios ( middlebox ). Debido al hecho de que TLS no cambi贸 mucho, cosas como firewalls, NAT y equilibradores de carga se negaron a trabajar con la nueva versi贸n del protocolo.

Los ingenieros denominaron este fen贸meno osificaci贸n (osificaci贸n). El hecho de que algunos desarrolladores no utilicen las caracter铆sticas flexibles del protocolo dificulta la introducci贸n de nuevas implementaciones del mismo. Como analog铆a, los participantes de la industria citan el ejemplo de la vieja puerta. Si no lo toca durante mucho tiempo, los bucles se oxidan y se abre con un crujido.


/ foto Christopher Sessums CC

Resulta que el protocolo anterior est谩 desactualizado, pero no funcionar谩 introducir uno nuevo por defecto. Se puede encontrar m谩s informaci贸n sobre el tema, por ejemplo, en el estudio del a帽o pasado de IEEE ( PDF ).

La soluci贸n fue encontrada por David Benjamin, trabajando en Chromium. Sugiri贸 disfrazar el primer mensaje de un cliente que admite TLS 1.3 como un mensaje TLS 1.2. Y funcion贸: el 3% mencionado de los servidores dej贸 de desconectarse. Para los sitios intermedios, Kyle Nekritz de Facebook sugiri贸 usar el mismo enfoque. Esto redujo el n煤mero de bloqueos en un 6.5% en Chrome y en un 2% en Firefox.

Para verificar si los middleboxes son compatibles con la nueva versi贸n del protocolo, puede usar la prueba desarrollada en Cloudflare.

C贸mo simplificar la implementaci贸n


Seg煤n Eric Rescorla, uno de los desarrolladores de especificaciones para TLS y HTTPS, en general, implementar TLS 1.3 no es tan dif铆cil. El consejo de ingenier铆a trat贸 de hacer este proceso lo m谩s simple posible. TLS 1.3 utiliza las mismas claves y certificados que TLS 1.2. Esto permite que el cliente y el servidor establezcan autom谩ticamente una conexi贸n a trav茅s de TLS 1.3 si ambos admiten la nueva versi贸n del protocolo.

Adem谩s, hay varias bibliotecas que pueden ayudarlo a implementar el protocolo m谩s r谩pido. Por ejemplo, a principios de la semana pasada, Facebook transfiri贸 su biblioteca TLS 1.3 Fizz a c贸digo abierto . Fizz reduce la latencia al transmitir datos, as铆 como la carga en la CPU.

Los desarrolladores han preparado una gu铆a sobre c贸mo comenzar a usar Fizz en Ubuntu 16.04 LTS. Est谩 en el repositorio oficial en GitHub (tambi茅n tiene una gu铆a para MacOS).

Primero necesita instalar las dependencias necesarias de locura y libsodium :

sudo apt-get install \ g++ \ cmake \ libboost-all-dev \ libevent-dev \ libdouble-conversion-dev \ libgoogle-glog-dev \ libgflags-dev \ libiberty-dev \ liblz4-dev \ liblzma-dev \ libsnappy-dev \ make \ zlib1g-dev \ binutils-dev \ libjemalloc-dev \ libssl-dev \ pkg-config \ libsodium-dev 

A continuaci贸n, debe compilar e instalar locura:

 git clone https://github.com/facebook/folly mkdir folly/build_ && cd folly/build_ cmake configure .. make -j $(nproc) sudo make install 

Luego puede proceder a instalar Fizz:

 cd ../.. git clone https://github.com/facebookincubator/fizz mkdir fizz/build_ && cd fizz/build_ cmake configure ../fizz make -j $(nproc) sudo make install 

Adem谩s de Fizz, hay otras bibliotecas en la red, por ejemplo, wolfSSL , GnuTLS o susurros .

Protocolo futuro


Para finalmente resolver el problema con la "osificaci贸n" del protocolo, David Benjamin propuso, adem谩s de la versi贸n oficial de la norma, usar varias de sus variaciones, que se lanzar谩n cada seis semanas (junto con el lanzamiento de nuevas versiones de Chrome). Por lo tanto, los servidores y los nodos intermedios deber谩n cumplir con todas las reglas para establecer una conexi贸n; de lo contrario, la mayor铆a de los clientes no podr谩n conectarse a los servicios.

Debido a esto, los desarrolladores esperan evitar posibles bloqueos al cargar p谩ginas web, as铆 como problemas similares con futuras versiones de TLS.

Se espera que la seguridad general de la red aumente significativamente despu茅s de la introducci贸n de TLS 1.3. Las bibliotecas que faciliten el despliegue de una nueva versi贸n del protocolo deber谩n contribuir a la distribuci贸n masiva.



PD Otros materiales de nuestro blog corporativo IaaS:




Lo que hacemos en IT-GRAD - las principales 谩reas:

Infraestructura virtual (IaaS) | Alojamiento PCI DSS | Nube FZ-152

Source: https://habr.com/ru/post/es420521/


All Articles