Es difícil de creer, pero la Indicación de Nombre de Servidor (SNI) TLS existe desde hace trece años. En nuestros tiempos modernos, es un dinosaurio, aunque extrañamente poco utilizado; aunque eso está cambiando por fin, y es en este blog donde exploramos cómo los equilibradores de carga avanzados edgeNEXUS pueden admitir esta función. SNI resuelve uno de los mayores problemas que muchos tienen con SSL/TLS/HTTPS: la necesidad de dedicar una preciada dirección IP a cada dominio o subdominio que deba protegerse. Esto es necesario porque SSL/TLS asegura la conexión antes de que podamos inspeccionar la petición HTTP inicial del cliente, que contiene esos preciosos detalles del nombre de dominio.
La única forma de asegurarnos de que proporcionamos el certificado correcto es servir sólo uno por dirección IP y utilizar DNS para garantizar que las peticiones a un nombre de dominio concreto se dirigen a la dirección IP de un host que sirve el certificado correcto para ese dominio. En una empresa privada quizá podríamos utilizar la misma dirección IP pero un puerto diferente, pero entonces estaríamos obligados a asegurarnos de que todo el mundo sabe que debe utilizar el puerto no estándar. Ésta no es realmente una opción viable cuando se trata de servicios públicos accesibles por Internet.
Podríamos utilizar certificados comodín que protegen todos los subdominios posibles (*.jetnexus.co.uk, por ejemplo), pero a nadie le gustan, y menos a los tipos de seguridad. Independientemente de lo que pienses de los hombres y mujeres del NO! del mundo de la seguridad de la información, probablemente tengan razón. Es difícil confiar en algo que, por su diseño, representa literalmente cualquier cosa o todo dentro de un dominio. ¿Cuántos dispositivos almacenan y cuántos empleados tienen acceso al certificado y a la clave en uso?
Los Certificados de Nombre Alternativo de Servidor (SAN) también han estado siempre disponibles, pero requieren conocer cada dominio específico que se desea proteger, en el momento en que se generan. Cualquier necesidad de eliminar o añadir un nombre de dominio exige regenerar el certificado y actualizar con él todos los hosts pertinentes.
Esa es la elección cada vez más difícil a la que todos nos enfrentamos una y otra vez (nuestros usuarios y clientes también): quemar una dirección IP o aceptar un compromiso (en todos los sentidos). Cada vez más difícil porque las direcciones IP son un recurso finito que cada día tiene menos disponibilidad y más valor. Por suerte para nosotros, este viejo problema tiene solución desde hace muchos años. Nos da lo mejor de todos los mundos y, sin embargo, ha tenido poca repercusión hasta hace poco.
SNI Proporciona un método para que el cliente indique al servidor (en nuestro caso un jetNEXUS) el nombre de dominio con el que está estableciendo una conexión. Esto se hace rellenando un campo de extensión en el primer paquete TLS del cliente (un hola) con ese nombre de dominio. Esto se envía “en claro” para que pueda leerse antes de que el servidor envíe su certificado SSL/TLS. Esto permite claramente al servidor enviar el certificado esperado (suponiendo que lo tenga) de entre todos los que se le hayan proporcionado.
Así, un único Servicio Virtual (y dirección IP) puede configurarse con tantos certificados SSL para tantos nombres de dominio como quieras que sirva. Cada uno puede tener un certificado SSL dedicado y válido, proporcionado correctamente y sin errores, en función de los datos facilitados por el cliente. Sirve www.jetnexus.com y www.loadbalance.co.uk en la misma dirección IP y proporciona certificados válidos para ambos; sin compromisos, sin complicaciones y sin desperdiciar direcciones IP.
Y no sólo eso, puedes cambiar la lista de dominios admitidos por el Servicio Virtual siempre que quieras, con unos pocos clics en la GUI. Añade o elimina certificados para añadir o eliminar los dominios admitidos por el Servicio Virtual. Eso sí, no olvides actualizar tus DNS a la vez. Si quieres utilizar servidores reales distintos para uno o dos dominios de alto valor, no hay problema, con una regla flightPATH rápida bastan unos minutos. Lo mismo ocurre con la compresión HTTP, la reescritura de URL o cualquier otra cosa que necesites. Un único Servicio Virtual y una única dirección IP para varios dominios son muy deseables, pero no tienen por qué restringir ningún manejo único que quieras aplicar al tráfico de los distintos dominios.
Ya te he oído: “¿cuál es el truco?”. Bueno, ciertamente solía haber una y esa es la razón por la que SNI ha existido durante tanto tiempo, pero sólo ahora está apareciendo en el equilibrio de carga y otros productos. ¿Esa razón? La compatibilidad con el cliente. La longevidad de la increíblemente popular combinación Windows XP e IE6, que no admite SNI, ha impedido que la mayoría lo utilice. Nadie quiere cortar potencialmente el 10-20% de su audiencia.
Hoy, sin embargo, es un lugar mucho más feliz: Windows XP ha superado con creces el fin de su soporte, IE6 tiene un uso inferior al 1% en la web y la actualización gratuita a Windows 10 se está promoviendo y adoptando rápidamente. Por fin podemos confiar en que la implantación de SNI no afectará a nuestros clientes ni a nuestro negocio. IE 7 en adelante (en Vista o posterior) y casi todas las versiones de Chrome, Firefox y Safari, salvo las más antiguas, son compatibles con SNI. Si quieres comprobar y estar seguro de tu base de usuarios específica, también hay una regla flightPATH para ello.
Sobre la cuestión de la seguridad, seamos claros: el cliente proporciona información en texto plano. Se trata de información que se puede captar por cable. El cliente también hace una consulta DNS en texto plano antes de conectarse. No podemos controlar eso, así que no se considera un riesgo revelar esta información por segunda vez más adelante. Quizás quieras comprobar que el nombre de dominio SNI coincide con el que se encuentra en la cabecera HTTP Host, con una regla flightPATH o quizás no te importe, cada persona es diferente. ¿Sugiere esto un problema de seguridad? En cualquier caso, el cliente está conectado y la conexión es segura. A menos que estés aplicando una política de seguridad basada en el nombre de dominio (y no deberías hacerlo), todo va bien.
Si realmente quieres más detalles, echa un vistazo a la RFC3546original (sección 3.1), a la RFC6066posterior (sección 3) y, si te parece fiable Server Name Indication en Wikipedi. Si necesitas seguridad a nivel de aplicación, el WAF edgeNEXUS se basa en la tecnología de cortafuegos de aplicaciones reforzada líder del sector. Disponible a través de edgeNEXUS App Store, y utilizando tecnología de contenedores de última generación, el cortafuegos de aplicaciones edgeNEXUS ofrece una protección de seguridad integral para cumplir los requisitos de PCI-DSS y OWASP. Como ya se ha comentado en anteriores entradas del blog, flightPATH es un motor de reglas dinámico y basado en eventos desarrollado por edgeNEXUS para manipular y enrutar de forma inteligente el tráfico IP, HTTP y HTTPS de carga equilibrada. Para saber más sobre la gestión del tráfico flightPATH, haz clic aquí, y para descubrir cómo aprovechar al máximo las reglas disponibles, consulta la Guía del Usuario de edgeNEXUS.
Un único Servicio Virtual (y dirección IP) puede configurarse con tantos certificados SSL para tantos nombres de dominio como quieras que sirva. Cada uno puede tener un certificado SSL dedicado y válido, proporcionado correctamente y sin errores, en función de los datos facilitados por el cliente.
