Fundamentos

Cifrado en tránsito: qué protege y cuáles son sus límites

Por Daniel Sardá · Publicado el 22 de octubre de 2026 a las 14:22 UTC

6 min de lectura1.195 palabras

El cifrado en tránsito protege los datos mientras viajan por una red. Es una defensa esencial, pero no equivale a anonimato ni a cifrado de extremo a extremo.

Al iniciar sesión en un sitio web, el nombre de usuario y la contraseña salen del navegador y recorren una red hasta llegar al servicio. En ese trayecto pueden pasar por el router doméstico, el proveedor de internet y distintas infraestructuras intermedias. El cifrado en tránsito busca que alguien situado en esa ruta no pueda leer ni modificar fácilmente la información.

La protección se aplica mientras los datos se mueven entre dos puntos técnicos. No los vuelve invisibles para todo el mundo, no garantiza que el servicio sea honesto y no protege por sí sola lo que ocurre antes de enviarlos o después de recibirlos. Su valor es importante, pero tiene un perímetro definido.

Idea clave: el cifrado en tránsito protege un recorrido de los datos, no todo su ciclo de vida.

Qué significa que un dato esté «en tránsito»

Un dato está en tránsito cuando se transfiere de un sistema a otro a través de una red. Puede ser un mensaje que sale de una aplicación, un formulario enviado desde el navegador, una consulta a una base de datos o un archivo que se copia a un servidor remoto.

La misma información puede atravesar varios estados. Mientras permanece guardada en un teléfono o servidor, está en reposo. Cuando viaja por la red, está en tránsito. Al llegar a su destino vuelve a quedar almacenada o es procesada. Cada estado exige controles distintos: proteger la transmisión no cifra automáticamente el disco donde se conserva el dato.

Esta separación evita una conclusión engañosa. Un servicio puede ofrecer una conexión cifrada y, aun así, guardar la información sin las salvaguardas adecuadas, compartirla con terceros o exponerla debido a un dispositivo comprometido. El cifrado del trayecto resuelve un riesgo concreto, no todos los riesgos posibles.

Cómo protegen TLS y HTTPS una conexión

En la web, la tecnología habitual para proteger datos en tránsito es TLS. El protocolo permite que dos participantes técnicos —por ejemplo, un navegador y un servidor— establezcan un canal seguro antes de intercambiar información. Cuando HTTP funciona sobre ese canal, hablamos de HTTPS.

En términos sencillos, el navegador comprueba la identidad presentada por el servidor mediante su certificado y acuerda con él las claves que protegerán la sesión. A partir de entonces, las peticiones y respuestas HTTP aceptadas dentro de la conexión viajan cifradas y con mecanismos que permiten detectar alteraciones.

El conocido candado del navegador indica que existe una conexión HTTPS con el origen cuya identidad se validó. No certifica que el contenido del sitio sea verdadero, que la empresa actúe responsablemente o que una oferta comercial sea legítima. Un sitio malicioso también puede utilizar una conexión correctamente cifrada.

Según los estándares de TLS 1.3 y HTTP, esta protección reúne tres propiedades que conviene distinguir:

• Confidencialidad: dificulta que un observador en la ruta lea el contenido protegido.
• Integridad: permite detectar si la información fue alterada durante la transmisión.
• Autenticación: ayuda a comprobar la identidad del otro extremo. En la web ordinaria se autentica el servidor; la autenticación del cliente mediante certificado es opcional.

Idea clave: HTTPS acredita una conexión protegida con un origen validado; no acredita la bondad, la honestidad ni las prácticas internas del sitio.

Dónde termina la protección

Imaginemos que una persona envía una dirección postal mediante un formulario HTTPS. Quien observe la conexión desde una red pública no debería poder leer ese campo ni cambiarlo sin que la manipulación sea detectada, siempre que TLS esté bien configurado y el certificado se valide correctamente.

Pero el servicio necesita descifrar la información para procesarla. A veces TLS termina en el propio servidor de la aplicación; otras veces termina en un proxy o balanceador que recibe la conexión y abre otra hacia sistemas internos. Esto no significa que la protección haya fallado. Significa que cada tramo debe protegerse de acuerdo con su arquitectura y sus riesgos.

El punto de terminación importa porque allí el contenido deja de estar cifrado por esa conexión TLS. Quien controle legítima o ilegítimamente ese extremo podría acceder a los datos en claro. Por eso, una afirmación como «usamos cifrado» está incompleta si no explica qué se cifra, durante qué trayectos y quién puede descifrarlo.

Cifrado en tránsito no es cifrado de extremo a extremo

TLS protege una conexión entre pares técnicos. En cambio, el cifrado de extremo a extremo busca que solo los extremos finales previstos —por ejemplo, quienes participan en una conversación— puedan descifrar el contenido. Un proveedor que termina una conexión TLS puede leer y procesar la información; en un sistema realmente cifrado de extremo a extremo, el proveedor no debería poseer las claves necesarias para hacerlo.

Tampoco debe confundirse el cifrado con el anonimato. Aunque TLS oculte el contenido transmitido, pueden seguir siendo observables señales como las direcciones de red, el momento de una comunicación, su duración o el volumen aproximado de tráfico. El propio estándar de TLS advierte, además, que la longitud de los registros no queda oculta por defecto sin medidas adicionales.

Estas diferencias sitúan el cifrado dentro de una visión más amplia de la privacidad y seguridad digital. Es una capa indispensable, pero necesita acompañarse de protección del dispositivo, controles de acceso, almacenamiento seguro y prácticas responsables del proveedor.

Idea clave: una conexión cifrada puede proteger el contenido frente a terceros en la ruta y, al mismo tiempo, permitir que el servicio receptor lo lea.

Qué no resuelve el cifrado del trayecto

Incluso una conexión HTTPS válida deja fuera problemas relevantes:

• un dispositivo infectado puede capturar la información antes de cifrarla;
• el servidor puede sufrir una intrusión después de recibirla;
• los datos almacenados requieren protección específica en reposo;
• el proveedor puede conservar, analizar o compartir información según sus prácticas y obligaciones;
• ciertos metadatos y patrones de tráfico pueden seguir siendo visibles.

Nada de esto vuelve inútil el cifrado en tránsito. Sin él, una red insegura ofrecería muchas más oportunidades para espiar credenciales, formularios y otros contenidos o para interferir en ellos. La conclusión razonable no es exigirle que resuelva todo, sino entender qué amenaza reduce y qué salvaguardas deben complementarlo.

Cómo evaluar la promesa de un servicio

Cuando una organización afirma que sus datos «están cifrados», unas preguntas sencillas ayudan a precisar la promesa:

1. ¿Se refiere a datos en tránsito, en reposo o a ambos?
2. ¿Qué conexiones están protegidas y dónde termina el cifrado?
3. ¿El proveedor puede acceder al contenido en claro?
4. ¿Se trata de TLS o de verdadero cifrado de extremo a extremo?
5. ¿Qué ocurre con los metadatos, las copias de seguridad y los registros?

Las respuestas no requieren que cada usuario sea especialista en criptografía. Exigen, más bien, que las afirmaciones comerciales sean concretas y que los proveedores asuman responsabilidad por las partes del sistema que controlan.

Las comunicaciones protegidas reducen la exposición innecesaria y sostienen una esfera de autonomía personal en la vida digital. Pero esa autonomía depende también de conocer los límites de la herramienta. El cifrado en tránsito ofrece una defensa valiosa durante el viaje de los datos; la protección completa requiere cuidar también el punto de partida, el destino y las decisiones de quienes operan el servicio.