HTTPS

El Protocolo de transferencia de hipertexto seguro (HTTPS por sus siglas en inglés) es una extensión del Protocolo de transferencia de hipertexto (HTTP). Se utiliza para la comunicación segura a través de una red informática y se utiliza ampliamente en Internet. En HTTPS, el protocolo de comunicación se cifra utilizando Transport Layer Security (TLS) o, anteriormente, Secure Sockets Layer (SSL). Por lo tanto, el protocolo también se conoce como HTTP sobre TLS o HTTP sobre SSL.

Las principales motivaciones para HTTPS son la autenticación del sitio web al que se accede y la protección de la privacidad e integridad de los datos intercambiados mientras están en tránsito. Protege contra ataques man-in-the-middle, y el cifrado bidireccional de las comunicaciones entre un cliente y un servidor protege las comunicaciones contra espionaje y manipulación.El aspecto de autenticación de HTTPS requiere que un tercero de confianza firme los certificados digitales del lado del servidor. Históricamente, esta fue una operación costosa, lo que significaba que las conexiones HTTPS totalmente autenticadas generalmente se encontraban solo en servicios de transacciones de pago seguro y otros sistemas de información corporativa seguros en la World Wide Web. En 2016, una campaña de Electronic Frontier Foundation con el apoyo de desarrolladores de navegadores web hizo que el protocolo se volviera más frecuente. Los usuarios de la web ahora usan HTTPS con más frecuencia que el HTTP no seguro original, principalmente para proteger la autenticidad de la página en todo tipo de sitios web; cuentas seguras; y para mantener privadas las comunicaciones, la identidad y la navegación web de los usuarios.

Visión general

El esquema HTTPS del Identificador uniforme de recursos (URI) tiene una sintaxis de uso idéntica al esquema HTTP. Sin embargo, HTTPS indica al navegador que utilice una capa de cifrado adicional de SSL/TLS para proteger el tráfico. SSL/TLS es especialmente adecuado para HTTP, ya que puede brindar cierta protección incluso si solo se autentica un lado de la comunicación. Este es el caso de las transacciones HTTP a través de Internet, donde normalmente solo se autentica el servidor (cuando el cliente examina el certificado del servidor).

HTTPS crea un canal seguro sobre una red insegura. Esto garantiza una protección razonable contra los intrusos y los ataques de intermediarios, siempre que se utilicen conjuntos de cifrado adecuados y que el certificado del servidor sea verificado y confiable.

Debido a que HTTPS aprovecha HTTP completamente sobre TLS, la totalidad del protocolo HTTP subyacente se puede cifrar. Esto incluye la URL de solicitud (qué página web en particular se solicitó), parámetros de consulta, encabezados y cookies (que a menudo contienen información de identificación sobre el usuario). Sin embargo, debido a que las direcciones de sitios web y los números de puerto son necesariamente parte de los protocolos TCP/IP subyacentes, HTTPS no puede proteger su divulgación. En la práctica, esto significa que incluso en un servidor web configurado correctamente, los intrusos pueden deducir la dirección IP y el número de puerto del servidor web y, a veces, incluso el nombre de dominio (por ejemplo, www.example.org, pero no el resto de la URL) que un usuario se está comunicando, junto con la cantidad de datos transferidos y la duración de la comunicación, aunque no el contenido de la comunicación.

Los navegadores web saben cómo confiar en los sitios web HTTPS en función de las autoridades de certificación que vienen preinstaladas en su software. De esta manera, los creadores de navegadores web confían en las autoridades de certificación para proporcionar certificados válidos. Por lo tanto, un usuario debe confiar en una conexión HTTPS a un sitio web si y solo si todo lo siguiente es cierto:

• El usuario confía en que el dispositivo que aloja el navegador y el método para obtener el navegador no están comprometidos (es decir, un ataque a la cadena de suministro)
• El usuario confía en que el software del navegador implementa correctamente HTTPS con autoridades de certificación correctamente preinstaladas.
• El usuario confía en que la autoridad de certificación avala solo los sitios web legítimos. (es decir, la autoridad de certificación no está comprometida y no hay emisión incorrecta de certificados).
• El sitio web proporciona un certificado válido, lo que significa que fue firmado por una autoridad de confianza.
• El certificado identifica correctamente el sitio web (p. ej., cuando el navegador visita "https://example.com", el certificado recibido corresponde correctamente a "example.com" y no a otra entidad).
• El usuario confía en que la capa de cifrado del protocolo (SSL/TLS) es lo suficientemente segura frente a intrusos.

