No hace mucho que ha sido aprobado el borrador (Octubre 2012) sobre el nuevo protocolo HSTS como propuesta de estándar, y es justamente en este mes de Noviembre, el 19 de Noviembre 2012, cuando ha sido publicado el RFC 6797 que se corresponde con el estándar HSTS propuesto.
The IESG has approved the following document:
- 'HTTP Strict Transport Security (HSTS)' (draft-ietf-websec-strict-transport-sec-14.txt) as Proposed Standard[Info]
La iniciativa surge a raíz de los problemas que existen en la actualidad sobre la navegación segura en Internet, donde la negociación de la conexión segura (SSL o TLS) se deja en manos de la configuración del usuario (user-agent-client) y el servidor (server).
Fruto de esta negociación basada en las preferencias del usuario y configuración del servidor, surgen situaciones en la que la conexión segura que requiere de un certificado, se permite interactuar con el servidor a pesar de que éste (certificado) se encuentre revocado o no pueda ser correctamente verificado. Pudiendo dejar cookies de sesión sin protección, es decir transmisión de cookies en un canal sin cifrar.
<< A passive network attacker using such tools can steal session identifiers/cookies and hijack the user's web session(s) by obtaining cookies containing authentication credentials >>
Para evitar esta situación se aparecieron algunas extensiones para los navegadores que forzaban la conexión HTTPS para conectarse a las web con objeto de establecer una conexión segura, con aquellas WEB soportadas, desde el inicio de la comunicación, proteger de ese modo el intercambio de cookies de sesión de forma segura.
Fruto de estas iniciativas surgió la propuesta HSTS, con objeto de eliminar los problemas en la negociación de las conexiones seguras entre user-agent-client y servidores web.
¿Qué es HSTS?
HTTP Strict Transport Security (HSTS) es un protocolo que estandariza el mecanismo mediante el cuál las páginas web se "declaran" accesibles únicamente mediante conexión segura.
Para ello el servidor WEB deberá habilitar mediante HSTS su política de seguridad, donde deberá indicar las obligación de establecer la conexión segura.
¿Cómo funciona?
Consiste en utilizar un campo del protocolo HTTP para indicar la política de seguridad de la página WEB, es decir, un usar la respuesta HTTP (HTTP Response) para incluir la política de seguridad denominada STS (Strict Transport Security), donde se especifica que se debe de iniciar la conexión segura con el servidor.
STS Policy
La política de seguridad que se especifica en el campo STS esta formada siguiendo la sintaxis ABNF (Augmented Backus-Naur Form) tal y como se especifica en la RFC2616 HTTP.
A continuación se muestra la estructura del campo STS:
Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] ) directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token | quoted-string
El valor que puede contener las directivas de seguridad son:
- max-age: número de segundos máximos que se espera (HSTS Host - WEBSITE -) después de la recepción de la cabecera STS por el usuario (client).
- includeSubDomains: si esta presente indica al "user-agent" que la politica STS aplica a cualquier subdominio que cuelge del dominio de la web.
Ejemplo:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Si max-age=0, significará que el UA (user-agent) deberá eliminar la política HSTS asociada con el UA inmediatamente después de su recepción.
ALGUNAS CONSIDERACIONES
1.- Se debe tener en consideración que al utilizar HSTS, la conexión pasará de HTTP a HTTPS inmediatamente independientemente del puerto sobre el que se este operando.
... HSTS Policy applies to HTTP over any TCP port of an HSTS Host [Info]
2.- El estándar (HSTS) especifica que el UA (user-agent - navegador web) debe finalizar la conexión con el servidor si ocurre algún error durante el establecimiento de la capa segura (TLS), incluyendo cualquier error derivado de la validación de los certificados.[*]
3.- El UA no debe prestar atención alguna a las posibles etiquetas y/o elementos "HTTP-Equiv" y "<Meta>" incluidos en el código HTML.
4.- La duración máxima para la asociación por parte de la UA de un website conocido como HSTS Host es de 90 días: "max-age value of 7776000 seconds is 90 days". Esto significa que si durante ese periodo de tiempo el UA se conecta con un Know HSTS Host, la UA no terminará la conexión al no recibir el campo STS en la conexión con el servidor mientras no haya expirado.
MEJORAS DE SEGURIDAD
El estándar HSTS previene a los usuarios del ataque SSL-Stripping (Hijacking) [ o firesheep]; el SSL_Strip es un ataque que convierte la conexión HTTPS en HTTP sin que el usuario se de cuenta utilizando la técnica de Man in the Middle. Esto puede ser utilizado por "atacantes" en redes inalambricas poco seguras y/o publicas. El HSTS evitaría este tipo de ataque ya que UA (user-agent - navegador) no permitirá una conexión no segura según lo establece la política STS.
SSL Strip Attack |
No obstante aunque se implemente el estándar HSTS será tarea del desarrollador WEB evitar el contenido mixto en la páginas web, de forma que se evite la transmisión de cookies de sesión de forma no segura, en definitiva SIEMPRE se debe continuar tomando las mismas precauciones de seguridad al desarrollar como si no se tuviera el protocolo HSTS habilitado.
Para una mayor detalle en el estándar, véase la RFC 6797.
REFERENCIAS
[2] [RFC6101] The Secure Sockets Layer (SSL) Protocol Version 3.0
[3] [RFC5246] The Transport Layer Security (TLS) Protocol Version 1.2
[4] [RFC6797] HTTP Strict Transport Security (HSTS)
[5] SSL Strip
0 comentarios:
Publicar un comentario