Recordemos que en la primera parte identificamos tres lugares diferentes en un producto SASE donde el soporte de TLS 1.3 es relevante. En orden descendente de importancia, esos lugares son: proxy, túnel e interfaz de gestión. También identificamos tres formas diferentes en que los proveedores "soportan" TLS 1.3: en orden descendente de calidad, eran "soporte verdadero", "negociación a la baja" o "bypass".
Sorprendentemente, a pesar de los méritos de TLS 1.3, y más de dos años después de su finalización, algunos proveedores de seguridad todavía no tienen un verdadero soporte de TLS 1.3 en su proxy. Aún más alarmante, se puede encontrar gente que dice públicamente (pero de forma incorrecta) que esos proveedores soportan TLS 1.3, lo que sólo es cierto de una forma débil, como si contaran una historia, o en forma de mensaje de marketing y ventas.
Ahora hablemos de algunos fabricantes/proveedores conocidos y de lo que hacen.
| Fabricante | Estrategia | ¿Se conecta con un TLS 1.3 estricto? | ¿Seguridad con TLS 1.3? |
|---|---|---|---|
| Netskope | TLS 1.3 verdadero | Sí | Sí |
| Zscaler | Negociación a la baja o bypass | Bypass | No |
| Symantec WSS | Negociación a la baja | No | No |
Como ya hemos señalado, Netskope tiene una verdadera implementación de TLS 1.3 para nuestro proxy. Hemos contado al menos otros seis proveedores de seguridad que han elegido hacer lo mismo, lo cual no es muy sorprendente. Después de todo, esta es la elección que esperarías que hicieran los proveedores de seguridad. Lo que es más sorprendente son los proveedores que no han hecho una verdadera implementación de TLS 1.3 (al menos, no todavía).
Por ejemplo, Zscaler utiliza la estrategia combinada de "negociación a la baja o bypass". Esto significa que Zscaler no romperá necesariamente una posible conexión TLS 1.3 haciendo imposible que el cliente y el servidor se comuniquen. Pero ya que Zscaler no puede realmente entregar sus controles de seguridad a través de una conexión TLS 1.3, su nube tiene que decidir en cada nueva conexión si renunciar a TLS 1.3 o renunciar a los controles de seguridad.
Cada vez que un usuario TLS 1.3 intenta conectarse a través de Zscaler a un servicio que soporta TLS 1.2, Zscaler degradará esa conexión. Pero cada vez que un usuario intenta conectarse a un servicio que requiere TLS 1.3, Zscaler hará completamente bypass de la conexión y no realizará ninguna inspección de seguridad en ella. (Bueno, hay una alternativa: en esta situación, Zscaler también puede bloquear la conexión como tráfico no descifrable. Esa opción aún no aplica ningún control de seguridad, pero podría ser preferible en algunos casos. De cualquier forma que lo veamos, claramente no es grandioso que las únicas opciones disponibles aquí sean "apagar la seguridad" o "no permitir el servicio").
El WSS de Symantec parece usar sólo la estrategia de negociación descendente. La mayoría de los servidores soportan TLS 1.2 por compatibilidad, por lo que, en el caso común, Symantec WSS se comportará de manera similar a Zscaler. Reducirá la seguridad y el rendimiento de la conexión en comparación con lo que el cliente podría haber logrado por sí solo, pero el cliente seguirá conectándose al servidor y Symantec WSS seguirá aplicando sus controles de seguridad. Sin embargo, si el servidor se niega a negociar el TLS 1.2, Symantec WSS impedirá que un cliente TLS 1.3 se conecte a un servidor TLS 1.3. En esa situación, el WSS de Symantec puede, de hecho, perjudicar la productividad de la empresa en lugar de mejorar la seguridad de la misma.
También hay que tener en cuenta que es casi seguro que estos proveedores solucionarán estos problemas con el tiempo. De hecho, es posible que ya los hayan solucionado cuando lea este artículo. ¿Hará eso que toda esta discusión sea irrelevante? No del todo, porque aún es sorprendente el tiempo que los ha llevado. Descubrimos la debilidad de algunas implementaciones de la competencia a principios de diciembre de 2019, cuando Netskope ya soportaba TLS 1.3. Parecía casi seguro que esos otros proveedores pronto se pondrían al día... pero ahora es octubre de 2020. Empezó a parecer que la implementación de TLS 1.3 no era muy importante para algunos proveedores. En cambio, podrían simplemente "soportarlo" en las formas descritas en la primera parte.
Fuentes de información
¿Cómo se puede determinar el soporte de un proveedor para TLS 1.3? Como este artículo (y la primera parte) han mostrado, no es tan simple como preguntar.
La mejor estrategia es experimentar realmente con el producto de interés. Una prueba fácil es visitar facebook.com a través del proxy a probar usando Firefox. Luego puedes hacer lo siguiente, Botón derecho>Ver información de la página>Seguridad, para ver los detalles de la conexión del navegador en esa página:
- Lo que quieres ver es una conexión TLS 1.3, protegida por el certificado del proveedor del proxy. Ese resultado significa que el proxy está en la ruta y usando TLS 1.3.
- Si ves TLS 1.2, entonces el proxy ha negociado a la baja.
- Si ve una conexión TLS 1.3 que está protegida por el certificado de Facebook, entonces el proxy ha hecho bypass.
La siguiente mejor alternativa parece ser los sitios de soporte del proveedor, pero puede haber algo de trabajo detectivesco. Tanto Zscaler como Symantec reconocen las limitaciones de su soporte TLS, aunque sólo implícitamente. El sitio de soporte de Zscaler actualmente enumera los protocolos admitidos pero omite TLS 1.3, mientras que el sitio de soporte de Broadcom para Symantec WSS responde a un problema de TLS 1.3 explicando cómo desactivar TLS 1.3 en el navegador.
¿Qué tal un blog corporativo del proveedor o un sitio de terceros? Al menos por lo que hemos visto, la información allí parece tener una calidad notablemente inferior. Por ejemplo, el blog corporativo de Zscaler tiene un extenso artículo sobre TLS 1.3 que nunca dice que Zscaler lo soporta, pero ciertamente parece insinuarlo. Cuando se lee cuidadosamente, no hay nada realmente incorrecto en el artículo, pero tampoco es un modelo de comunicación directa.
De la misma manera, hay un fascinante artículo en el blog de Brian Deitch del 2018 que afirma que Zscaler se ha ocupado de todo esto, lo cual es incorrecto. El post se queja sobre todo de los fabricantes de cajas tradicionales y tiene algunos puntos buenos. Pero como ya estamos en 2020 y Zscaler todavía no soporta TLS 1.3, claramente había un error en algún lugar de la evaluación del autor.
El blog corporativo de Symantec también tiene un artículo sobre DoH que menciona el uso de un proxy de TLS 1.3 para un control adicional, sin indicar claramente que el WSS de Symantec no funciona como tal proxy. Una vez más, si lee el artículo con mucho cuidado, no es realmente falso... simplemente no ayuda al lector a entender el estado real del mundo.
En resumen
La primera parte fue una introducción a las sorprendentes complejidades que acechan en el soporte TLS 1.3, y establecimos un marco de trabajo para entender lo que está pasando allí con cualquier proveedor SASE o posible SASE. Como recordatorio, parte de lo que abordamos allí fue la pregunta "¿y qué?" acerca de por qué el soporte TLS 1.3 es importante. En este artículo, nos fijamos en algunos proveedores específicos. Si quiere aplicar este mismo enfoque a otros proveedores, tenga en cuenta:
- TLS 1.3 es importante tanto para la seguridad como para el rendimiento. Si no conoce los detalles de lo que hace su proveedor cuando hace proxy del tráfico TLS, puede estar abriéndose a vulnerabilidades inesperadas y sacrificando el rendimiento.
- El "soporte" de TLS 1.3 podría no significar lo que usted piensa; sea consciente de las formas alternativas en que un proveedor puede "soportar" el protocolo.
- Experimentar con el producto, o leer cuidadosamente el sitio de soporte del proveedor, son dos maneras probables de aclarar la situación.
- Los blogs corporativos y los sitios de terceros parecen ser fuentes de información menos fiables.
