<\/p>\n
Es dif\u00edcil de creer, pero la Indicaci\u00f3n de Nombre de Servidor (SNI) TLS<\/a> existe desde hace trece a\u00f1os. En nuestros tiempos modernos, es un dinosaurio, aunque extra\u00f1amente poco utilizado; aunque eso est\u00e1 cambiando por fin, y es en este blog donde exploramos c\u00f3mo los equilibradores de carga avanzados edgeNEXUS pueden admitir esta funci\u00f3n. SNI resuelve uno de los mayores problemas que muchos tienen con SSL\/TLS\/HTTPS: la necesidad de dedicar una preciada direcci\u00f3n IP a cada dominio o subdominio que deba protegerse. Esto es necesario porque SSL\/TLS asegura la conexi\u00f3n antes de que podamos inspeccionar la petici\u00f3n HTTP inicial del cliente, que contiene esos preciosos detalles del nombre de dominio. <\/p>\n La \u00fanica forma de asegurarnos de que proporcionamos el certificado correcto es servir s\u00f3lo uno por direcci\u00f3n IP y utilizar DNS para garantizar que las peticiones a un nombre de dominio concreto se dirigen a la direcci\u00f3n IP de un host que sirve el certificado correcto para ese dominio. En una empresa privada quiz\u00e1 podr\u00edamos utilizar la misma direcci\u00f3n IP pero un puerto diferente, pero entonces estar\u00edamos obligados a asegurarnos de que todo el mundo sabe que debe utilizar el puerto no est\u00e1ndar. \u00c9sta no es realmente una opci\u00f3n viable cuando se trata de servicios p\u00fablicos accesibles por Internet. <\/p>\n Podr\u00edamos utilizar certificados comod\u00edn 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\u00f3n, probablemente tengan raz\u00f3n. Es dif\u00edcil confiar en algo que, por su dise\u00f1o, representa literalmente cualquier cosa o todo dentro de un dominio. \u00bfCu\u00e1ntos dispositivos almacenan y cu\u00e1ntos empleados tienen acceso al certificado y a la clave en uso? <\/p>\n Los Certificados de Nombre Alternativo de Servidor (SAN) tambi\u00e9n han estado siempre disponibles, pero requieren conocer cada dominio espec\u00edfico que se desea proteger, en el momento en que se generan. Cualquier necesidad de eliminar o a\u00f1adir un nombre de dominio exige regenerar el certificado y actualizar con \u00e9l todos los hosts pertinentes. <\/p>\n Esa es la elecci\u00f3n cada vez m\u00e1s dif\u00edcil a la que todos nos enfrentamos una y otra vez (nuestros usuarios y clientes tambi\u00e9n): quemar una direcci\u00f3n IP o aceptar un compromiso (en todos los sentidos). Cada vez m\u00e1s dif\u00edcil porque las direcciones IP son un recurso finito que cada d\u00eda tiene menos disponibilidad y m\u00e1s valor. Por suerte para nosotros, este viejo problema tiene soluci\u00f3n desde hace muchos a\u00f1os. Nos da lo mejor de todos los mundos y, sin embargo, ha tenido poca repercusi\u00f3n hasta hace poco. <\/p>\n SNI Proporciona un m\u00e9todo para que el cliente indique al servidor (en nuestro caso un jetNEXUS) el nombre de dominio con el que est\u00e1 estableciendo una conexi\u00f3n. Esto se hace rellenando un campo de extensi\u00f3n en el primer paquete TLS del cliente (un hola) con ese nombre de dominio. Esto se env\u00eda \u201cen claro\u201d para que pueda leerse antes de que el servidor env\u00ede 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. <\/p>\n As\u00ed, un \u00fanico Servicio Virtual (y direcci\u00f3n 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\u00e1lido, proporcionado correctamente y sin errores, en funci\u00f3n de los datos facilitados por el cliente. Sirve www.jetnexus.com<\/a> y www.loadbalance.co.uk<\/a> en la misma direcci\u00f3n IP y proporciona certificados v\u00e1lidos para ambos; sin compromisos, sin complicaciones y sin desperdiciar direcciones IP. <\/p>\n Y no s\u00f3lo eso, puedes cambiar la lista de dominios admitidos por el Servicio Virtual siempre que quieras, con unos pocos clics en la GUI. A\u00f1ade o elimina certificados para a\u00f1adir o eliminar los dominios admitidos por el Servicio Virtual. Eso s\u00ed, 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\u00e1pida bastan unos minutos. Lo mismo ocurre con la compresi\u00f3n HTTP, la reescritura de<\/a> URL o cualquier otra cosa que necesites. Un \u00fanico Servicio Virtual y una \u00fanica direcci\u00f3n IP para varios dominios son muy deseables, pero no tienen por qu\u00e9 restringir ning\u00fan manejo \u00fanico que quieras aplicar al tr\u00e1fico de los distintos dominios. <\/p>\n Ya te he o\u00eddo: \u201c\u00bfcu\u00e1l es el truco?\u201d. Bueno, ciertamente sol\u00eda haber una y esa es la raz\u00f3n por la que SNI ha existido durante tanto tiempo, pero s\u00f3lo ahora est\u00e1 apareciendo en el equilibrio de carga y otros productos. \u00bfEsa raz\u00f3n? La compatibilidad con el cliente. La longevidad de la incre\u00edblemente popular combinaci\u00f3n Windows XP e IE6, que no admite SNI, ha impedido que la mayor\u00eda lo utilice. Nadie quiere cortar potencialmente el 10-20% de su audiencia. <\/p>\n Hoy, sin embargo, es un lugar mucho m\u00e1s 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\u00f3n gratuita a Windows 10 se est\u00e1 promoviendo y adoptando r\u00e1pidamente. Por fin podemos confiar en que la implantaci\u00f3n de SNI no afectar\u00e1 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\u00e1s antiguas, son compatibles con SNI. Si quieres comprobar y estar seguro de tu base de usuarios espec\u00edfica, tambi\u00e9n hay una regla flightPATH para ello. <\/p>\n Sobre la cuesti\u00f3n de la seguridad, seamos claros: el cliente proporciona informaci\u00f3n en texto plano. Se trata de informaci\u00f3n que se puede captar por cable. El cliente tambi\u00e9n hace una consulta DNS en texto plano antes de conectarse. No podemos controlar eso, as\u00ed que no se considera un riesgo revelar esta informaci\u00f3n por segunda vez m\u00e1s adelante. Quiz\u00e1s 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\u00e1s no te importe, cada persona es diferente. \u00bfSugiere esto un problema de seguridad? En cualquier caso, el cliente est\u00e1 conectado y la conexi\u00f3n es segura. A menos que est\u00e9s aplicando una pol\u00edtica de seguridad basada en el nombre de dominio (y no deber\u00edas hacerlo), todo va bien. <\/p>\n Si realmente quieres m\u00e1s detalles, echa un vistazo a la RFC3546<\/a>original (secci\u00f3n 3.1), a la RFC6066<\/a>posterior (secci\u00f3n 3) y, si te parece fiable Server Name Indication en Wikipedi. Si necesitas seguridad a nivel de aplicaci\u00f3n, el WAF edgeNEXUS se basa en la tecnolog\u00eda de cortafuegos de aplicaciones reforzada l\u00edder del sector. Disponible a trav\u00e9s de edgeNEXUS App Store, y utilizando tecnolog\u00eda de contenedores de \u00faltima generaci\u00f3n, el cortafuegos de aplicaciones edgeNEXUS ofrece una protecci\u00f3n 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\u00e1mico y basado en eventos desarrollado por edgeNEXUS para manipular y enrutar de forma inteligente el tr\u00e1fico IP, HTTP y HTTPS de carga equilibrada. Para saber m\u00e1s sobre la gesti\u00f3n del tr\u00e1fico flightPATH, haz clic aqu\u00ed, y para descubrir c\u00f3mo aprovechar al m\u00e1ximo las reglas disponibles, consulta la Gu\u00eda del Usuario de edgeNEXUS. <\/p>\n <\/p>\n Un \u00fanico Servicio Virtual (y direcci\u00f3n 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\u00e1lido, proporcionado correctamente y sin errores, en funci\u00f3n de los datos facilitados por el cliente. <\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":" Es dif\u00edcil de creer, pero la Indicaci\u00f3n de Nombre de Servidor (SNI) TLS existe desde hace trece a\u00f1os. En nuestros tiempos modernos, es un dinosaurio, aunque extra\u00f1amente poco utilizado; aunque eso est\u00e1 cambiando por fin, y es en este blog donde exploramos c\u00f3mo los equilibradores de carga avanzados edgeNEXUS pueden admitir esta funci\u00f3n. SNI […]<\/p>\n","protected":false},"author":13,"featured_media":51181,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[500],"tags":[1040,501,1039,1041,1042,1038],"class_list":["post-51180","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-es","tag-certificados-ssl","tag-equilibrador-de-carga","tag-identificacion-del-nombre-del-servidor","tag-seguridad-ssl","tag-ssl-es","tag-tls-sni-es"],"yoast_head":"\n