HTTPS es especialmente importante en redes inseguras y redes que pueden estar sujetas a manipulación. Las redes inseguras, como los puntos de acceso Wi-Fi públicos, permiten que cualquier persona en la misma red local detecte paquetes y descubra información confidencial no protegida por HTTPS. Además, se ha observado que algunas redes WLAN de pago y de uso gratuito manipulan páginas web mediante la inyección de paquetes para publicar sus propios anuncios en otros sitios web. Esta práctica puede explotarse maliciosamente de muchas maneras, como inyectando malware en páginas web y robando información privada de los usuarios.

HTTPS también es importante para las conexiones a través de la red Tor, ya que los nodos Tor maliciosos podrían dañar o alterar los contenidos que pasan a través de ellos de manera insegura e inyectar malware en la conexión. Esta es una de las razones por las que Electronic Frontier Foundation y Tor Project comenzaron el desarrollo de HTTPS Everywhere, que se incluye en Tor Browser.

A medida que se revela más información sobre la vigilancia masiva global y los delincuentes que roban información personal, el uso de la seguridad HTTPS en todos los sitios web se vuelve cada vez más importante, independientemente del tipo de conexión a Internet que se utilice. Aunque los metadatos sobre las páginas individuales que visita un usuario pueden no considerarse confidenciales, cuando se agregan pueden revelar mucho sobre el usuario y comprometer su privacidad.

La implementación de HTTPS también permite el uso de HTTP/2 (o su predecesor, el ahora obsoleto protocolo SPDY), que es una nueva generación de HTTP diseñada para reducir los tiempos de carga, el tamaño y la latencia de la página.

Se recomienda utilizar HTTP Strict Transport Security (HSTS) con HTTPS para proteger a los usuarios de los ataques de intermediarios, especialmente la eliminación de SSL.

HTTPS no debe confundirse con el HTTP seguro (S-HTTP) rara vez utilizado especificado en RFC 2660.

Uso en sitios web

En abril de 2018, el 33,2 % de los 1 000 000 de sitios web principales de Alexa utilizan HTTPS de forma predeterminada, el 57,1 % de los 137 971 sitios web más populares de Internet tienen una implementación segura de HTTPS y el 70 % de las cargas de página (medidas por Firefox Telemetry) utilizan HTTPS. Sin embargo, a pesar del lanzamiento de TLS 1.3, la adopción ha sido lenta, y muchos aún permanecen en el antiguo protocolo TLS 1.2 o han adoptado el QUIC alternativo.

Integración del navegador

La mayoría de los navegadores muestran una advertencia si reciben un certificado no válido. Los navegadores más antiguos, cuando se conectaban a un sitio con un certificado no válido, presentaban al usuario un cuadro de diálogo que le preguntaba si deseaba continuar. Los navegadores más nuevos muestran una advertencia en toda la ventana. Los navegadores más nuevos también muestran de forma destacada la información de seguridad del sitio en la barra de direcciones. Los certificados de validación extendida muestran la entidad legal en la información del certificado. La mayoría de los navegadores también muestran una advertencia al usuario cuando visita un sitio que contiene una mezcla de contenido cifrado y sin cifrar. Además, muchos filtros web devuelven una advertencia de seguridad cuando se visitan sitios web prohibidos.Comparación entre diferentes tipos de certificados SSL/TLS

(Usando Firefox como ejemplo)

• Muchos navegadores web, incluido Firefox (que se muestra aquí), usan la barra de direcciones para decirle al usuario que su conexión es segura, un Certificado de Validación Extendida debe identificar la entidad legal para el certificado.
• Al acceder a un sitio solo con un certificado común, en la barra de direcciones de Firefox y otros navegadores, aparece un signo de "candado".
• La mayoría de los navegadores web alertan al usuario cuando visita sitios que tienen certificados de seguridad no válidos.

