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.
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.
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.
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).
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:
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.
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:
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.
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.
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 headersUna vez activado el módulo de cabecera de Apache tendrás que reiniciar el servidor:
sudo service apache restartEl 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, exclusivamentede forma cifrada con el certificado SSL/TLS.
Recuerda que debes reiniciar Apache para que se guarden los cambios realizados en la configuración.
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.
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:
Para finalizar deberás reiniciar IIS.
La seguridad en Internet es primordial, tanto en el ámbito privado, como en el profesional. Cuando se administra una página web, es pertinente tomar medidas para que los usuarios se sientan tan seguros como sea posible y se pueda garantizar una transferencia de datos libre de riesgos. Al migrar a HTTPS, sientas las bases de una mayor seguridad y confianza por parte de tu clientela.
Hace dos años que Google ha empezado a posicionarse activamente a favor del cifrado de páginas web con SSL. Si en 2014 ya propuso la protección de la transmisión de datos como factor de ranking, en el futuro se quiere ir un paso más allá, implementando un sistema de indicadores para los usuarios del navegador de la casa, Chrome, que identificará a las páginas sin certificado de seguridad. En este...
Los certificados SSL/TLS desempeñan un papel cada vez más importante en la transmisión de datos sensibles. Estos garantizan que los paquetes de datos no se desvíen y lleguen al destinatario deseado. Los problemas solo surgen cuando los usuarios de Internet son redireccionados deliberadamente por certificados inválidos de organismos de certificación dudosos, un escenario que se puede evitar con la...
Los navegadores actuales evitan cada vez más aceptar páginas web sin cifrar e insisten en que se utilice la versión cifrada, es decir, el protocolo seguro de transferencia de hipertexto (HTTPS). ¿Por qué es importante? ¿Qué es lo que se cifra concretamente? ¿Qué información nos proporciona el navegador al respecto? Resolvemos todas tus dudas.
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
Ver packs
