Cada vez que abres una página, tu navegador y un servidor mantienen una conversación breve: tú pides algo, él responde. Ese diálogo es HTTP, y es tan cotidiano que rara vez pensamos en él. Pero hay una pregunta que decide casi todo lo demás: ¿esa conversación viaja protegida o cualquiera en el camino la puede leer? La respuesta separa a HTTP de HTTPS, y explica por qué el candado del navegador dice menos —y más— de lo que crees.
Qué es HTTP
Antes de hablar del candado hay que entender qué es lo que se protege. Y lo que se protege es HTTP: el idioma con el que el navegador y el servidor se entienden.
HTTP (HyperText Transfer Protocol) es el protocolo de petición y respuesta de la web: el cliente —tu navegador— pide un recurso y el servidor responde con él. Es un protocolo de texto y sin estado (stateless): cada petición es independiente, el servidor no recuerda la anterior por sí mismo.
Una petición HTTP se compone de un método (GET, POST…), una ruta (qué recurso pides), unas cabeceras (headers: metadatos como el navegador, el idioma o las cookies) y, a veces, un cuerpo (el contenido que envías).
Cómo viaja una petición
Antes de que HTTP diga una sola palabra, hay que llegar hasta el servidor y abrir un canal por donde hablar. Estos son los pasos de una petición HTTP normal:
- El navegador resuelve el dominio a una IP vía DNS: traduce
ejemplo.coma una dirección numérica a la que conectarse. - Abre una conexión TCP con el servidor. En HTTP, por defecto, contra el puerto 80.
- Envía la petición: el método más la ruta, seguidos de las cabeceras (y, si aplica, el cuerpo).
- El servidor devuelve una respuesta: un código de estado (200, 404, 500…), sus cabeceras y el contenido solicitado.
Hasta aquí todo funciona. El problema no es que la petición no llegue: es que en HTTP puro viaja a la vista de todos en cada tramo de la red.
El problema: HTTP va en claro
En HTTP puro no hay cifrado en ningún punto. Eso significa que todo lo que compone la conversación es legible para cualquier intermediario que esté en la ruta: el Wi-Fi de la cafetería, tu proveedor de internet, cada router por el que pasan los paquetes.
- La URL completa —incluida la ruta y sus parámetros—.
- Las cabeceras, con datos del cliente y de la sesión.
- Las cookies de sesión, que son las llaves de tu sesión iniciada.
- El contenido de la petición y de la respuesta, tal cual.
Y no es solo cuestión de leer. Un atacante bien ubicado no solo ve el tráfico: puede modificar la respuesta antes de que te llegue —inyectar contenido, alterar un enlace, cambiar lo que ves—. En HTTP no hay nada que le impida hacerlo ni forma de que tú lo notes.
"Si no escribo nada sensible, HTTP me sirve." Aunque solo leas, tus cookies de sesión viajan en cada petición: quien las lea puede hacerse pasar por ti sin tu contraseña. Y sobre una página HTTP nadie te garantiza que lo que ves sea lo que el servidor envió.
Qué añade HTTPS
HTTPS no es un protocolo nuevo que reemplace a HTTP. Es el mismo HTTP, pero transportado dentro de una capa que lo protege: TLS. La ecuación es literal: HTTPS = HTTP + TLS. Y el puerto por defecto ya no es el 80, sino el 443.
TLS le aporta a HTTP tres garantías que en claro no existían:
Confidencialidad: cifra el tráfico, de modo que un intermediario ve datos ininteligibles en vez de tu URL, tus cookies y tu contenido. Integridad: detecta si alguien alteró los datos en el camino, así la manipulación silenciosa deja de ser posible. Autenticación del servidor: verifica —mediante su certificado— que hablas con quien dice ser, y no con un impostor en medio.
El handshake de TLS, en simple
Antes de intercambiar una sola petición HTTP, cliente y servidor hacen un handshake: un saludo inicial que establece el canal cifrado. Sin entrar en el detalle de las suites criptográficas, la idea es esta:
- El navegador saluda y propone los parámetros de la conexión (versiones y algoritmos que soporta).
- El servidor presenta su certificado: su identidad más su llave pública, avalados por una autoridad en la que el navegador confía.
- El navegador valida ese certificado y, a partir de él, ambos acuerdan una clave de sesión que solo ellos conocen.
- Desde ese punto, todo el HTTP viaja cifrado con esa clave. La misma conversación de antes, ahora ilegible desde fuera.
El detalle de por qué se combinan llaves simétricas y asimétricas, y de cómo un certificado logra que tu navegador confíe en un servidor, se ve en otras entradas de Fundamentos. Aquí basta la idea: el handshake verifica identidad y pacta una clave; después, HTTP habla cifrado.
Qué protege el candado y qué no
Cuando el handshake termina bien, el navegador dibuja el candado. Y aquí es donde casi todo el mundo lee de más. El candado dice algo muy concreto —y solo eso—.
"Tiene candado, entonces es un sitio confiable / una empresa legítima." No. El candado no significa eso. Solo indica que la conexión está cifrada y que el certificado corresponde al dominio que estás visitando. Un sitio de phishing puede tener HTTPS y un candado impecable: el candado protege el canal, no garantiza la intención de quien está del otro lado.
Dicho de otro modo: el candado te asegura que nadie en el camino está leyendo o alterando tu conversación con ese dominio. No te dice si ese dominio merece tu confianza. Confidencialidad e identidad del canal son una cosa; la reputación del destinatario, otra muy distinta.
HTTP y HTTPS, lado a lado
| Característica | HTTP | HTTPS |
|---|---|---|
| Puerto por defecto | 80 | 443 |
| Cifrado en tránsito | No | Sí |
| Integridad | No | Sí |
| Autenticación del servidor | No | Sí, vía certificado |
| Qué ve un intermediario | Todo: URL, headers, contenido | Solo el dominio y el tamaño aproximado |
El ángulo banca
En banca la pregunta de "¿HTTP o HTTPS?" ni siquiera se plantea: todo va por HTTPS, sin excepción. Pero exigir HTTPS no basta si queda una rendija por donde colarse al HTTP plano. Por eso se cierran dos flancos concretos:
- Se fuerza HTTPS con HSTS. HSTS (HTTP Strict Transport Security) es una cabecera que le dice al navegador: "a este dominio, conéctate solo por HTTPS, nunca por HTTP". Con eso se evita el degradado a HTTP y los ataques de interceptación que dependen de esa primera conexión sin cifrar.
- Se evita el contenido mixto. El mixed content es cargar recursos por HTTP (una imagen, un script) dentro de una página servida por HTTPS. Basta un recurso en claro para abrir una grieta en una página que se creía cifrada, así que en banca simplemente no se permite.
HTTP y HTTPS responden la misma pregunta —cómo pedir y entregar la web— pero solo uno responde la que de verdad importa en un banco: quién puede leer o alterar lo que viaja. HTTPS blinda el transporte. Lo que no hace —ni el candado— es juzgar por ti en quién confías. Esa decisión sigue siendo tuya.