La Electronic Frontier Foundation, opinando que "En un mundo ideal, cada solicitud web podría tener HTTPS de forma predeterminada", ha proporcionado un complemento llamado HTTPS Everywhere para Mozilla Firefox, Google Chrome, Chromium y Android, que habilita HTTPS de forma predeterminada para cientos de sitios web de uso frecuente.

Forzar un navegador web para cargar contenido HTTPS solo se admite en Firefox a partir de la versión 83. A partir de la versión 94, Google Chrome puede "usar siempre conexiones seguras" si se activa en la configuración del navegador.

Seguridad

La seguridad de HTTPS es la del TLS subyacente, que generalmente usa claves públicas y privadas a largo plazo para generar una clave de sesión a corto plazo, que luego se usa para cifrar el flujo de datos entre el cliente y el servidor. Los certificados X.509 se utilizan para autenticar el servidor (ya veces también el cliente). En consecuencia, las autoridades de certificación y los certificados de clave pública son necesarios para verificar la relación entre el certificado y su propietario, así como para generar, firmar y administrar la validez de los certificados. Si bien esto puede ser más beneficioso que verificar las identidades a través de una red de confianza, las revelaciones de vigilancia masiva de 2013 llamaron la atención sobre las autoridades de certificación como un posible punto débil que permite los ataques de intermediarios.Una propiedad importante en este contexto es el secreto directo, que garantiza que las comunicaciones cifradas registradas en el pasado no se puedan recuperar y descifrar en caso de que las claves o contraseñas secretas a largo plazo se vean comprometidas en el futuro. No todos los servidores web brindan confidencialidad directa.

Para que HTTPS sea efectivo, un sitio debe estar completamente alojado en HTTPS. Si algunos de los contenidos del sitio se cargan a través de HTTP (scripts o imágenes, por ejemplo), o si solo una determinada página que contiene información confidencial, como una página de inicio de sesión, se carga a través de HTTPS mientras se carga el resto del sitio. sobre HTTP simple, el usuario será vulnerable a ataques y vigilancia. Además, las cookies en un sitio servido a través de HTTPS deben tener habilitado el atributo seguro. En un sitio que tiene información confidencial, el usuario y la sesión quedarán expuestos cada vez que se acceda a ese sitio con HTTP en lugar de HTTPS.

Técnico

Diferencia de HTTP

Las URL de HTTPS comienzan con "https://" y usan el puerto 443 de manera predeterminada, mientras que las URL de HTTP comienzan con "http://" y usan el puerto 80 de manera predeterminada.

HTTP no está encriptado y, por lo tanto, es vulnerable a ataques de intermediarios y de espionaje, que pueden permitir a los atacantes obtener acceso a cuentas de sitios web e información confidencial, y modificar páginas web para inyectar malware o anuncios. HTTPS está diseñado para soportar este tipo de ataques y se considera seguro contra ellos (con la excepción de las implementaciones de HTTPS que usan versiones obsoletas de SSL).

Capas de red

HTTP opera en la capa más alta del modelo TCP/IP: la capa de aplicación; al igual que el protocolo de seguridad TLS (que funciona como una subcapa inferior de la misma capa), que cifra un mensaje HTTP antes de la transmisión y lo descifra cuando llega. Estrictamente hablando, HTTPS no es un protocolo separado, sino que se refiere al uso de HTTP normal a través de una conexión SSL/TLS encriptada.

HTTPS cifra todo el contenido de los mensajes, incluidos los encabezados HTTP y los datos de solicitud/respuesta. Con la excepción del posible ataque criptográfico CCA descrito en la sección de limitaciones a continuación, un atacante debería ser capaz de descubrir, como máximo, que se está produciendo una conexión entre dos partes, junto con sus nombres de dominio y direcciones IP.

Configuración del servidor

Para preparar un servidor web para aceptar conexiones HTTPS, el administrador debe crear un certificado de clave pública para el servidor web. Este certificado debe estar firmado por una autoridad de certificación de confianza para que el navegador web lo acepte sin previo aviso. La autoridad certifica que el titular del certificado es el operador del servidor web que lo presenta. Los navegadores web generalmente se distribuyen con una lista de certificados de firma de las principales autoridades de certificación para que puedan verificar los certificados firmados por ellos.

