HSTS: Así funciona la extensión HTTPS

Cada vez más proveedores de Internet dedican sus esfuerzos a facilitar un acceso más seguro a los contenidos online. Con este objetivo se ha consolidado en la World Wide Web el protocolo de cifrado TLS (Transport Layer Security), popularizado como SSL (Secure Sockets Layer). Mientras que la conexión a través de HTTP (Hypertext Transfer Protocol) se efectúa sin cifrar, el protocolo de red HTTPS (“Hypertext Transfer Protocol Secure” o “Hypertext Transfer Protocol over SSL/TLS”) garantiza un tráfico web más seguro.

Incluso Google, el gigante de Internet, se está convirtiendo en un ejemplo a seguir y ofrece, en sus muy visitadas páginas web, únicamente el cifrado SSL/TLS. Desde agosto de 2014, HTTPS es también un factor relevante para el ranking de una web. Con ello, aumentó la importancia para los operadores web del cifrado de transmisión de datos con SSL/TLS. Sin embargo, HTTPS no ofrece una protección fiable en su configuración estándar. Una y otra vez, los expertos en IT se ven obligados a cubrir brechas en la seguridad. El riesgo principal lo representan, sobretodo, los ataques man in the middle, que permiten que cibercriminales revoquen el cifrado SSL/TLS. Solo con la aparición en 2012 de HSTS se estableció un mecanismo de seguridad para conexiones HTTPS que previene ataques de este tipo.

Las vulnerabilidades de la tecnología HTTPS

En teoría, si se accede a una página web a través del protocolo de red HTTPS y de un certificado de confianza como SSL/TLS, se habla de un tipo de cifrado seguro. Sin embargo, en el pasado se presentaron repetidos ataques a las entidades emisoras que, como consecuencia, generaron la circulación de una variedad de certificados inseguros. Por otra parte, la generalización de los hábitos de uso y el descuido general en el manejo de las conexiones cifradas también facilita los ataques de phishing y man in the middle.

El cambio de HTTP a HTTPS

Los usuarios de Internet rara vez introducen URL completas, más bien las reducen a su dominio. Con ello, se pierde el protocolo HTTPS, destinado a velar por la seguridad de la conexión cifrada. Por ejemplo, si un usuario de Internet escribe example.com en la barra de direcciones de su navegador en vez de https:// example.com, el navegador lo completará automáticamente como una búsqueda y utilizará para ello el protocolo de red estándar para visitas web: HTTP.

example.com -> http:// example.com

Si la página de destino es una web encriptada, solo al final se realizará la redirección de HTTP a HTTPS desde el lado del servidor.

http:// example.com -> https:// example.com

Así, en última instancia, se establecerá una conexión cifrada. Sin embargo, para los hackers, la redirección representa una oportunidad para pasar desapercibido a la hora de ubicarse como man in the middle entre el navegador y el servidor. En este caso, los atacantes pueden leer, en texto sin formato, la totalidad del tráfico sin necesidad de deshacer el cifrado SSL/TLS. Si, por ejemplo, la página de destino es la banca online de un usuario o una tienda electrónica, las vulnerabilidades de seguridad para quienes tienen como fin realizar transacciones financieras pueden generar graves consecuencias.

Para ilustrarlo con un ejemplo: en muchos lugares hay puntos con conexión WLAN disponible. Es común que, sin pensar más allá, los usuarios se conecten a estas sin verificar quién está proporcionando dicho acceso a Internet. Los hackers utilizan esta falta de atención para utilizar sus equipos como puntos de acceso (hotspots) y grabar así la totalidad del tráfico de datos. Así, si, por comodidad, un usuario accede a su cuenta bancaria desde uno de estos puntos de acceso a Internet sin cifrar, estará dando a los hackers la posibilidad de inyectar una redirección hacia un sitio de phishing, antes de que el servidor de la banca online tenga la posibilidad de redirigir la conexión HTTP a HTTPS.

Extracción SSL

