Cada vez más pro­vee­do­res de Internet dedican sus esfuerzos a facilitar un acceso más seguro a los co­n­te­ni­dos online. Con este objetivo se ha co­n­so­li­da­do en la World Wide Web el protocolo de cifrado TLS (Transport Layer Security), po­pu­la­ri­za­do 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á co­n­vi­r­tie­n­do en un ejemplo a seguir y ofrece, en sus muy visitadas páginas web, úni­ca­me­n­te 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 im­po­r­ta­n­cia para los ope­ra­do­res web del cifrado de tra­n­s­mi­sión de datos con SSL/TLS. Sin embargo, HTTPS no ofrece una pro­te­c­ción fiable en su co­n­fi­gu­ra­ción estándar. Una y otra vez, los expertos en IT se ven obligados a cubrir brechas en la seguridad. El riesgo principal lo re­pre­se­n­tan, sobretodo, los ataques man in the middle, que permiten que ci­be­r­cri­mi­na­les revoquen el cifrado SSL/TLS. Solo con la aparición en 2012 de HSTS se es­ta­ble­ció un mecanismo de seguridad para co­ne­xio­nes HTTPS que previene ataques de este tipo.

Las vu­l­ne­ra­bi­li­da­des de la te­c­no­lo­gía HTTPS

En teoría, si se accede a una página web a través del protocolo de red HTTPS y de un ce­r­ti­fi­ca­do de confianza como SSL/TLS, se habla de un tipo de cifrado seguro. Sin embargo, en el pasado se pre­se­n­ta­ron repetidos ataques a las entidades emisoras que, como co­n­se­cue­n­cia, generaron la ci­r­cu­la­ción de una variedad de ce­r­ti­fi­ca­dos inseguros. Por otra parte, la ge­ne­ra­li­za­ción de los hábitos de uso y el descuido general en el manejo de las co­ne­xio­nes 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 in­tro­du­cen 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 di­re­c­cio­nes de su navegador en vez de https:// example.com, el navegador lo co­m­ple­ta­rá au­to­má­ti­ca­me­n­te 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 en­cri­p­ta­da, solo al final se realizará la re­di­re­c­ción de HTTP a HTTPS desde el lado del servidor.

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

Así, en última instancia, se es­ta­ble­ce­rá una conexión cifrada. Sin embargo, para los hackers, la re­di­re­c­ción re­pre­se­n­ta una opo­r­tu­ni­dad para pasar des­ape­r­ci­bi­do 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 ele­c­tró­ni­ca, las vu­l­ne­ra­bi­li­da­des de seguridad para quienes tienen como fin realizar tra­n­sac­cio­nes fi­na­n­cie­ras pueden generar graves co­n­se­cue­n­cias.

Para ilu­s­trar­lo con un ejemplo: en muchos lugares hay puntos con conexión WLAN di­s­po­ni­ble. Es común que, sin pensar más allá, los usuarios se conecten a estas sin verificar quién está pro­po­r­cio­na­n­do 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 po­si­bi­li­dad de inyectar una re­di­re­c­ción hacia un sitio de phishing, antes de que el servidor de la banca online tenga la po­si­bi­li­dad de redirigir la conexión HTTP a HTTPS.

Ex­tra­c­ción SSL

