TLS frente a cifrado de extremo a extremo: qué debes saber

TLS (Transport Layer Security) cifra los datos mientras viajan entre tu dispositivo y un servidor, y luego los descifra al llegar — lo que significa que el operador del servidor puede leer tus archivos en texto claro. El cifrado de extremo a extremo (E2EE) cifra el contenido en el dispositivo del remitente con una clave que solo posee el destinatario, de modo que los servidores nunca ven los datos sin cifrar. Para transferencias de archivos, TLS protege contra quienes espían la red, pero no contra el propio proveedor. El E2EE protege contra ambos. El candado en el navegador no te dice cuál de los dos está realmente en juego.

Qué protege realmente TLS

TLS 1.3, estandarizado en RFC 8446, es el protocolo que impulsa cada conexión HTTPS. Negocia una clave de sesión mediante ECDHE con curvas como X25519, autentica el servidor con un certificado X.509 y envuelve el tráfico HTTP en AES-128-GCM o ChaCha20-Poly1305. Es una protección excelente contra el atacante en la Wi-Fi de una cafetería o un ISP que intenta leer tus peticiones.

Lo que TLS no hace: termina en el load balancer. Cuando subes un vídeo de 3 GB a un servicio de intercambio de archivos típico, TLS descifra en el borde, luego el archivo en texto claro llega a un bucket S3, una canalización de transcodificación, quizás un trabajo de análisis de contenido con ML y, finalmente, el flujo de descarga del destinatario — que se recifra con una nueva sesión TLS. El servicio tiene acceso de lectura completo en cada paso.

Dónde empieza y dónde termina el cifrado de extremo a extremo

El E2EE real desplaza la frontera del cifrado del servidor a los extremos. En el navegador o cliente del remitente, se genera una clave simétrica (típicamente AES-256-GCM) en memoria. El archivo se cifra fragmento a fragmento antes de que un solo byte salga del dispositivo. El texto cifrado se sube por TLS al servidor, que almacena blobs opacos. El destinatario recibe la clave de descifrado por un canal separado — normalmente como fragmento de URL tras el símbolo #, que los navegadores nunca transmiten a los servidores.

El servidor, en este modelo, es una capa de almacenamiento sin inteligencia. Incluso una citación judicial completa, un empleado sin escrúpulos con acceso a la base de datos o un proveedor cloud leyendo snapshots de disco solo produciría bytes cifrados. Esta es la arquitectura que usa HexaTransfer: AES-256-GCM con una clave por transferencia generada en el cliente y nunca transmitida al servidor de origen.

Comparativa: solo TLS frente a cifrado de extremo a extremo

| Propiedad | Transferencia solo TLS | Cifrado de extremo a extremo | |---|---|---| | Cifrado en tránsito | AES-128/256-GCM | AES-256-GCM (más TLS) | | El servidor ve texto claro | Sí | No | | Ubicación de la clave | Gestionada por el servidor | Dispositivo del remitente | | Protección ante citación judicial | Ninguna | Sólida | | Análisis de contenido por el proveedor | Posible | Imposible | | Recuperación si pierdes la clave | El proveedor puede ayudar | Los datos son irrecuperables | | Servicios típicos | Google Drive, Dropbox | HexaTransfer, SwissTransfer en modo E2EE |

Cómo funciona realmente el intercambio de claves

La parte difícil del E2EE no es el cifrado — AES lleva 25 años siendo sólido. Lo difícil es llevar la clave del remitente al destinatario sin que el servidor la vea. Los servicios de transferencia de archivos usan normalmente uno de tres patrones.

El primero es el truco del fragmento de URL: el enlace tiene el aspecto de https://hexatransfer.com/d/abc123#key=xyz, donde todo lo que va después de # se queda en el navegador. JavaScript lo lee localmente y descifra. El segundo es el cifrado basado en contraseña, donde el remitente elige una frase de contraseña, la pasa por PBKDF2 (RFC 8018) o Argon2id con más de 600 000 iteraciones y comparte la contraseña fuera de banda vía Signal o una llamada de teléfono. El tercero es el intercambio de clave pública usando librerías como crypto_box de libsodium, donde el destinatario publica una clave pública X25519.

Cuándo TLS solo es suficiente

No todos los archivos necesitan E2EE. Si compartes una nota de prensa con un periodista, un meme en un grupo de chat o un PDF de marketing público, los servicios solo con TLS son perfectamente adecuados. Los datos no eran sensibles para empezar, y que el proveedor los lea no crea ningún riesgo. Estás optimizando para comodidad — previsualizaciones, miniaturas, edición en el navegador — y esas características requieren fundamentalmente acceso en texto claro en el servidor.

El cálculo cambia con imágenes médicas (archivos DICOM cubiertos por HIPAA 45 CFR 164.312(a)(2)(iv)), estados financieros bajo PCI DSS 4.0 Requisito 3.5.1, materiales de litigación, documentos de fusiones y adquisiciones, o cualquier cosa que contenga datos personales de la UE bajo el artículo 32 del RGPD. Aquí, "el proveedor puede técnicamente leer esto" es un problema de cumplimiento, no solo una cuestión estética de privacidad.

La brecha de metadatos de la que nadie habla

Incluso con E2EE perfecto, el servidor sigue viendo metadatos: marca temporal de subida, tamaño del archivo, direcciones IP del remitente y el destinatario, cadenas de user-agent, duración de la transferencia. Si tu modelo de amenaza incluye el análisis de tráfico — un periodista que se comunica con una fuente, por ejemplo — esto importa. Un archivo de 147 MB subido a las 3:14 desde una oficina de Reuters a un número de Signal en Estambul cuenta una historia aunque el contenido sea texto cifrado.

Los buenos servicios E2EE minimizan la retención de metadatos. Busca ventanas cortas de retención de logs (7 días o menos), ninguna cuenta de usuario requerida para transferencias básicas, ninguna analítica de terceros en las páginas de transferencia y, idealmente, políticas favorables al enrutamiento onion o a las VPN. La suite de cifrado importa menos que la higiene operacional que la rodea.

Verificar la afirmación

"Cifrado de extremo a extremo" es texto de marketing hasta que puedes probarlo. Tres pruebas separan el E2EE real del juego de palabras. Primero, abre DevTools y observa la pestaña de red durante una subida — si el cuerpo del archivo sale como multipart/form-data en texto claro, estás ante solo TLS. Segundo, comprueba si la URL de descifrado contiene un fragmento (#). Sin fragmento, sin clave en el cliente. Tercero, lee la política de respuesta a citaciones del servicio: si pueden producir el contenido de los archivos a las autoridades, los archivos no son E2EE de entrada. Los servicios que publican canarios de litigación y ponen en código abierto su código criptográfico (repositorios de GitHub que muestran el uso de la WebCrypto API) ofrecen la garantía más sólida.

Para envíos cotidianos de archivos grandes donde la confidencialidad importa, elige un servicio explícito sobre su modelo. Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.