Xifratge al costat del client per compartir secrets

El xifratge al costat del client protegeix un secret desat davant de l'operador i de qualsevol que obtingui la base de dades, i res més: un JavaScript maliciós, una extensió del navegador o un enllaç filtrat el deixen sense efecte, perquè la clau viatja dins l'enllaç. No és una solució màgica, i la seva única garantia té un preu en altres aspectes.

Aquesta guia explica què garanteix el xifratge al navegador, on falla sense fer soroll, com es compara amb el model del costat del servidor i com LinkPilot combina els dos des del 29 de setembre de 2026, quan el seu generador d'enllaços secrets d'un sol ús va passar a xifrar al navegador.

Reescrit el 19 d'octubre de 2026. La versió original d'aquest article descrivia el model del costat del servidor que LinkPilot feia servir aleshores; una nota afegida el 29 de setembre de 2026 deixava constància del canvi. Aquesta versió descriu el model actual de principi a fi. El raonament sobre què protegeix i què no protegeix cada model no ha canviat.

Què protegeix de debò el xifratge al costat del client?

El secret desat, davant de l'operador i de qualsevol que obtingui la base de dades. En una eina de secrets amb xifratge al costat del client (també anomenada de xifratge d'extrem a extrem, o E2EE), el procés és aquest:

1. El navegador genera una clau simètrica, normalment una clau AES-GCM de 256 bits, amb la Web Crypto API (crypto.subtle.generateKey).
2. El contingut es xifra al navegador amb aquesta clau.
3. Només el text xifrat s'envia al servidor, que el desa amb un identificador aleatori.
4. La clau s'afegeix a l'enllaç que es comparteix com a fragment (#…). Segons l'RFC 3986, secció 3.5, els navegadors no envien mai el fragment a les peticions HTTP, de manera que la clau no arriba al servidor.
5. El navegador del destinatari llegeix el fragment, baixa el text xifrat i el desxifra localment.

El servidor només veu text xifrat. Un operador que llegeix la seva pròpia base de dades, una còpia de seguretat de la base de dades que es filtra, un requeriment judicial sobre les dades desades: cap d'aquests casos revela el secret, sempre que la resta de baules de la cadena aguantin.

Anatomia d'un enllaç secret E2EE

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

Tot el que va abans del # viatja a la petició i pot aparèixer als registres del servidor i dels servidors intermediaris. El fragment només el processa el navegador del destinatari. Aquest únic caràcter fa tota la feina de seguretat, cosa que és elegant i alhora l'origen de la majoria de les fallades que es descriuen a continuació.

De què no protegeix el xifratge al costat del client?

D'un JavaScript maliciós o compromès, de les extensions del navegador i d'un enllaç filtrat, perquè la clau és a l'enllaç.

• No protegeix d'un JavaScript maliciós. El codi de xifratge s'executa al navegador, i el navegador l'ha rebut del servidor. Si el servidor lliura un codi alterat, perquè l'operador ha actuat de mala fe, l'han obligat a fer-ho o l'han atacat, el secret es pot llegir abans del xifratge o després del desxifratge. Aquest és el límit fonamental de l'E2EE al navegador.
• No protegeix de les extensions del navegador. Una extensió amb accés a la pàgina veu el text sense xifrar després del desxifratge i pot llegir el fragment directament.
• No fa inofensiu un enllaç filtrat. La clau forma part de l'enllaç. Si el destinatari enganxa l'enllaç sencer en un xat, reenvia el correu o té activada la sincronització de l'historial del navegador, la clau hi viatja. Un enllaç E2EE amb l'URL filtrat és un secret que es pot llegir sencer. L'única defensa és una frase de contrasenya enviada per un altre canal, i per això LinkPilot incorpora la frase de contrasenya a la clau en lloc de comprovar-la per separat.
• No audita, no analitza ni previsualitza el contingut. Com que el servidor no pot llegir el contingut, no hi pot aplicar filtres, ni anàlisi de programari maliciós ni prevenció de pèrdua de dades. Els controls han de funcionar sobre el text xifrat i sobre els esdeveniments d'accés.

El problema del lliurament del codi, explicat

Val la pena aturar-s'hi: l'E2EE al navegador vol dir confiar que el servidor, del qual en teoria no us fieu, lliuri un JavaScript honest cada vegada que es carrega la pàgina. Una aplicació nativa s'instal·la una vegada, signada i amb versió; una pàgina web es torna a baixar a cada visita. La integritat de subrecursos i el codi font publicat redueixen la distància, però no l'eliminen.

Per tant, la lectura honesta de «no podem llegir els vostres secrets» és «no podem llegir els vostres secrets de manera passiva». Passar d'una capacitat passiva a un atac actiu que distribueix codi modificat és un salt real (els atacs actius són més arriscats, dirigits i potencialment detectables), però no equival a «impossible». Això s'aplica a l'afirmació de LinkPilot tant com a la de qualsevol altre.

L'alternativa del costat del servidor

L'altre disseny habitual, i el que LinkPilot va fer servir fins al setembre de 2026, xifra les dades desades al servidor i protegeix la visualització amb un hash de la frase de contrasenya:

• TLS durant la transmissió; el contingut es desa en una taula dedicada d'una base de dades amb xifratge de disc.
• La frase de contrasenya es converteix en un hash al navegador abans d'enviar-la i es compara pel hash; la frase original no arriba mai a la base de dades.
• Destrucció efectiva: en la primera visualització, la caducitat o la revocació, el contingut desat se sobreescriu i els intents posteriors reben un HTTP 410.
• Els intents amb frase de contrasenya tenen un límit de freqüència i es registren.

En aquest model, el servidor pot llegir un secret actiu. Això és el que fa possibles la previsualització al servidor, l'anàlisi i les funcions que depenen del contingut, i és exactament la propietat que l'E2EE elimina. Eines de codi obert com OneTimeSecret encara el fan servir; és segur OneTimeSecret? n'analitza les conseqüències.

Què fa LinkPilot ara

Des del 29 de setembre de 2026, LinkPilot fa servir xifratge al costat del client i manté els controls del costat del servidor que no necessiten el contingut. Segons la pàgina d'arquitectura de seguretat:

• Xifratge al navegador. El contingut es xifra amb AES-GCM-256 amb una clau de 256 bits generada al navegador de qui l'envia. El servidor desa el text xifrat i res més; la clau viatja al fragment de l'enllaç que es comparteix.
• La frase de contrasenya forma part de la clau (Pro). La frase de contrasenya s'estira amb PBKDF2-SHA256 (210.000 iteracions) i es combina amb la clau de l'enllaç mitjançant HKDF-SHA256, de manera que ni l'enllaç sol ni la frase de contrasenya sola desxifren el secret. Els intents tenen un límit de 5 per IP per minut i per secret, amb un limitador en memòria i una finestra lliscant a la base de dades.
• Destrucció després de la lectura sobre el text xifrat. Una funció de la base de dades registra la visualització en un sol pas indivisible, de manera que dos intents simultanis no poden filtrar el secret dues vegades; el text xifrat desat se sobreescriu amb [REDACTED] i els intents posteriors retornen HTTP 410.
• Revocació. Un secret es pot revocar des del tauler en qualsevol moment; els secrets revocats no es mostren i retornen 410.
• Visualització protegida de les previsualitzacions. Els previsualitzadors d'enllaços i els escàners de correu fan peticions GET, que només retornen metadades (l'estat i si cal una frase de contrasenya). Una visualització només es registra quan es mostra el secret explícitament des d'un navegador.
• Cronologia d'auditoria (Pro). Creat, vist, frase de contrasenya incorrecta, destruït, caducat i revocat, cadascun amb l'hora, el país i la ciutat que indica la xarxa perimetral, la cadena del navegador i un hash de l'adreça amb una sal diària. La cronologia registra l'accés, mai el contingut.
• Fitxers. Els fitxers adjunts també es xifren al navegador, amb una clau derivada de la clau de l'enllaç. El nom, la mida i el tipus d'un fitxer continuen visibles per a LinkPilot com a metadades.