En 2009, durante la co­n­fe­re­n­cia de seguridad Black Hat, el cyberpunk y fundador de Open Whisper Systems, Moxie Ma­r­li­n­s­pi­ke, demostró cómo revocar las co­ne­xio­nes HTTPS or­di­na­rias con la técnica del SSL stripping, de­sa­rro­lla­da por él mismo.   Para revelar las vu­l­ne­ra­bi­li­da­des en seguridad de HTTPS, Ma­r­li­n­s­pi­ke de­sa­rro­lló el software de proxy conocido como SSLstrip, que aprovecha la brecha de seguridad que surge durante la re­di­re­c­ción de URL HTTP a HTTPS, co­n­vi­r­tie­n­do todas las so­li­ci­tu­des HTTPS del navegador en pe­ti­cio­nes 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 di­re­c­ta­me­n­te 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 co­mu­ni­ca­ción entre el navegador y el servidor. En 2012, tres años más tarde, el Grupo de trabajo de In­ge­nie­ría de Internet (IETF) presentó una solución al problema de seguridad pre­se­n­ta­do por Ma­r­li­n­s­pi­ke. El RFC 6797 explica de­ta­lla­da­me­n­te 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 co­ne­xio­nes HTTPS contra ataques man in the middle y se­cue­s­tros de sesión (Session Hijacking). La extensión HTTPS permite a los ope­ra­do­res web señalar, con in­fo­r­ma­ción adicional en la cabecera de HTTP, que, por un periodo de­te­r­mi­na­do 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 obli­ga­to­ria max age y puede ex­te­n­de­r­se a las di­re­c­tri­ces in­clu­de­Su­b­Do­main y preload:

Strict-Transport-Security: max-age=31536000