Adquisición de certificados

Existen varias autoridades de certificación comercial que ofrecen certificados SSL/TLS de pago de varios tipos, incluidos los certificados de validación extendida.

Let's Encrypt, lanzado en abril de 2016, brinda un servicio gratuito y automatizado que entrega certificados SSL/TLS básicos a los sitios web. Según Electronic Frontier Foundation, Let's Encrypt hará que cambiar de HTTP a HTTPS sea "tan fácil como emitir un comando o hacer clic en un botón". La mayoría de los servidores web y los proveedores de la nube ahora aprovechan Let's Encrypt, proporcionando certificados gratuitos a sus clientes.

Usar como control de acceso

El sistema también se puede utilizar para la autenticación de clientes con el fin de limitar el acceso a un servidor web a los usuarios autorizados. Para ello, el administrador del sitio suele crear un certificado para cada usuario, que el usuario carga en su navegador. Normalmente, el certificado contiene el nombre y la dirección de correo electrónico del usuario autorizado y el servidor lo verifica automáticamente en cada conexión para verificar la identidad del usuario, posiblemente sin siquiera requerir una contraseña.

En caso de clave secreta (privada) comprometida

Una propiedad importante en este contexto es el secreto directo perfecto (PFS). Poseer una de las claves secretas asimétricas a largo plazo utilizadas para establecer una sesión HTTPS no debería facilitar la obtención de la clave de sesión a corto plazo para luego descifrar la conversación, incluso en un momento posterior. El intercambio de claves Diffie-Hellman (DHE) y el intercambio de claves Diffie-Hellman de curva elíptica (ECDHE) son en 2013 los únicos esquemas que se sabe que tienen esa propiedad. En 2013, solo el 30 % de las sesiones de Firefox, Opera y Chromium Browser lo usaron, y casi el 0 % de las sesiones de Safari de Apple y Microsoft Internet Explorer. TLS 1.3, publicado en agosto de 2018, dejó de admitir cifrados sin secreto directo. A partir de febrero de 2020, el 96,6 % de los servidores web encuestados admite alguna forma de confidencialidad directa y el 52,1 % utilizará la confidencialidad directa con la mayoría de los navegadores.

Revocación de certificado

Un certificado puede revocarse antes de que caduque, por ejemplo, porque se ha comprometido el secreto de la clave privada. Las versiones más recientes de navegadores populares como Firefox, Opera e Internet Explorer en Windows Vista implementan el Protocolo de estado de certificado en línea (OCSP) para verificar que este no sea el caso. El navegador envía el número de serie del certificado a la autoridad de certificación o su delegado a través de OCSP (Protocolo de estado de certificado en línea) y la autoridad responde, diciéndole al navegador si el certificado aún es válido o no. La CA también puede emitir una CRL para informar a las personas que estos certificados están revocados. El foro CA/Browser ya no requiere CRL,sin embargo, todavía son ampliamente utilizados por las CA. La mayoría de los estados de revocación en Internet desaparecen poco después de la expiración de los certificados.

Limitaciones

El cifrado SSL (Secure Sockets Layer) y TLS (Transport Layer Security) se puede configurar en dos modos: simple y mutuo. En el modo simple, la autenticación solo la realiza el servidor. La versión mutua requiere que el usuario instale un certificado de cliente personal en el navegador web para la autenticación del usuario. En cualquier caso, el nivel de protección depende de la corrección de la implementación del software y de los algoritmos criptográficos en uso.

SSL/TLS no evita que un rastreador web indexe el sitio y, en algunos casos, el URI del recurso cifrado se puede inferir conociendo solo el tamaño de la solicitud/respuesta interceptada. Esto permite que un atacante tenga acceso al texto sin formato (el contenido estático disponible públicamente) y al texto encriptado (la versión encriptada del contenido estático), lo que permite un ataque criptográfico.

