SASE y TLS 1.3, Parte 1: ¿Qué significa “soportar” TLS 1.3?

TLS es el protocolo más importante para la comunicación segura con sitios web y servicios en la nube. Cualquier proveedor con ambiciones en el mercado SASE (Secure Access Service Edge) tiene que ser capaz de hacer proxy TLS a escala. Esto requiere una considerable sofisticación en términos de diseño de la infraestructura de computo y de redes para una "nube de seguridad" SASE, pero también requiere atención a los detalles del propio TLS.

TLS 1.3 es la versión actual de vanguardia de TLS, y fue lanzada hace más de dos años. Dado que TLS 1.3 tiene algunos méritos importantes, y ha sido estable durante un tiempo, no es sorprendente que varios proveedores de seguridad la soporten. Lo que es un poco más sorprendente es lo elástico que resulta el concepto "soportar". Por lo tanto, este artículo es una breve guía sobre los lugares en los que TLS 1.3 podría aparecer en un sistema SASE o en un posible sistema SASE, las formas en que podría ser "soportado" y por qué estos detalles son importantes para la seguridad de las organizaciones.

¿Es TLS 1.3 importante?

Reconozcamos inmediatamente que la mayoría de la gente no pasa mucho tiempo pensando en TLS 1.3, y probablemente no siente fuertes emociones sobre el tema. Por lo tanto, una pregunta razonable es, "¿realmente importa el protocolo?" TLS 1.3 establece una diferencia significativa en la seguridad, y se usa en una fracción significativa de los sitios web, así que hay motivos solidos por los que realmente importa. 

Aunque los cambios con respecto a TLS 1.2 son relativamente pequeños, esos cambios son importantes para eliminar o reducir una serie de ataques recientes muy notorios. En otros artículos de blog se han resumido los cambios en seguridad y rendimiento en TLS 1.3. La eliminación de un solo ataque grave es una mejora importante, y TLS 1.3 cubre mucho más que eso.

Cuando se observan las estadísticas recopiladas por los laboratorios SSL, resulta que TLS 1.3 ya es la mejor versión disponible de SSL/TLS en el 25% de los 150K de Alexa (los sitios web más populares del mundo). Así que podemos decir tranquilamente que es ampliamente utilizado.

Así que TLS 1.3 realmente importa. ¿Dónde deberíamos buscarlo en un sistema SASE?

¿Dónde aparece TLS 1.3?

En SASE o en los productos aspirantes a SASE, hay básicamente tres lugares donde es razonable prestar atención al soporte de TLS 1.3: proxy, túnel y gestión. 

El primero, y de lejos el más importante, está en la funcionalidad de proxy TLS. Un proxy de seguridad de confianza se integra efectivamente a la conversación TLS entre el cliente y el servidor, de modo que puede inspeccionar el tráfico que de otra manera está cifrado. El soporte de TLS 1.3 en un proxy de seguridad de confianza es crucial porque, de lo contrario, el uso del propio proxy en realidad degrada la seguridad: una conversación cliente/servidor que podría haber tenido lugar a través de TLS 1.3 se ve obligada, en cambio, a utilizar el TLS 1.2, conocido como vulnerable.

El segundo lugar donde importa TLS 1.3 es en los túneles, por ejemplo, en un producto o funcionalidad Zero Trust Network Access (ZTNA). Es bueno tener TLS 1.3 como transporte en el túnel, pero es menos importante que para un proxy—simplemente porque el proveedor de seguridad controla la implementación de los dos puntos finales del túnel que se están comunicando. En el caso de un túnel, el proveedor de seguridad puede reducir la vulnerabilidad de una manera que es imposible para un proxy. unque TLS 1.2 es un protocolo menos seguro que TLS 1.3, se pueden tomar medidas para "endurecer" una instancia particular de TLS 1.2 eliminando los tipos de cifrado vulnerables y cambios locales similares. En cambio, un proxy no tiene forma de saber cuán vulnerables pueden ser los endpoints con los que se está comunicando. 

En el caso de un sistema SASE o que aspira a ser llamado SASE, el tercer lugar en el que importa la funcionalidad de TLS 1.3 es para comunicarse con la consola de gestión. Los usuarios autorizados utilizan la consola de gestión para establecer políticas y analizar incidentes, por lo que los datos que pueden estar en riesgo pueden ser bastante sensibles, pero el volumen de datos es bastante bajo en comparación con el volumen de datos que pasa por el proxy o el túnel de una nube de seguridad. En el caso de las comunicaciones de la parte de gestión, los puntos finales de comunicación son controlados por el departamento de seguridad de la organización. Así pues, una vez más, existen oportunidades para "endurecer" el TLS 1.2 de maneras que no son posibles para una gran población de usuarios que se comunican con una gran población de servicios en la nube. 

Mi proveedor soporta TLS 1.3... ¿qué significa eso?