En 2009, durante la conferencia de seguridad Black Hat, el cyberpunk y fundador de Open Whisper Systems, Moxie Marlinspike, demostró cómo revocar las conexiones HTTPS ordinarias con la técnica del SSL stripping, desarrollada por él mismo.   Para revelar las vulnerabilidades en seguridad de HTTPS, Marlinspike desarrolló el software de proxy conocido como SSLstrip, que aprovecha la brecha de seguridad que surge durante la redirección de URL HTTP a HTTPS, convirtiendo todas las solicitudes HTTPS del navegador en peticiones HTTP idénticas. Mientras SSLstrip establece una conexión HTTP no cifrada con el navegador del usuario, por su parte, el programa se comunica con el servidor directamente en el nivel HTTPS. De esta manera, el usuario es engañado con un icono de favoritos (favicon) en forma de castillo para hacerle creer que se trata de una conexión segura. De esta forma es como el atacante puede acceder a la comunicación entre el navegador y el servidor. En 2012, tres años más tarde, el Grupo de trabajo de Ingeniería de Internet (IETF) presentó una solución al problema de seguridad presentado por Marlinspike. El RFC 6797 explica detalladamente la extensión HTTPS Strict Transport Security (HSTS).

¿Qué es HSTS?

HSTS (HTTP Strict Transport Security) es un mecanismo de seguridad diseñado para asegurar las conexiones HTTPS contra ataques man in the middle y secuestros de sesión (Session Hijacking). La extensión HTTPS permite a los operadores web señalar, con información adicional en la cabecera de HTTP, que, por un periodo determinado de tiempo, una página web solo será accesible por SSL/TSL. En el lado del servidor se utilizará el campo de cabecera Strict Transport Security. Esto incluye la directriz obligatoria max age y puede extenderse a las directrices includeSubDomain y preload:

Strict-Transport-Security: max-age=31536000

