El objetivo de este post es comentar sobre cambios trascendentes en la forma en que Internet es procesado, cambios que han ocurrido desde hace al menos un par de años y seguirán ocurriendo por al menos otros dos. Estos pueden pasar imperceptibles para la mayoría de los usuarios de Internet sin embargo conllevan un esfuerzo relevante para la gente de TI precísamente con el objetivo de que sean transparente para los usuarios. Si aún no están al día con ellos es necesario que los conozcan y si ya saben de ellos pero no han realizado acción alguna probablemente sus competidores ya las están realizando.
Veamos de qué se trata…
HTTP/2
Probablemente el mayor evento fue la liberación de la siguiente versión del protocolo HTTP (HTTP/2) sustituyendo a la versión anterior (HTTP/1.1) que por más de 15 años fue la favorita para este tipo de comunicaciones. HTTP es el protocolo que utilizamos todo el tiempo para interconectarnos e intercambiar información en Internet. Algunas de las modificaciones al protocolo son:
- Nueva estructura y formato a nivel de mensajería (binario) = mensajes más ligeros y menos propensos a errores.
- Menos redundancia en la información transmitida = mayor eficiencia en el uso del ancho de banda
- “Multiplexing” en la comunicación = mayor velocidad en la comunicación incluso por un mismo canal
- Compresión en los encabezados utilizados = mensajes más ligeros
- “Push” de respuestas del servidor al cliente: Le permite al servidor adelantarse en los recursos que le van a pedir y así ahorrar tiempo.
El nivel de adopción de este protocolo va creciendo tanto de clientes como servidores y, si aún no lo han tomado en cuenta, podría decir que ya van tarde. Apache, Citrix, F5, Microsoft IIS, nginx, ya cuentan con soporte para HTTP/2 del lado de servidor; Firefox, Chrome, Opera, IE, Safari, Safari iOS, Chrome Android ya cuentan también con el soporte del lado cliente. Además ya existen muchos portales, sitios y webapps bajo HTTP/2 hoy día.
Podrán encontrar los detalles del protocolo en su RFC: https://tools.ietf.org/html/rfc7540
TLS 1.3
Por medio de este protocolo nos estaremos comunicando al solicitar componentes por HTTPS (Actualmente utilizamos TLS 1.2, en el mejor de los casos). Esta versión mejorada del protocolo TLS implementa también mejoras en el intercambio de mensajería e información entre los equipos interconectados. Mayor eficiencia en el uso de los mensaje y una seguridad mejorada dando preferencia a suites de cifrado con curvas elípticas y preshared-key y dejando fuera a algoritmos débiles como RC4 y SHA-1.
Un TLS handshake más ligero y eficiente permitirá establecer las sesiones de forma más rápida y segura utilizando un procedimiento más puntual para la negociación de llaves.
El protocolo será liberado este año y esto dará pie a la obsolescencia de SSL 2 y SSL 3 quedando disponibles TLS 1.0, 1.1, 1.2 y 1.3.
Los avances en este protocolo los pueden encontrar en su último draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-12
Certificados para HTTPS – SHA256
Relacionado al tema anterior los certificados X.509 v.3 utilizados también para comunicarnos por HTTPS han sufrido alteraciones, específicamente en el algoritmo de su firma debido a que el previo, SHA-1, ha quedado expuesto a nuevos ataques, vulnerabilidades y el inevitable poder computacional.
Esta actualización inició su planeación desde finales de 2013 y ha sido apoyada por los líderes tecnológicos en Internet: Google, Microsoft, Mozilla, Apple, entre otros.
El tema con esto es que los certificados SSL que se estaban utilizando para establecer la comunicación por HTTPS cada vez era menos complicado falsificarlos debido a que la verificación principal que se hace para validar la autenticidad de un certificado se basa en el algoritmo hash SHA-1 y este algoritmo ya traía muchos problemas en cuando a su seguridad. Existen ya ataques exitosos en contra del algoritmo e Internet no podía ya depender de este para garantizar la seguridad se los túneles HTTPS. Por ende se decidió basar esa seguridad en el siguiente algoritmo hash: SHA-256.
De ahí todas las autoridades certificadoras como Verisign, Digicert, GlobalSign, Entrust, etc. recibieron la instrucción para ya no emitir certificados SSL con firma en SHA-1 y únicamente dejar SHA-256 como algritmo de firma válido.
Hoy día ya los navegadores (con soporte obviamente) están preparados para este cambio tecnológico y los sitios y aplicaciones en Internet están terminando de actualizar sus certificados a SHA-256. 2016 es el último año que tenemos para que todos los certificados SSL públicos sean firmados en SHA-256 ya que para el 1 de Enero de 2017 los certificados que hayan quedado en Internet en SHA-1 (que no sean certificados raíz) serán inválidos para todas las plataformas y clientes como Windows, Mac OS, Chrome, Firefox, Safari, Internet Explorer, Android browser, etc.
Existen herramientas que les pueden ayudar a validar la fortaleza de su servicio HTTPS incluyendo sus certificados. Una, bastante útil, es el SSL Server Test de Qualys https://www.ssllabs.com/ssltest/
Content Delivery Networks
Desde hace algunos años se comenzaron a crear una serie de servicios concentrados en lo denominado Redes de Distribución o Entrega de Contenido (CDN). Este servicio, ofrecido por empresas como Akamai, CloudFlare, Amazon, Imperva, entre otras, se han vuelto muy populares por su bajo costo para el cliente comparado con sus grandes beneficios. Básicamente trabaja de la siguiente forma:
- No importa donde uno tenga “hosteado” el sitio, aplicación, portal.
- Se contrata el servicio CDN y el proveedor le entrega al cliente una serie de IPs a las cuales tendrá que apuntar el dominio que deseemos integrar, es decir, el dominio ya no apuntará a su servicio de hosting sino a la red CDN.
- Desde el panel de administración de la CDN se redirigen las peticiones recibidas ahí hacia su servicio de hosting.
El resultado final de esta configuración es que todas las solicitudes hacia el portal ahora pasarán primero por la red del proveedor y esa red contiene diversos mecanismos de caché de contenido, seguridad, estabilidad, disponibilidad, con los cuales probablemente su sitio no contaba.
Incluso si su proveedor de hosting tuviera mantenimiento y los servidores donde estuviera hospedado su sitio o portal no respondieran durante ese periodo, la CDN puede mantener una copia temporal (caché) de los archivos que ustedes configuren por si en algún momento llegan a faltar. Así los clientes no perderán disponibilidad de sus servicios.
Estas redes integran conceptos como:
- Alta redundancia: Siempre otorgan más de una IP y en ubicaciones distintas.
- Rapidez en la entrega de contenido: Mantienen una copia en caché del contenido estático para que no tenga que viajar la petición hasta su servidor a solicitarlo. Y esto, aunado con HTTP/2, hace que los sitios vuelen.
- Seguridad: Las redes CDN se encuentran protegidas por herramientas sofisticadas de seguridad como Web Application Firewalls (WAF), Next Generation Firewall o Unified Threat Management, Intrution Prevention o Detection Systems, monitoreo activo de la red, bloqueo de fuentes sospechosas como IPs TOR o I2P y todo con el fin de que todo el tráfico que entre a sus redes sea bloqueado o sanitizado antes de que llegue a su servidor donde se encuentra realmente hospedada la aplicación.
La competencia de ellos se basa en quién ofrece más servicios a un bajo costo como todos por lo que los clientes están obteniendo grandes beneficios de forma muy accesible sin tener que invertir cantidades fuertes de dinero en infraestructura dedicada incluso de forma virtual.
Para finalizar este tema les comento que ya las CDN están habilitando HTTP/2 por lo que puede ser una buena forma de comenzar a actualizar sus aplicaciones previo a que actualicen su infraestructura de hosting.
Estos fueron algunos de los principales cambios que hay tenido Internet desde hace 2 años y que aún están en etapa de adopción. Es necesario que estén al día con ellos para poder tomarlos en cuenta en decisiones tecnológicas y de negocio importantes.