Cómo funcionan HTTP y HTTPS

HTTP, cuyas siglas corresponden a protocolo de transferencia de hipertexto, es el protocolo que hace funcionar la web, es decir, el conjunto de reglas que permiten que un navegador y un servidor se comuniquen y se entiendan. Su funcionamiento se basa en un modelo de petición y respuesta muy sencillo de comprender: el cliente, que normalmente es el navegador, siempre toma la iniciativa y envía una petición al servidor solicitando algo, como una página, una imagen o un dato, y el servidor procesa esa petición y devuelve una respuesta con el contenido solicitado o con una indicación de lo que ha ocurrido. Es importante notar que en este modelo el servidor nunca habla por su cuenta, sino que únicamente responde a lo que se le pide. Cada petición incluye un método que indica qué se quiere hacer, como recuperar un recurso o enviar datos, y cada respuesta incluye un código de estado que resume el resultado, como éxito, redirección o error. Una característica fundamental de HTTP es que es un protocolo sin estado, lo que significa que cada petición es independiente y el servidor no recuerda por sí mismo las peticiones anteriores del mismo cliente. Esto simplifica y hace escalable el protocolo, pero obliga a usar mecanismos adicionales, como las cookies, para mantener la continuidad de una sesión entre varias peticiones, por ejemplo para recordar que un usuario ha iniciado sesión mientras navega por distintas páginas de un mismo sitio.

La diferencia entre HTTP y HTTPS es que HTTPS es HTTP con una capa de seguridad añadida mediante cifrado, mientras que HTTP transmite la información sin proteger. Técnicamente, HTTPS es el mismo protocolo HTTP, con su modelo de petición y respuesta y sus métodos y códigos de estado, pero envuelto en una capa de seguridad llamada TLS que protege toda la comunicación. Esa capa aporta tres garantías esenciales. La primera es la confidencialidad mediante cifrado: todo lo que viaja entre el navegador y el servidor va cifrado, de modo que si alguien intercepta la conexión, por ejemplo en una red wifi pública, no puede leer su contenido. La segunda es la integridad: se garantiza que los datos no puedan ser alterados durante el trayecto sin que se detecte, de manera que llegan intactos o no llegan. La tercera es la autenticación del servidor mediante un certificado, que confirma que el navegador se está comunicando realmente con el dominio que dice ser y no con un impostor que se hace pasar por él. Con HTTP sin cifrar, en cambio, cualquiera que se sitúe en el camino de la comunicación puede leer y potencialmente modificar todo lo que se transmite, incluidas contraseñas y datos personales, lo que resulta inaceptable para cualquier uso serio. Por esta razón, HTTPS se ha convertido en el estándar universal de la web, y hoy prácticamente todos los sitios lo utilizan, mostrando los navegadores advertencias cuando una conexión no está cifrada.

El candado que muestra el navegador junto a la dirección de un sitio significa que la conexión con ese sitio está cifrada mediante HTTPS y que el sitio presenta un certificado válido para el dominio que aparece en la barra de direcciones. En otras palabras, el candado garantiza dos cosas concretas: que nadie situado en el camino de la comunicación puede leer ni alterar lo que se intercambia entre el navegador y el servidor, y que se está hablando efectivamente con el dominio que figura en la barra y no con un impostor que haya suplantado la conexión. Sin embargo, y esto es un malentendido muy extendido y peligroso, el candado no significa en absoluto que el sitio sea legítimo, honesto o de confianza. La razón es que obtener un certificado válido para un dominio se ha vuelto sencillo y gratuito, de modo que cualquiera, incluidos los responsables de sitios fraudulentos, puede conseguir uno para su propio dominio y mostrar el candado. Un sitio de phishing diseñado para robar credenciales puede tener perfectamente su candado y su conexión cifrada, porque el candado protege el canal de comunicación, pero no juzga ni verifica las intenciones ni la reputación de quien está al otro lado. Por eso, el candado debe interpretarse correctamente: indica que la conexión es segura y privada, pero la decisión de confiar en un sitio debe basarse en otros factores, como comprobar cuidadosamente que el dominio es exactamente el correcto y no una imitación, y aplicar las precauciones habituales frente al phishing.