Tres límits, dits clarament. Els secrets creats abans del 29 de setembre de 2026 es van desar sense xifrar fins que van caducar; no es van tornar a escriure mai. Les metadades dels fitxers són visibles encara que el contingut no ho sigui. I tot el que diu la secció sobre el que no fa continua sent vàlid: ni aquest model ni cap altre basat en el navegador resol el JavaScript maliciós, les extensions del navegador ni un enllaç filtrat.

Resum dels compromisos

Cap model és «més segur» en abstracte. Defensen d'amenaces diferents amb costos diferents, i combinar-los redueix el que hi perdeu, però no ho elimina.

Adequar el model a l'amenaça: tres escenaris

1. Enviar la contrasenya d'una base de dades a un col·laborador extern. L'amenaça és que el secret es quedi al correu o al xat, o que algú el reenviï per error. Qualsevol model ho resol amb una caducitat curta i destrucció després de la lectura; el que decideix és la facilitat d'ús i el registre. El xifratge al navegador amb una frase de contrasenya enviada per un altre canal, i una cronologia que mostri quan s'ha obert l'enllaç, és l'opció pràctica.

2. Un periodista que rep material d'una font. El model d'amenaça inclou que s'obligui l'operador de la plataforma a revelar dades. Aquí l'operador forma part de l'amenaça, de manera que l'E2EE és el mínim, i l'opció correcta són eines fetes expressament com SecureDrop, on tot el sistema està dissenyat al voltant d'aquesta amenaça. Una eina web a la qual es podria obligar a servir JavaScript alterat no és suficient per si sola.

