Fundamentos del cifrado
HTTPS y el cifrado de mensajes no son lo mismo
La diferencia entre proteger una conexión y cifrar un mensaje antes de que salga del navegador.
Publicado: 29 de marzo de 2026
Límites de la implementación actual
El cliente actual cifra el texto en el navegador y lleva el contenido cifrado en la URL. La contraseña compartida por separado no forma parte del enlace. No existe un servidor de aplicación que almacene, recupere, elimine o consuma mensajes una sola vez.
Contexto adicional
Imagine dos sobres.
El primero viaja por un túnel vigilado, se abre en el destino y se entrega al personal de la oficina. Eso se parece a HTTPS.
La analogía es imperfecta. Los servidores web no son oficinas, TLS no es un túnel y JavaScript convierte fácilmente las analogías sencillas en diagramas de arquitectura. Aun así, la distinción resulta útil.
Sin HTTPS, alguien situado en la ruta de red podría observar o modificar el tráfico.
Collogue debe usar HTTPS independientemente de cualquier cifrado adicional de mensajes. La criptografía del navegador entregada a través de una conexión no fiable podría sustituirse antes de ejecutarse.
HTTPS protege el trayecto. La aplicación de destino todavía puede procesar el contenido.
Que lo haga o no es una decisión de la aplicación.
Con el cifrado en el navegador, la página transforma el texto en claro en texto cifrado antes de enviar la solicitud de creación.
Eso no hace que TLS sea opcional. La conexión sigue transportando identificadores, texto cifrado, código de la aplicación y metadatos operativos. Un atacante que pueda modificar la página podría alterar el proceso de cifrado.
Una revisión de seguridad útil considera al menos cuatro estados.
El texto en claro existe en el navegador del remitente.
Entre las amenazas están las extensiones maliciosas, los scripts, el malware, las miradas indiscretas y los errores al copiar y pegar.
La solicitud puede contener texto en claro o texto cifrado, según la aplicación.
El texto en claro existe en el navegador del destinatario.
El destinatario puede leerlo, al igual que un software con privilegios suficientes en ese dispositivo.
Una afirmación de seguridad que solo analiza uno de estos estados está incompleta.
- copiar el texto en claro antes del cifrado;
- enviar la clave a otro punto de acceso;
- debilitar la generación aleatoria;
- sustituir un algoritmo;
- modificar el enlace de destino.
Esto no es un argumento contra la criptografía en el navegador. Es un argumento a favor de modelos de amenazas precisos, despliegues seguros, controles de seguridad del contenido, transparencia del código fuente, builds reproducibles cuando resulte práctico y revisiones independientes.
El cifrado del lado del cliente puede crear un límite distinto cuando la aplicación nunca recibe la clave del mensaje.
De nuevo, verifique Collogue en lugar de generalizar.
¿Puede alguien en la red leer o modificar esta conexión sin dificultad?
¿En qué forma llega el mensaje a la aplicación?
¿Quién posee lo necesario para descifrarlo?
¿Durante cuánto tiempo y con qué frecuencia lo devolverá el servicio?
Estos controles se complementan. Ninguno debe atribuirse el mérito de los demás.
No. HTTPS protege la aplicación entregada, las solicitudes, los identificadores y el texto cifrado frente a la observación y la manipulación en la red.
Sí. TLS normalmente termina en el servicio; después, la aplicación procesa los valores enviados.