Los códigos de estado HTTP son números de tres cifras que el servidor incluye en cada respuesta para indicar de forma resumida qué ha ocurrido con la petición del cliente. Se organizan en familias según su primera cifra, lo que facilita interpretarlos de un vistazo. Los códigos que empiezan por dos indican éxito, es decir, que la petición se procesó correctamente, siendo el más común el doscientos, que significa que todo ha ido bien y se devuelve el contenido solicitado. Los que empiezan por tres indican redirección, es decir, que el recurso solicitado está en otra ubicación y el navegador debe ir a buscarlo allí, algo habitual cuando una página cambia de dirección. Los que empiezan por cuatro indican un error del lado del cliente, es decir, que hubo algún problema con la petición en sí; el más conocido es el cuatrocientos cuatro, que significa que el recurso solicitado no se ha encontrado, y otro frecuente es el que indica que el acceso está prohibido. Los que empiezan por cinco indican un error del lado del servidor, es decir, que la petición era válida pero el servidor no pudo procesarla por un fallo interno; el ejemplo típico es el quinientos. Conocer estas familias es muy útil tanto para navegar como, sobre todo, para desarrollar y diagnosticar, porque el código de estado dice inmediatamente de qué lado está el problema: un error de la familia cuatrocientos apunta a la petición o al cliente, mientras que uno de la familia quinientos apunta a un fallo del servidor, lo que orienta enseguida hacia dónde investigar.

Se dice que HTTP es sin estado porque cada petición que llega al servidor se trata de forma completamente independiente, sin que el servidor conserve, por sí mismo y por defecto, ningún recuerdo de las peticiones anteriores del mismo cliente. Dicho de otro modo, el protocolo no mantiene una memoria de la conversación: cada vez que el navegador pide algo, es como si el servidor lo atendiera por primera vez, sin saber qué pidió antes ni si es el mismo usuario que hizo una petición previa. Este diseño tiene ventajas importantes, ya que simplifica enormemente el protocolo y permite que los servidores atiendan cantidades masivas de peticiones de muchos clientes sin tener que almacenar y gestionar el contexto de cada uno, lo que favorece la escalabilidad. Sin embargo, plantea un desafío evidente, porque muchas funciones de la web requieren precisamente recordar el contexto entre peticiones, como mantener a un usuario con la sesión iniciada mientras navega por distintas páginas, conservar el contenido de un carrito de compra, o recordar preferencias. La solución a este desafío no está en el protocolo HTTP en sí, sino en mecanismos construidos por encima de él que transportan la información de contexto de una petición a otra. El más conocido es la cookie, un pequeño dato que el servidor entrega al navegador y que este devuelve en las peticiones siguientes, permitiendo así que el servidor reconozca al cliente y recupere su sesión. También se usan tokens con un propósito similar. De este modo se combina la simplicidad de un protocolo sin estado con la capacidad de ofrecer experiencias que sí recuerdan el contexto.

HTTPS cifra el contenido de la comunicación, pero no oculta por completo qué sitios se visitan, y entender este matiz es importante para tener expectativas realistas sobre la privacidad. Lo que HTTPS protege con su cifrado es el contenido concreto de las páginas y los datos que se intercambian: las palabras de una página, los datos de un formulario, las credenciales, las rutas específicas dentro del sitio y demás información viajan cifradas y no pueden ser leídas por quien intercepte la conexión. Sin embargo, hay cierta información que, dependiendo de la configuración de la red y de las tecnologías empleadas, puede seguir siendo visible para observadores en el camino, en particular el nombre del dominio del sitio con el que se está estableciendo la comunicación. Esto se debe a que ciertas partes del proceso de establecer la conexión y de la resolución previa del nombre pueden revelar a qué dominio se conecta el usuario, aunque no qué páginas concretas dentro de él consulta ni qué datos intercambia. Por tanto, un observador como el proveedor de internet o alguien en la misma red podría llegar a saber que se ha visitado un determinado dominio, pero no el detalle de la actividad dentro de él. Existen tecnologías y configuraciones más recientes orientadas a cifrar también esa información del nombre para mejorar la privacidad, pero su disponibilidad depende del entorno. Para ocultar de forma más completa qué sitios se visitan frente a observadores locales o el proveedor, se recurre a herramientas adicionales como las redes privadas virtuales, que enrutan y cifran todo el tráfico a través de un intermediario.