Mostrando entradas con la etiqueta RFC. Mostrar todas las entradas
Mostrando entradas con la etiqueta RFC. Mostrar todas las entradas
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

[1] [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1 
[2] [RFC6101] The Secure Sockets Layer (SSL) Protocol Version 3.0
[3] [RFC5246] The Transport Layer Security (TLS) Protocol Version 1.2

INTRODUCCIÓN

Hace unos días se publico la versión 0.4 del borrador de WebFinger el protocolo basado en el estándar HTTP para encontrar información sobre alguien o una entidad en Internet.

En realidad es una extensión del funcionamiento de "Finger" y adaptarlo a la generación 2.0, es decir, utilizar el protocolo HTTP para encontrar datos personales en Internet, dirección email, URL, teléfono de contacto, etc.

Finger protocolo que proporciona información sobre una computadora o persona. Muy utilizado a principios de la era Internet. [Más Información]

Los creadores de WebFinger pretender convertir una dirección de correo (email) en un identificador personal, es decir, actualmente con la dirección de correo de una persona, lo más que se puede hacer es enviarle un correo electrónico  no? o incluso buscar en Internet, por si aparecen más datos relacionados con dicha dirección de correo, pero estos aparecen de forma desordenada y no estructurada.

Lo que WebFinger quiere es proporcionar un protocolo que permite añadir más datos [metadatos] a dicha dirección de correo, de forma que se convierta en una forma de encontrar información personal estructurada sobre alguien o algo en Internet, por ejemplo:

 - Perfil público: información de contacto ( teléfono, dirección, etc)
 - Identificador de OpenID.
 - Avatar.
 - URL de website asociado.
 - Perfiles de las redes sociales asociados a la dirección de correo electrónico.

Incluso, información de si es un perfil privado, con información no disponible, protegiendo de esa forma la privacidad de la persona. [Las implicaciones de seguridad las trataremos más adelante, en éste artículo].


¿CÓMO FUNCIONA?

Cada administrador de un website, es el responsable de implantar el funcionamiento de webfinger, es decir, en estos instante, webfinger no es un estándar de facto en la industria, y no se encuentra incluido por defecto en los servidores web. 

Si se desea implantar el protocolo, es necesario habilitar:

  • Host-meta: añadir el soporte webfinger a dominio.
  • Webfinger profile: proporcionar un perfil webfinger en el dominio.

Soporte para el fichero "Host-Meta"

Se debe añadir un archivo XML en el root de nuestro website. Ejemplo:

http://www.midominio.com/.well-known/host-meta



<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
     xmlns:hm='http://host-meta.net/xrd/1.0'>
    <hm:Host>example.com</hm:Host>
    <Link rel='lrdd'
          template='http://example.com/describe?uri={uri}'>
        <Title>WebFinger Template</Title>
    </Link>
</XRD>

Otro ejemplo (host-meta):


<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
     xmlns:hm='http://host-meta.net/xrd/1.0'>
  <Link rel='lrdd'
        template='http://seguridadparatodos.es/webfinger?uri={uri}'>
    <Title>Webfinger Template</Title>
  </Link>
</XRD>

*Hay que establecer el elemento <Host> para que coincida con el nombre de dominio y "template" para que coincida con el perfil de WebFinger.




Creación del perfil WebFinger en nuestro website:

Un archivo XML "webfinger" en el raíz (root) de nuestro servidor web en el dominio de ejemplo, de forma que el archivo contenga lo siguiente:


http://www.midominio.com/webfinger?id=acct:joe@example.com




<?xml version='1.0' encoding='UTF-8'>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

  <Alias>http://midominio.com/users/joe</Alias>

  <Link rel='http://microformats.org/profile/hcard'
        href='http://midominio.com/users/joe' />
  <!-- Include additional Link elements here. --> 
</XRD>


Más:


<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
    <Subject>acct:joe@example.com</Subject>
    <Alias>http://example.com/profiles/joe</Alias>
    <Link rel='http://portablecontacts.net/spec/1.0'
          href='http://example.com/api/people/' />
    <Link rel='http://webfinger.net/rel/profile-page'
          type='text/html'
          href='http://example.com/profiles/joe' />
    <Link rel='http://microformats.org/profile/hcard'
          type='text/html'
          href='http://example.com/profiles/joe' />
    <Link rel='describedby'
          type='text/html'
          href='http://example.com/profiles/joe' />
    <Link rel='http://webfinger.net/rel/avatar'
          href='http://example.com/profiles/joe/photo' />
</XRD>





Para saber más sobre como implementar "WebFinger" en el servidor de dominio se recomienda visitar la siguiente página WEB.

PRIVACIDAD / SEGURIDAD

El protocolo Finger fue utilizado por los Hackers para llevar a cabo ataques de ingeniería social en los inicios  de Internet, cuando el uso de Finger estaba muy extendido, y podían acceder fácilmente a información personal que podían utilizar para construir su ataque. Debido a las implicaciones de Seguridad, el protocolo fue poco a poco relegado, llegando incluso a bloquear el servicio en aquellos equipos que todavía lo tuvieran instalado.

Ahora, con WebFinger, llegamos a la misma pregunta ¿Cómo afectará esto a nuestra privacidad? Pues al igual que otra mucha información que los usuarios proporcionan libremente a través de sus perfiles de redes sociales, con WebFinger se quiere estandarizar la forma de encontrar información personal a través de un identificador, la dirección de correo electrónica.

Las implicaciones de privacidad, serán las mismas, que cualquier otra información que se ponga públicamente a disposición de todo el mundo. Es por ello, que deberá de ser tratada con precaución y publicar solamente aquella información que desea ser encontrada.

Bajo esta premisa, la utilización de WebFinger, dará coherencia y proporcionará una estandarización de la información personal disponible, unificando bajo la dirección de correo electrónica la información que deseas que sea publica, como por ejemplo:

 - Perfiles de las redes sociales (flickr, twitter, facebook, tuenti, google plus, etc)
 - URL de página web personal, blog, empresa, CV, etc.

La implementación y aceptación de este protocolo utilizado de forma correcta, podría proporcionar una forma de encontrar información personal de forma estructura y estándar.


REFERENCIAS