La directriz max-age (edad máxima) es­pe­ci­fi­ca cuánto tiempo debe estar di­s­po­ni­ble una web cifrada. El período se define en segundos. Una max-age de 31536000 segundos co­rre­s­po­n­de 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 si­guie­n­tes in­s­tru­c­cio­nes en el campo de cabecera Strict-Transport-Security:

  • Todos los enlaces no cifrados deben ser re­es­cri­tos en enlaces cifrados (http:// se co­n­ve­r­ti­rá en https://).
  • Si no se puede es­ta­ble­cer la seguridad de la conexión (por ejemplo, debido a un ce­r­ti­fi­ca­do no válido), esta se debe cancelar y el usuario recibe un mensaje de error.

Op­cio­na­l­me­n­te, existe la opción de ampliar la in­fo­r­ma­ción HSTS de los su­b­do­mi­nios. En este caso, se utiliza el campo de cabecera Strict-Transport-Security en co­m­bi­na­ción con la directriz in­clu­de­Su­b­Do­mai­ns. Esta le indica al navegador que el en­ca­be­za­do HSTS no solo es válido para el host actual (p. ej., www.example.com) sino también para todos los su­b­do­mi­nios del dicho dominio (p. ej., blog.example.com o adserver.example.com).

Strict-Transport-Security: max-age=31536000; in­clu­de­Su­b­Do­mai­ns

La directriz preload permite marcar páginas web para la llamada pre­loa­di­ng para lidiar con el “first-visit-problem”.

Strict-Transport-Security: max-age=31536000; in­clu­de­Su­b­Do­mai­ns; preload

Sin el parámetro preload, HSTS solo se aplicará a futuras visitas en la página web: una vez el navegador conoce la in­fo­r­ma­ción del en­ca­be­za­do HSTS de una web, los accesos po­s­te­rio­res se eje­cu­ta­rán de la misma forma. Este mecanismo de seguridad no toma acciones en la primera visita a la página web.

Como co­n­se­cue­n­cia, algunos pro­vee­do­res de na­ve­ga­do­res como Google y Mozilla ofrecen la po­si­bi­li­dad de inscribir páginas web en las llamadas listas de precarga (preload lists). Así, las webs que hayan sido re­gi­s­tra­das para pre­ca­r­gar­se, estarán di­s­po­ni­bles ex­clu­si­va­me­n­te a través de HTTPS. Las listas de precarga se ejecutan ce­n­tra­l­me­n­te y son enviadas al navegador del usuario cuando se realizan ac­tua­li­za­cio­nes.

Listas de precarga para páginas HTTPS

Debido a que HSTS solo funciona si una web ha sido visitada an­te­rio­r­me­n­te al menos una vez con una conexión HTTPS no ma­ni­pu­la­ble, cada visita inicial es, en principio, su­s­ce­p­ti­ble a ataques de SS­L­s­tri­p­pi­ng. Para evitar esto, en la ac­tua­li­dad, la mayoría de na­ve­ga­do­res acceden a listas basadas en un sistema de precarga HSTS que es pro­po­r­cio­na­do por Google como parte del proyecto Chromium. En principio, todo operador web puede in­tro­du­cir 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 re­qui­si­tos básicos que tienen como finalidad asegurar la calidad del sistema de control:

  • Todas las webs deben contar con un ce­r­ti­fi­ca­do SSL válido.
  • Las di­re­c­cio­nes HTTP deben ser re­di­ri­gi­das a di­re­c­cio­nes HTTPS del mismo host.
  • Todos los su­b­do­mi­nios (in­clu­ye­n­do el su­b­do­mi­nio www) tienen que estar di­s­po­ni­bles a través de HTTPS.
  • La cabecera HSTS debe en­tre­gar­se sobre el dominio base cu­m­plie­n­do con los si­guie­n­tes pa­rá­me­tros:
    • El valor para max-age debe ser al menos de ocho semanas (4.838.400 segundos).
    • La cabecera HSTS debe contener los in­clu­de­Su­b­Do­mai­ns.
    • El HSTS debe incluir la directriz preload.
    • Cualquier re­di­re­c­ción adicional HTTPS de la web debe incluir el en­ca­be­za­do HSTS.

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

Co­n­fi­gu­rar HSTS: in­s­tru­c­cio­nes para Apache2, Lighttpd y NGINX

Los pro­vee­do­res de contenido online que quieran proteger sus proyectos del SS­L­s­tri­p­pi­ng usando HSTS deben co­n­fi­gu­rar su servidor web para tal propósito. A co­n­ti­nua­ción, ex­pli­ca­re­mos bre­ve­me­n­te cómo co­n­fi­gu­rar 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 te­r­mi­no­lo­gía Apache, cada uno de estos dominios se denomina Vi­r­tua­lHo­st (vhost) y su co­n­fi­gu­ra­ción no depende de otros dominios en el servidor. Dado que HSTS es una extensión de HTTPS, este mecanismo de seguridad solo está di­s­po­ni­ble para los hosts virtuales con el número de puerto 443, es decir, con el puerto pre­de­te­r­mi­na­do para HTTPS. Para ga­ra­n­ti­zar 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 co­n­fi­gu­ra­ción de Apache https.conf:

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

Adi­cio­na­l­me­n­te se añadirán el campo de cabecera Strict-Transport-Security junto con otras di­re­c­ti­vas del co­n­te­ne­dor Vi­r­tua­lHo­st:

<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 co­n­fi­gu­ra­da de esta forma, Apache emite una cabecera HSTS con los pa­rá­me­tros 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, in­clu­ye­n­do sus su­b­do­mi­nios, ex­clu­si­va­me­n­te de forma cifrada con el ce­r­ti­fi­ca­do SSL/TLS.

Recuerda que debes reiniciar Apache para que se guarden los cambios rea­li­za­dos en la co­n­fi­gu­ra­ción.

NGINX

NGINX permite generar co­ne­xio­nes 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 rea­li­zar­se en el archivo de co­n­fi­gu­ra­ción /etc/nginx/nginx.conf. En lugar de Vi­r­tua­lHo­sts, en NGINX se utilizan los llamados server blocks para definir las di­re­c­tri­ces:

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 re­ini­ciar­se una vez fi­na­li­za­da su co­n­fi­gu­ra­ción.

Lighttpd

Para activar HSTS en Lighttpd basta con adaptar el archivo de co­n­fi­gu­ra­ció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 re­ini­cia­do el servidor web.

Microsoft IIS
A di­fe­re­n­cia de Apache, NGINX y Lighttpd, el servidor web de Microsoft Internet In­fo­r­ma­tion Services (IIS) se configura fá­ci­l­me­n­te 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 se­le­c­cio­na la web deseada.
  • Se­le­c­cio­na 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.

Ir al menú principal