La directriz max-age (edad máxima) especifica cuánto tiempo debe estar disponible una web cifrada. El período se define en segundos. Una max-age de 31536000 segundos corresponde a un periodo de un año. Así, cuando un usuario visita por primera vez una página web asegurada con HSTS, el navegador recibe las siguientes instrucciones en el campo de cabecera Strict-Transport-Security:

  • Todos los enlaces no cifrados deben ser reescritos en enlaces cifrados (http:// se convertirá en https://).
  • Si no se puede establecer la seguridad de la conexión (por ejemplo, debido a un certificado no válido), esta se debe cancelar y el usuario recibe un mensaje de error.

Opcionalmente, existe la opción de ampliar la información HSTS de los subdominios. En este caso, se utiliza el campo de cabecera Strict-Transport-Security en combinación con la directriz includeSubDomains. Esta le indica al navegador que el encabezado HSTS no solo es válido para el host actual (p. ej., www.example.com) sino también para todos los subdominios del dicho dominio (p. ej., blog.example.com o adserver.example.com).

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

La directriz preload permite marcar páginas web para la llamada preloading para lidiar con el “first-visit-problem”.

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

Sin el parámetro preload, HSTS solo se aplicará a futuras visitas en la página web: una vez el navegador conoce la información del encabezado HSTS de una web, los accesos posteriores se ejecutarán de la misma forma. Este mecanismo de seguridad no toma acciones en la primera visita a la página web.

Como consecuencia, algunos proveedores de navegadores como Google y Mozilla ofrecen la posibilidad de inscribir páginas web en las llamadas listas de precarga (preload lists). Así, las webs que hayan sido registradas para precargarse, estarán disponibles exclusivamente a través de HTTPS. Las listas de precarga se ejecutan centralmente y son enviadas al navegador del usuario cuando se realizan actualizaciones.

Listas de precarga para páginas HTTPS

Debido a que HSTS solo funciona si una web ha sido visitada anteriormente al menos una vez con una conexión HTTPS no manipulable, cada visita inicial es, en principio, susceptible a ataques de SSLstripping. Para evitar esto, en la actualidad, la mayoría de navegadores acceden a listas basadas en un sistema de precarga HSTS que es proporcionado por Google como parte del proyecto Chromium. En principio, todo operador web puede introducir su nombre en la lista de precarga HSTS sin ningún coste. Ahora bien, la inclusión de una web a dicha lista depende de ciertos requisitos básicos que tienen como finalidad asegurar la calidad del sistema de control:

  • Todas las webs deben contar con un certificado SSL válido.
  • Las direcciones HTTP deben ser redirigidas a direcciones HTTPS del mismo host.
  • Todos los subdominios (incluyendo el subdominio www) tienen que estar disponibles a través de HTTPS.
  • La cabecera HSTS debe entregarse sobre el dominio base cumpliendo con los siguientes parámetros:
    • El valor para max-age debe ser al menos de ocho semanas (4.838.400 segundos).
    • La cabecera HSTS debe contener los includeSubDomains.
    • El HSTS debe incluir la directriz preload.
    • Cualquier redirección adicional HTTPS de la web debe incluir el encabezado HSTS.

Algunos de los usuarios de este servicio de precarga son Google, PayPal, Twitter y LastPass. Si quieres visitar la lista completa de dominios registrados, visita la web oficial del proyecto Chromium.

Configurar HSTS: instrucciones para Apache2, Lighttpd y NGINX

Los proveedores de contenido online que quieran proteger sus proyectos del SSLstripping usando HSTS deben configurar su servidor web para tal propósito. A continuación, explicaremos brevemente cómo configurar HSTS para Apache, NGINX, Lighttpd y Microsoft IIS.

Servidor Apache HTTP

Para poder utilizar HSTS en un servidor Apache es necesario activar el módulo de cabecera Apache (mod_headers). Como operador web, deberás escribir el siguiente comando en tu terminal:

sudo a2enmod headers

Una vez activado el módulo de cabecera de Apache tendrás que reiniciar el servidor:

sudo service apache restart

El servidor Apache HTTP permite operar varios dominios desde un mismo servidor. En el contexto de la terminología Apache, cada uno de estos dominios se denomina VirtualHost (vhost) y su configuración no depende de otros dominios en el servidor. Dado que HSTS es una extensión de HTTPS, este mecanismo de seguridad solo está disponible para los hosts virtuales con el número de puerto 443, es decir, con el puerto predeterminado para HTTPS. Para garantizar la conexión cifrada a una web HTTPS en futuras visitas, como operador web deberás añadir la siguiente línea de comando para el host virtual deseado en el archivo de configuración de Apache https.conf:

Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"

Adicionalmente se añadirán el campo de cabecera Strict-Transport-Security junto con otras directivas del contenedor VirtualHost:

<VirtualHost *:443>
    ServerAdmin support@example.com
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key
    […]
    Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"
    DocumentRoot /var/www/
</VirtualHost>

Así, cada vez que un navegador solicita una página web configurada de esta forma, Apache emite una cabecera HSTS con los parámetros deseados. En este ejemplo, el navegador recibe la orden de abrir, durante las próximas ocho semanas, todas las páginas web del dominio example.com, incluyendo sus subdominios, exclusivamente de forma cifrada con el certificado SSL/TLS.

Recuerda que debes reiniciar Apache para que se guarden los cambios realizados en la configuración.

NGINX

NGINX permite generar conexiones cifradas SSL/TLS con tan solo añadir una simple línea de código;

add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";

Este ajuste debe realizarse en el archivo de configuración /etc/nginx/nginx.conf. En lugar de VirtualHosts, en NGINX se utilizan los llamados server blocks para definir las directrices:

server {
    listen      443 ssl;
    server_name    example.com;
    ssl_certificate  www.example.com.crt;
    ssl_certificate_key  www.example.com.key;
    […]
    add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
}

NGINX también debe reiniciarse una vez finalizada su configuración.

Lighttpd

Para activar HSTS en Lighttpd basta con adaptar el archivo de configuración /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}

Los ajustes se aplicarán una vez reiniciado el servidor web.

Microsoft IIS
A diferencia de Apache, NGINX y Lighttpd, el servidor web de Microsoft Internet Information Services (IIS) se configura fácilmente a través de una interfaz gráfica de usuario. Si eres un operador web, podrás activar HSTS de la siguiente manera:

  • Inicia el IIS Manager y selecciona la web deseada.
  • Selecciona el elemento del menú “HTTP Response Header” y haz clic en “Add”.
  • En el cuadro de diálogo “Add Custom HTTP Response Header”, escribe Strict-Transport-Security en el campo “Name” y define la duración en segundos en “Value”.

Para finalizar deberás reiniciar IIS.

¿Le ha resultado útil este artículo?