Debido a que TLS opera en un nivel de protocolo inferior al de HTTP y no tiene conocimiento de los protocolos de nivel superior, los servidores TLS solo pueden presentar estrictamente un certificado para una combinación particular de dirección y puerto. En el pasado, esto significaba que no era viable utilizar alojamiento virtual basado en nombres con HTTPS. Existe una solución llamada Indicación de nombre de servidor (SNI), que envía el nombre de host al servidor antes de cifrar la conexión, aunque muchos navegadores antiguos no admiten esta extensión. El soporte para SNI está disponible desde Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 e Internet Explorer 7 en Windows Vista.

Desde un punto de vista arquitectónico:

• Una conexión SSL/TLS es administrada por la primera máquina frontal que inicia la conexión TLS. Si, por alguna razón (enrutamiento, optimización del tráfico, etc.), esta máquina frontal no es el servidor de aplicaciones y tiene que descifrar los datos, se deben encontrar soluciones para propagar la información de autenticación del usuario o el certificado al servidor de aplicaciones, que debe saber quién se va a conectar.
• Para SSL/TLS con autenticación mutua, la sesión SSL/TLS es administrada por el primer servidor que inicia la conexión. En situaciones en las que el cifrado debe propagarse a través de servidores encadenados, la administración del tiempo de espera de la sesión se vuelve extremadamente difícil de implementar.
• La seguridad es máxima con SSL/TLS mutuo, pero en el lado del cliente no hay forma de finalizar correctamente la conexión SSL/TLS y desconectar al usuario excepto esperando que la sesión del servidor expire o cerrando todas las aplicaciones cliente relacionadas.

En la Conferencia Blackhat de 2009 se presentó un tipo sofisticado de ataque man-in-the-middle denominado SSL stripping. Este tipo de ataque anula la seguridad proporcionada por HTTPS al convertir el https:enlace en un http:enlace, aprovechando el hecho de que pocos usuarios de Internet realmente escriben "https" en la interfaz de su navegador: acceden a un sitio seguro haciendo clic en un enlace y por lo tanto, se les engaña pensando que están usando HTTPS cuando en realidad están usando HTTP. El atacante entonces se comunica claramente con el cliente. Esto impulsó el desarrollo de una contramedida en HTTP llamada HTTP Strict Transport Security.

Se ha demostrado que HTTPS es vulnerable a una variedad de ataques de análisis de tráfico. Los ataques de análisis de tráfico son un tipo de ataque de canal lateral que se basa en variaciones en el tiempo y el tamaño del tráfico para inferir propiedades sobre el propio tráfico cifrado. El análisis del tráfico es posible porque el cifrado SSL/TLS cambia el contenido del tráfico, pero tiene un impacto mínimo en el tamaño y el tiempo del tráfico. En mayo de 2010, un trabajo de investigación realizado por investigadores de Microsoft Research y la Universidad de Indiana descubrió que los datos confidenciales detallados del usuario se pueden deducir de los canales secundarios, como el tamaño de los paquetes. Los investigadores descubrieron que, a pesar de la protección HTTPS en varias aplicaciones web de primera línea y de alto perfil en atención médica, impuestos, inversiones y búsqueda web, un intruso podría inferir las enfermedades/medicamentos/cirugías del usuario,Aunque este trabajo demostró la vulnerabilidad de HTTPS al análisis de tráfico, el enfoque presentado por los autores requería un análisis manual y se enfocaba específicamente en las aplicaciones web protegidas por HTTPS.

El hecho de que la mayoría de los sitios web modernos, incluidos Google, Yahoo! y Amazon, utilicen HTTPS causa problemas a muchos usuarios que intentan acceder a puntos de acceso Wi-Fi públicos, porque la página de inicio de sesión de un punto de acceso Wi-Fi no se carga si el usuario intenta abre un recurso HTTPS. Varios sitios web, como neverssl.com y nonhttps.com, garantizan que siempre estarán accesibles por HTTP.

Historia

Netscape Communications creó HTTPS en 1994 para su navegador web Netscape Navigator. Originalmente, HTTPS se usaba con el protocolo SSL. A medida que SSL evolucionó hacia Transport Layer Security (TLS), HTTPS se especificó formalmente mediante RFC 2818 en mayo de 2000. Google anunció en febrero de 2018 que su navegador Chrome marcaría los sitios HTTP como "No seguros" después de julio de 2018. propietarios para implementar HTTPS, como un esfuerzo para hacer que la World Wide Web sea más segura.