3. Un equip d'enginyeria que fa traspassos rutinaris de credencials. L'amenaça és la dispersió: enllaços oblidats i cap registre de qui ha vist què. Les funcions que compten són la cronologia, la revocació, els rols de l'espai de treball i una política de caducitat. Abans exigien un servidor capaç de llegir el contingut; ara ja no, perquè actuen sobre el text xifrat i els esdeveniments d'accés. Compartir contrasenyes de manera segura en equip tracta la part de polítiques d'aquest escenari.

Com triar

Trieu el xifratge al costat del client quan:

• No us fieu de l'operador, tampoc quan l'operador sou vosaltres mateixos sobre una infraestructura al núvol que no podeu verificar del tot.
• Una normativa o un contracte exigeix que el proveïdor no pugui llegir el contingut per raons tècniques.
• Enviareu la frase de contrasenya per un segon canal i mantindreu una caducitat curta, perquè, si no, un enllaç filtrat és el secret sencer.

Trieu el xifratge al costat del servidor quan:

• Necessiteu que el servidor inspeccioni el contingut: anàlisi de programari maliciós, prevenció de pèrdua de dades, filtratge de contingut.
• Allotgeu al vostre servidor una eina d'un sol propòsit i l'operador sou vosaltres.

Busqueu tots dos quan:

• Voleu treure l'operador de la cadena de confiança i tot i així necessiteu una cronologia, revocació, rols d'equip i una visualització que una previsualització d'enllaços no pugui activar. Pregunteu al proveïdor quins controls funcionen sobre el text xifrat i quins necessiten, sense dir-ho, el text sense xifrar.

Una eina de xifratge en línia és l'opció adequada?

Qui cerca una eina de xifratge en línia normalment vol una de dues coses: convertir un text en text xifrat que pugui enganxar a qualsevol lloc, o fer arribar un missatge confidencial a una persona de manera segura. La primera és una eina. La segona és un procés, i l'eina sola no el completa.

Una pàgina on enganxeu el text per xifrar-lo fa el xifratge al vostre navegador si està ben feta, cosa que podeu comprovar amb els passos de la secció de verificació de més avall. El que us deixa a vosaltres és tot el que envolta el text xifrat: triar una frase de contrasenya robusta, enviar-la per un canal separat, suprimir el text xifrat d'allà on l'hàgiu enganxat i esbrinar si el destinatari l'ha pogut desxifrar. Codificar no és xifrar, de manera que una eina de Base64 no protegeix res, i una frase de contrasenya feble és la manera habitual com falla a la pràctica el xifratge al navegador.

Un enllaç secret d'un sol ús fa el mateix xifratge al navegador i s'ocupa de la resta del procés: la clau viatja a la part de l'enllaç que va després del #, la còpia desada es destrueix la primera vegada que s'obre, l'enllaç caduca si ningú no l'obre i qui l'envia pot veure que s'ha mostrat. Per a un missatge a una persona, és el que encaixa millor. Per a un text xifrat que hàgiu de conservar vosaltres, o enganxar en un sistema que controleu, una eina local com age o GPG és millor que qualsevol pàgina web, perquè la clau no passa mai per un navegador.

Quan no fer servir cap dels dos

Alguns secrets no haurien de viatjar per cap enllaç. Les credencials d'administrador de llarga durada, les claus de signatura de producció i les exportacions massives de dades han d'estar en un gestor de secrets o un KMS amb control d'accés, no en un URL. I si el destinatari necessita el valor repetidament, un element a la caixa forta d'un gestor de contrasenyes és millor que tornar a enviar enllaços; el lliurament d'un sol ús és per a traspassos, no per desar. Enllaços secrets o gestors de contrasenyes traça aquesta línia.

Verificar una afirmació

No trieu una eina segons quina en promet més. Trieu segons allò de què us heu de defensar, i comproveu que el que diu l'etiqueta coincideix amb l'arquitectura que hi ha a sota:

• La clau és al fragment? Mireu l'estructura de l'enllaç; la clau ha d'anar després del #.
• Una petició simple a l'enllaç retorna el secret? No ho hauria de fer.
• Què fa la frase de contrasenya: controla l'accés a la visualització o forma part de la clau?
• Què es registra, i l'operador ho diu per escrit?

Les respostes de LinkPilot són a la pàgina d'arquitectura de seguretat, amb els límits inclosos. Aquella pàgina s'ha de sotmetre a la mateixa prova que la de qualsevol altre.

Lectures relacionades

• Com funcionen els enllaços secrets d'un sol ús
• És segur OneTimeSecret?
• LinkPilot o PrivateBin
• Enllaços secrets o gestors de contrasenyes
• Per què els URL filtren informació confidencial
• Els escàners d'enllaços i els secrets d'un sol ús

Referències

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.