El protocolo de transporte seguro HSTS podría convertirse en estándar en breve

Síguenos

Nuevo protocolo HSTS


Muchos de vosotros os habréis dado cuenta de que una de las principales carencias de HTTPS es que a veces no se establece la conexión segura (cifrada) hasta después de haber rellenado un formulario y transmitirlo por HTTP. Es decir, que se cifran los datos sensibles de una sesión autenticada, pero no los datos con los que se abre esa sesión, con lo que sería posible que un ataque man-in-the-middle se hiciese con nuestras credenciales.

Por eso, desde IETF (Internet Engineering Task Force) se está trabajando para buscar una solución, y una de sus principales propuestas es la estandarización del protocolo HSTS, o lo que es lo mismo, HTTP Strict Transport Security. De hecho, el Internet Engineering Steering Group ya ha aprobado el borrador, por lo que conviene ir aprendiendo el funcionamiento de este protocolo que quizá suponga el futuro de las transacciones seguras.

El objetivo es sencillo: que tras un primer establecimiento, el navegador recuerde el dominio y subdominios de modo que nunca vuelva a enviarles información en claro. Para ello, envía una cabecera en la que establece el tiempo durante el cual debe mantenerse este funcionamiento, para lo cual suele aconsejarse un valor de un año. Por ejemplo, esta sería la cabecera para 12 meses, incluyendo a los subdominios:

Strict-Transport-Security: max-age=31536000; includeSubDomains

El primer borrador para HSTS, publicado en septiembre de 2010 por Jeff Hodges, de PayPal, Collin Jackson y Adam Barth, se basó en el artículo del año anterior ForceHTTPS: Protecting High-Security Web Sites from Network Attacks. El pasado martes 2 de octubre ascendió a la categoría de Internet-Draft, por lo que pronto podría convertirse en un RFC y ser adoptado multitudinariamente.

A día de hoy, ya es usado por grandes compañías como Paypal, presente desde el primer borrador, Blogspot o Etsy; a pesar de que los navegadores asociados a sistemas operativos (Internet Explorer y Safari) aún no son capaces de procesar la cabecera. Por contra, Mozilla Firefox y Google Chrome lo soportan desde la versión 4 de cada uno de ellos, siendo uno más de los muchos motivos que los convierten en los navegadores más seguros y avanzados.

Vía | Genbeta
En Genbeta Dev | IETF comienza a trabajar en la nueva generación de HTTP 2.0, basándose en SPDY

Los comentarios se han cerrado

Ordenar por:

3 comentarios