El punto de partida—y en el que todos están de acuerdo—es que un producto que "soporta" TLS 1.3 no puede romperse cuando le envías tráfico TLS 1.3. Pero esa es una restricción bastante débil, especialmente si hay diferentes ideas de lo que significa "romper". Resulta que hay (al menos) tres definiciones diferentes de lo que significa "soportar" TLS 1.3 en un proxy, ¡y sólo una de esas definiciones requiere realmente la implementación del protocolo! Podemos llamar a estas tres opciones "verdadero", "negociación a la baja" y "bypass". 

El verdadero soporte de TLS 1.3

Tomemos primero el soporte "verdadero", ya que es lo que la mayoría de la gente esperaría cuando un proxy dice soportar TLS 1.3, que es lo que Netskope implementa como proxy. En esta definición, un proxy que "tiene verdadero soporte de TLS 1.3" lleva a cabo su funcionalidad completa de seguridad incluso cuando el cliente y el servidor sólo requieren TLS 1.3. Tenga en cuenta que TLS 1.3 tiene mejores cifrados y mejores establecimientos de la comunicación inicial (handshake) que TLS 1.2, lo que lo hace más seguro y rápido de configurar, por lo que hay algunas razones sólidas para que los clientes y servidores prefieran el nuevo protocolo. 

Si el cliente y el servidor insisten en utilizar TLS 1.3 para comunicarse, y el producto va a ofrecer toda su funcionalidad de seguridad, entonces el producto tiene que implementar realmente TLS 1.3. Esto es bastante simple. 

"Soporte" a través de negociación a la baja

Ahora asumamos que el cliente y el servidor están un poco más dispuestos a llegar a un acuerdo, como la mayoría de los clientes y servidores TLS. Un proxy "soporta TLS 1.3 a través de la negociación a la baja" si lleva a cabo su funcionalidad de seguridad completa cuando el cliente y el servidor aceptan TLS 1.2. Básicamente, el "truco" aquí es que el proxy recibe una solicitud de conexión TLS 1.3 del cliente, pero la negocia hasta TLS 1.2... y luego abre una conexión TLS 1.2 al servidor. Efectivamente, el "soporte" añadido en el proxy es sólo suficiente para reconocer una petición TLS 1.3 y responder, "¡no, gracias!" al cliente. Por lo demás, es un mundo completamente TLS 1.2. 

Esta estrategia de negociación a la baja no es obviamente tan buena como el verdadero soporte más estricto de TLS 1.3. Aun así, tomemos un momento para valorar lo que es bueno y lo que es malo de esto. En el lado negativo, el proxy está degradando silenciosamente la seguridad de la conexión. Lo que hubiera sido una conexión TLS 1.3 entre el cliente y el servidor ahora es manejada por TLS 1.2 en su lugar. En el lado positivo, el proxy sigue realizando sus funciones de seguridad en este tráfico ligeramente menos seguro.

"Soporte" vía bypass

¿Qué hay de la tercera definición? Un proxy "soporta TLS 1.3 vía bypass" si no intenta procesar el tráfico TLS 1.3. No lleva a cabo ninguna funcionalidad de seguridad cuando un cliente o servidor requiere TLS 1.3. En esta extraña versión de "soporte", el proxy sólo sabe lo suficiente sobre TLS 1.3 para quitarse de en medio. 

Una vez más, esta estrategia de bypass obviamente no es tan buena como el verdadero soporte más estricto de TLS 1.3. Y de nuevo, podemos examinar lo que es bueno y malo de esto. En el lado positivo, esta estrategia no reduce silenciosamente la postura de seguridad del cliente y el servidor como la estrategia anterior; el cliente y el servidor seguirán comunicándose a través de su TLS 1.3 preferido. En el lado negativo, este enfoque elimina silenciosamente las funciones de seguridad del proxy, lo que podría ser peor que bajar a TLS 1.2.

Incluso se pueden combinar la negociación a la baja y el bypass. Cuando el cliente se pone en contacto con el proxy usando TLS 1.3, el proxy puede comprobar si puede abrir una conexión TLS 1.2 con el servidor. Si es así, negocia la conexión. Si no, el proxy la deja pasar tal cual.

Resumen de opciones

En este cuadro, se resumen las opciones de implementación del proxy y las consecuencias correspondientes cuando el servidor acepta TLS 1.2 o requiere TLS 1.3. En todos estos casos, el cliente está iniciando una conexión TLS 1.3.

Sólo la fila superior de "True TLS 1.3" funciona correctamente, con plena funcionalidad, para ambos tipos de servidores. Todas las demás entradas implican un debilitamiento del protocolo, un bypass de la funcionalidad de seguridad o el fallo completo de la conexión cliente/servidor. Tal vez sea un poco difícil de creer que alguien realmente describa las últimas tres filas como "soporte" de TLS 1.3, pero ese tipo de exageración es común cuando los departamentos de ventas y marketing se dejan llevar. En la segunda parte, seremos específicos sobre Netskope y algunos competidores, identificando cómo el proxy de cada compañía implementa (o no implementa) el verdadero TLS 1.3.