Preguntes freqüents
- Per què aquest lloc està mal traduït? ⎃
- Quina seguretat té aquest servei?
- Per què he rebut un enllaç aquí amb una opció per desxifrar un missatge?
- Voleu suprimir tot el contingut enviat a aquest lloc?
- Per què utilitzar aquest servei?
- És un servei de missatgeria?
- Quins són els casos d'ús previstos?
- Per a què no s’ha d’utilitzar aquest servei?
- Per què no només utilitzeu PGP / Signal / OMEMO / Matrix / etc.?
- Quins requisits existeixen?
- El destinatari pot fer una còpia del missatge?
- Es recopila informació personal?
- Quina informació es registra?
- Què feu per protegir els servidors?
- Quins riscos de seguretat hi ha quan s’utilitza aquest lloc?
- Què feu sobre els atacs home-al-mig (MITM)?
- Quins avantatges ofereixen les extensions del navegador?
- Com puc saber amb seguretat que tot el que s’envia està encriptat de cap a extrem?
- Com funciona el xifratge d'extrem a extrem en aquest lloc?
- La clau de desxifratge pot estar a l'URL?
- Però la clau de desxifratge no ha d’estar a l’URL?
- Aquest servei no lliura l'enllaç al destinatari?
- Com puc protegir la meva privadesa tant com sigui possible mentre utilitzo aquest servei?
- Què passa si no confio en els Estats Units?
- Què feu per evitar el correu brossa?
- Per què hi ha una opció per exigir al destinatari que completi un CAPTCHA?
- Qui gestiona aquest servei i per què és gratuït?
- Com puc confiar en les respostes a les preguntes anteriors?
Per què aquest lloc està mal traduït? ⎃
Ho sentim, però els autors actuals només parlen anglès. Necessitem ajuda per traduir aquest projecte a altres idiomes. Com a mitjà senzill i econòmic per fer disponible aquest servei a persones que no parlen anglès, utilitzem la traducció automàtica. Els resultats solen ser acceptables, però poden donar lloc a una redacció estranya o fins i tot a una informació completament inexacta. Podeu ajudar-nos a millorar l’experiència per a tothom; envieu la traducció correcta .
Quina seguretat té aquest servei?
Hem fet molts passos per garantir que aquest servei sigui segur per al seu ús previst . Abans de revisar aquests passos, és important entendre el següent:
- Tot i que no podem llegir el vostre missatge a causa d'un xifratge d'extrem a extrem , l'enllaç predeterminat generat conté la clau de desxifratge ; per tant, qualsevol persona que tingui l'enllaç pot llegir el vostre missatge, inclosa qualsevol persona que pugui interceptar-lo.
- Aquest servei és només una eina que permet l'enviament de comunicacions menys permanents (és a dir, missatges xifrats que s'esborren en recuperar-los) mitjançant transports tradicionals que són més permanents (és a dir, correu electrònic / text / missatgeria instantània / lloc web / etc.). Això significa que qualsevol problema de seguretat / privadesa inherent al transport escollit (és a dir, correu electrònic) s’hereta quan utilitzeu aquesta eina .
- Hi ha altres solucions disponibles que ofereixen una millor seguretat segons les vostres necessitats i entorn. El principal avantatge que ofereix aquest servei en comparació amb altres és que els requisits són molt més baixos per al destinatari (és a dir, només necessiten un navegador web i la possibilitat de fer clic en un enllaç).
- Tot i que la configuració predeterminada és suprimir missatges en recuperar-los, no hi ha res que impedeixi al destinatari fer una còpia . Tingueu en compte que això s'aplica a totes les solucions de missatges temporals; si el receptor pot veure el missatge, es pot copiar.
- Totes les comunicacions per Internet poden comprometre la vostra privadesa ; canvieu una mica de seguretat per comoditat.
- El web és un entorn difícil quan es tracta de seguretat a causa d’alguns problemes fonamentals : això s’aplica a tots els llocs web. Tanmateix, estar basat en la web fa que sigui molt més fàcil verificar la nostra afirmació que no podem llegir el vostre missatge .
- Aquest lloc web i la seva base de dades s’allotgen als Estats Units. Utilitzem Cloudflare, una empresa amb seu als Estats Units, com a xarxa de lliurament de contingut (tot el trànsit web travessa aquesta xarxa).
- L’ús del servei no requereix cap informació personal (és a dir, nom / correu electrònic / telèfon / etc.). No hi ha cap sistema de compte (és a dir, inici de sessió / contrasenya / etc.); per tant, qualsevol incompliment de dades no pot filtrar aquesta informació.
- Tot el contingut del missatge està xifrat de cap a extrem . En altres paraules, la clau de desxifrat mai no ens és enviada. Per tant, nosaltres, o qualsevol altra persona que tingui la base de dades, no tenim cap mitjà per desxifrar i visualitzar el contingut del missatge.
- Totes les entrades de la nostra base de dades tenen un temps de vida que oscil·la entre 1 minut i 2 setmanes (per defecte a 1 setmana). Un cop passat aquest temps, el registre se suprimeix automàticament. Per tant, qualsevol informació de la nostra base de dades se suprimirà poc després de la seva creació .
- Només mantenim les darreres 24 hores de registres de servidors web . Qualsevol informació IP emmagatzemada a la base de dades es comparteix de manera segura, cosa que impossibilita l'extracció de la IP original.
- Tot el codi que alimenta aquest servei és de codi obert i està disponible per revisar-lo. Podeu veure fàcilment el codi que executa el xifratge , que és intencionadament curt, concís i comentat.
- Es prenen diverses precaucions tècniques per ajudar a reforçar la seguretat, algunes de les quals inclouen:
- Tot aquest lloc web que no sigui / api és estàtic i no admet codi de servidor a les pàgines (és a dir, PHP / JSP / ASP / etc.)
- L’ API Web Crypto , que forma part del navegador, s’utilitza per xifrar tot el contingut dels missatges.
- TLS s’utilitza per xifrar les comunicacions entre el vostre navegador i els nostres servidors. Ajuda a garantir que el codi no es pugui interceptar ni modificar durant el trànsit. TLS 1.3 és compatible, però també admetem TLS 1.2 per a dispositius antics. Les versions anteriors de TLS estan desactivades perquè no són tan segures.
- Es registren els registres de transparència de certificats per detectar la mala emissió del certificat. A més, publiquem una política d’autorització de l’autoritat de certificació (CAA) per reduir el risc d’expedició no desitjada o malintencionada de certificats.
- Utilitzem HTTP Strict Transport Security (HSTS) per garantir que els navegadors sempre es comuniquen amb els nostres servidors mitjançant el protocol TLS. A més, incloem els nostres dominis a les llistes de precàrrega .
- S’aplica una política de seguretat de contingut estricta per evitar atacs de Cross Site Scripting (XSS) .
- Mitjançant l'ús d'una política de recursos d'origen creuat , un política Embebedor origen creuat , i una política d'obridor d'origen creuat , prohibim codi d'origen creu amb la finalitat d'ajudar a mitigar els atacs de canal lateral especulatius com Specter i desglaç. Això també ofereix protecció contra sol·licituds potencialment malicioses d'altres orígens, aïllant el context de navegació exclusivament a documents del mateix origen.
- Fem servir una política de permisos per evitar que el navegador carregui recursos que puguin comprometre la vostra privadesa, com ara la vostra ubicació, càmera web, micròfon, etc.
- DNSSEC s’utilitza en tots els nostres dominis per ajudar a mitigar els atacs MITM basats en DNS.
- Prenem diverses precaucions per protegir el servidor.
- No es carrega cap codi de tercers (és a dir, jQuery) i es carreguen molt pocs recursos (continueu i obriu la pestanya Xarxa a Eines de desenvolupament per comprovar-ho); això minimitza l'esforç necessari per auditar-lo. L'única excepció és si es requereix un CAPTCHA, que carrega el codi de tercers des de hCaptcha . Tot i això, el codi hCaptcha es carrega a la seva pròpia URL dins de les seves pròpies regles CSP i en cap moment té accés a res que tingui a veure amb un missatge.
- Com a mitjà per protegir-vos dels atacs MITM , hi ha disponibles extensions de navegador .
Per què he rebut un enllaç aquí amb una opció per desxifrar un missatge?
Disculpeu si hi ha errors en aquesta traducció . Aquest servei simplement transmet un missatge xifrat d’un punt a un altre i tu ets el destinatari. Aviat se suprimirà el missatge. Els operadors d’aquest servei no tenen manera de llegir el contingut del missatge. Normalment algú utilitza aquest servei quan no vol que el contingut d’un missatge quedi dins de diverses bases de dades / dispositius / serveis / fitxers / etc. com és habitual en enviar un correu electrònic / missatge instantani / text / etc. Si decidiu desxifrar, tingueu en compte el següent:
- És probable que el missatge se suprimeixi immediatament després d’enviar-lo al dispositiu per desxifrar-lo. Això vol dir que després de fer clic al botó per desxifrar el missatge, ja no tenim cap còpia per enviar-vos-la més tard.
- Eliminem sistemàticament tota la informació rebuda. Els missatges se suprimiran entre un minut o dues setmanes després de la creació, independentment de si el missatge es desxifra mai. Dit d’una altra manera, si heu de llegir el missatge, no espereu massa temps per desxifrar-lo.
- El remitent probablement creu que el contingut del missatge s’hauria de tractar amb cura. Fins i tot poden haver indicat que no volen fer còpies. Si us plau, respecteu els seus desitjos.
- Si se us demana una contrasenya per desxifrar un missatge, no tanqueu la finestra / pestanya del navegador. Segons el primer punt en aquesta llista, és probable que no en puguem enviar una altra còpia més endavant. Només cal que deixeu oberta la finestra / pestanya del navegador fins que pugueu introduir la contrasenya. Si introduïu una contrasenya incorrecta, se us demanarà de nou. Cal introduir la contrasenya amb precisió. Tingueu en compte que, per complir els requisits d’idiomes i contrasenyes diferents, acceptem molts caràcters diferents a les contrasenyes.
Voleu suprimir tot el contingut enviat a aquest lloc?
Fidel al logotip de la nostra paperera ... tot s'esborra poc després de rebre'l. La supressió de tot s’automatitza: s’escriu al servidor. Penseu-ho així: hi ha dues classes d'informació enviada:
- Missatges xifrats per als quals no tenim mitjans per desxifrar el contingut
- Altra informació inherent a l'enviament de qualsevol cosa al web (és a dir, la vostra adreça IP, etc.)
- Quant de temps hauríem de conservar el missatge si ningú el recupera (que oscil·la entre 1 minut i 2 setmanes, per defecte a 1 setmana).
- Quantes vegades es recupera el missatge (que oscil·la entre 1 i 100 vegades, per defecte a 1 vegada)
Per què utilitzar aquest servei?
Aquest servei és una eina per ajudar a fer que els missatges que envieu / rebeu siguin menys permanents. La majoria del que comuniqueu a Internet (xats, textos, correus electrònics, etc.) s’emmagatzema i rarament s’elimina. Sovint, quan suprimiu alguna cosa, en realitat no se suprimeix, sinó que es marca com a suprimit i ja no se us mostra. Les vostres comunicacions agregades s’acumulen any rere any en bases de dades i en dispositius sobre els quals no teniu control. Inevitablement, es pirateja una o més de les organitzacions / persones / dispositius que emmagatzemen les vostres comunicacions i es filtra la vostra informació. Aquest problema és tan generalitzat que ara hi ha molts llocs web que fan un seguiment de les organitzacions que han estat compromeses i han filtrat les dades dels usuaris. Els missatges temporals xifrats de punta a punta són una solució senzilla per ajudar a fer que algunes de les vostres comunicacions siguin menys permanents. Tots els missatges enviats a aquest lloc tenen un temps de vida que oscil·la entre 1 minut i 2 setmanes; un cop passat aquest temps, el missatge se suprimeix. A més, la configuració per defecte és suprimir qualsevol missatge un cop el destinatari l’hagi recuperat. A més, tots els missatges es xifren des del dispositiu fins al dispositiu del destinatari. L’objectiu principal d’utilitzar el xifratge extrem a extrem és eliminar la nostra capacitat de llegir qualsevol missatge enviat, eliminant així alguns dels requisits de confiança. El resultat final és que ara és fàcil enviar un missatge xifrat mitjançant un simple enllaç. Aquest missatge s’esborra poc després d’enviar-lo o després de recuperar-lo. No cal instal·lar / configurar programari especial. No cal que creeu cap compte ni proporcioneu cap informació personal. El destinatari no ha d’estar als vostres contactes ni tan sols conèixer aquest servei, l’únic requisit que pot fer clic en un enllaç.
És un servei de missatgeria?
No, aquest servei està dissenyat per complementar els serveis de missatgeria existents, com ara missatgeria instantània / correu electrònic / text / etc. afegint la possibilitat d’evitar que els missatges enviats s’emmagatzemin durant molt de temps. No lliurem l'enllaç generat al destinatari .
Quins són els casos d'ús previstos?
Quins són alguns escenaris en què és adequat utilitzar aquest servei? Tot i que tothom té necessitats i requisits diferents pel que fa a la seva privadesa i seguretat, personalment he trobat els casos següents com a casos d’ús adequats:
- Heu estat comunicant a través d’un fòrum web local sobre les rutes de bicicleta de muntanya de la zona i, de vegades, us heu reunit amb gent del fòrum per comprovar els senders nous junts. Algú del fòrum vol recollir-vos al vostre lloc per compartir un cotxe a un sender aquest cap de setmana. No voleu que la vostra adreça de casa estigui permanentment en aquesta base de dades del fòrum del lloc web. Simplement envieu l'adreça a través d'aquest servei: l'enllaç és el que resideix a la base de dades del fòrum del lloc web, però un cop llegit pel destinatari, el missatge / adreça s'elimina.
- Heu d’enviar al vostre germà el vostre inici de sessió a Netflix perquè la vostra neboda el torna boig a causa del bloqueig de COVID i encara no té el seu propi compte. No us importa massa aquest inici de sessió, però el vostre germà és especialment dolent en el que anomenaré "higiene digital" i ha tingut moltes proves amb inicis de sessió i programari maliciós compromesos. Els intents posteriors per fer-lo netejar i fins i tot instal·lar-li missatgeria segura no s'han pogut mantenir. Simplement enviar-lo mitjançant un missatge de text és probablement la millor opció (per desgràcia), però no us sentiu còmode que tingueu aquest inici de sessió al seu historial de missatges a causa de l’experiència passada. Si utilitzeu aquest servei per enviar l’inici de sessió mitjançant un enllaç en un missatge de text, no és possible que l’inici de sessió quedi permanentment al seu historial de xats.
- De vegades treballes en una oficina que compta amb molts inquilins compartits que vénen i surten a totes hores. Hi ha WiFi disponible per utilitzar-lo, però la contrasenya es gira cada setmana des que hi ha hagut problemes d’abús. Molts inquilins envien un missatge de correu electrònic o envien un missatge de text per demanar la contrasenya WiFi, tot i que es troba a la recepció perquè la majoria no hi accedeixen per l'entrada principal. Mitjançant aquest servei, el gerent de l’oficina pot enviar la contrasenya WiFi a través d’un enllaç en una resposta de correu electrònic / text que no permet que la contrasenya perduri, i també permet al destinatari copiar immediatament la contrasenya mitjançant un botó de còpia que és menys maldestre als dispositius mòbils.
- Un dels vostres proveïdors d’allotjament us demana informació sobre un servidor que heu informat que mostra signes d’un disc dur que sembla funcionar malament. Part de la informació que necessiten és una mica sensible: no voleu que quedi per sempre al sistema de tiquets que utilitzen. Mitjançant aquest servei, podeu enviar la informació als tècnics d'assistència sense que resideixi al sistema de tiquets. Com que és possible que diversos tècnics hagin de referir-se a la informació diverses vegades, configureu la lectura per a la vida superior a 1 (és a dir, potser 20) de manera que el missatge no se suprimeixi en la primera recuperació.
- Cal que envieu un missatge privat a un altre usuari de Reddit per fer-li saber el vostre número de telèfon perquè us pugui trucar. Reddit, com molts altres proveïdors, ha filtrat informació d’usuari en el passat i no voleu que el vostre número de telèfon només estigui a la base de dades de Reddit durant anys fins a la propera filtració. Simplement envieu el vostre número de telèfon mitjançant aquest servei.
Per a què no s’ha d’utilitzar aquest servei?
Aquest servei no s’ha d’utilitzar per obtenir informació molt confidencial per tots els motius explicats en aquest FAQ. A continuació es mostren alguns exemples de què no cal fer:
- No utilitzeu aquest servei per fer un transport de missatges inadequat "més segur". Com que la configuració predeterminada és incloure la clau de desxifratge a l'URL que pot llegir el missatge, qualsevol persona que tingui l'enllaç pot llegir-lo. Com s'ha esmentat anteriorment, qualsevol problema de seguretat / privadesa inherent al transport escollit (és a dir, un text) s'hereta quan utilitzeu aquesta eina. Per exemple, si mai no us plantejaríeu utilitzar el correu electrònic per enviar informació específica a causa del seu caràcter sensible, no hauríeu d'utilitzar aquest servei per "protegir" aquesta part del correu electrònic.
- No utilitzeu aquest servei per assegurar-vos que no es faci cap còpia del missatge. El fet que suprimim la nostra còpia del missatge xifrat immediatament després de recuperar-lo i en fem més difícil la còpia, no vol dir que no es pugui copiar el missatge. Què passa si el destinatari fa una foto de la seva pantalla? I si només escriuen el missatge? En definitiva, si el destinatari pot llegir el missatge, es pot fer una còpia.
- No utilitzeu aquest servei per assegurar-vos que no es pugui rastrejar cap missatge. Aquest servei depèn d'un altre proveïdor de transport de missatges (és a dir, correu electrònic, xat, etc.) per fer arribar el missatge d'un punt a un altre. El transport de missatges utilitzat podria molt bé rastrejar-lo.
- No utilitzeu aquest servei per enviar res que vulgueu negar l'enviament. El fet de suprimir el missatge en si no significa que s’elimini l’enllaç que apunta al missatge suprimit. Si envieu un correu electrònic al vostre amic i una part d’aquest correu electrònic té un enllaç a un missatge d’aquest servei, un lector casual sabrà que hi havia alguna cosa més al missatge. Fins i tot si el missatge a què fa referència l'enllaç ja fa temps, és evident que es va enviar una altra cosa i que el vau enviar al vostre amic.
Per què no només utilitzeu PGP / Signal / OMEMO / Matrix / etc.?
Si coneixeu la persona que voleu enviar missatges temporals segurs, envieu-los sovint, espereu una interfície semblant al xat i / o pugueu esperar que el destinatari tingui el programari requerit i el sàpiga utilitzar, probablement aquest lloc web no sigui millor solució. Hi ha opcions fantàstiques que són de codi obert, suporten E2EE, no basades en web, i fins i tot algunes com Signal que també admeten missatges temporals. Personalment utilitzo un servidor privat XMMP i OMEMO per xatejar amb amics i familiars propers. L’ús d’aquest lloc només pot ser òptim si no sabeu quin és el programari que executa el destinatari, no coneixeu el seu número de telèfon / contacte, ni coneixeu el seu coneixement tècnic (però suposeu que poden fer clic a un enllaç), o simplement preferiu mantenir el missatge que envieu fora del transport de comunicació subjacent.
Quins requisits existeixen?
Es requereix un navegador web modern i actualitzat que implementi correctament estàndards que incloguin l'API Web Crypto. Alguns exemples són: Chrome, Firefox, Edge i Safari (vers 2020 o després).
El destinatari pot fer una còpia del missatge?
Sí. Tot i que el missatge es pot esborrar a si mateix quan es recupera, el destinatari encara pot visualitzar-lo. Sempre que el receptor pot visualitzar completament el missatge, es pot fer una còpia, això s'aplica a totes les comunicacions. Hi ha una opció per dificultar la realització d’una còpia per al destinatari. En aquest cas, s’implementen tres impediments per copiar:
- S'elimina el botó Copia. Per defecte, aquest botó permet al destinatari copiar tot el missatge al porta-retalls.
- S'elimina el botó Baixa. Per defecte, aquest botó permet al destinatari descarregar el missatge com a fitxer de text.
- S'elimina la possibilitat de seleccionar text dins del quadre de text del missatge.
Es recopila informació personal?
No admetem comptes d'usuari (és a dir, nom d'usuari / contrasenya). No recopilem cap informació que pugui identificar-lo (és a dir, nom / adreça / correu electrònic / telèfon). És possible que hi hagi informació personal al missatge que envieu, però està encriptada i no tenim manera de llegir-la. Consulteu la nostra política de privadesa per obtenir detalls complets.
Quina informació es registra?
El nostre servidor web manté fins a 24 hores de format de registre comú en tota l'activitat web. Això inclou el registre de l'adreça IP completa dels clients HTTP. Després de 24 hores, aquesta informació registrada s'elimina automàticament. Totes les sol·licituds enviades a / api es publiquen, cosa que significa que el servidor web no registra mai cap informació específica del missatge. A més, es registra eficaçment tota la informació guardada a la base de dades. Totes les entrades de la base de dades, incloses les adreces IP anonimitzades i resumides, tenen un temps de caducitat (TTL) després del qual se suprimeixen automàticament. Els terminis de caducitat del TTL varien entre 1 minut i 2 setmanes.
Què feu per protegir els servidors?
La seguretat del servidor és una preocupació òbvia. Hi ha dues àrees principals en què ens centrem per mantenir-la segura:
- En primer lloc, emmagatzemem el mínim possible durant el mínim temps possible, de manera que si el servidor es veu compromès, qualsevol filtració d’informació no seria perjudicial per als nostres usuaris. Tots els missatges emmagatzemats a la base de dades estan encriptats sense cap mètode per desxifrar-los. No hi ha res emmagatzemat que enllaci cap missatge a cap dels nostres usuaris, ja que no recopilem informació personal dels nostres usuaris. Tots els registres de la base de dades tenen un temps de caducitat (TTL) que oscil·la entre 1 minut i 2 setmanes; un cop passat aquest temps, el registre se suprimeix automàticament. Per tant, la gran majoria de la informació que hi ha hagut a la base de dades ja es va esborrar fa molt de temps.
- Prenem diverses mesures per evitar compromisos i contenir qualsevol compromís que es produeixi:
- El servidor web, nginx , s’executa en un contenidor aïllat com a usuari sense privilegis sense accés d’escriptura a cap altra cosa que no siguin registres. El contenidor s’executa dins del seu propi context SELinux, evitant encara més qualsevol canvi de sistema de fitxers o fàcil fugida del contenidor. No hi ha suport per a PHP / ASP / JSP / etc. - només servir recursos estàtics.
- El codi que s’executa / api s’escriu a Go, cosa que hauria de fer que sigui bastant resistent a les vulnerabilitats de desbordament de memòria intermèdia (un vector d’atac comú). El procés Go també s'executa en un contenidor aïllat com a usuari sense privilegis sense accés d'escriptura a cap altra cosa que la base de dades. El contenidor s’executa dins del seu propi context SELinux, evitant encara més qualsevol canvi de sistema de fitxers o fàcil fugida del contenidor. La base de dades, badgerdb , forma part del procés Go (no hi ha cap procés de dependència / base de dades externa).
- El principal perill d'un compromís del servidor és que l'atacant pugui modificar fitxers d'una manera que comprometi la privadesa / seguretat dels nostres usuaris. Un procés dedicat controla tots els fitxers del lloc web de qualsevol canvi i ens avisa immediatament en cas que hi hagi algun canvi.
- Tot l'accés administratiu està protegit i limitat a xarxes autoritzades.
Quins riscos de seguretat hi ha quan s’utilitza aquest lloc?
Abans d'abordar específicament alguns d'aquests riscos, crec que una analogia semi-breu pot ajudar a resumir els riscos de l'ús de qualsevol comunicació a Internet. Visualitzeu que qualsevol sistema només és tan segur com l’enllaç més feble d’una cadena. Imagineu-vos ara un escenari en què hi hagi dues persones en una habitació tancada sense mitjans per veure, escoltar ni enregistrar res del que fan. Un passarà un missatge a l’altre que en llegir-lo el cremarà. Si algú fora d’aquesta sala vol obtenir el missatge que ja s’havia aprovat, serà difícil. Quin és l’enllaç més feble per obtenir el missatge? No hi ha tants enllaços per triar: és una cadena força curta. Ara imagineu-vos que quan envieu un missatge a Internet que hi ha almenys un milió d’enllaços a la cadena –molts d’ells febles - molts d’ells totalment fora del vostre control– i això és realitat.
L’ús del xifratge pot ajudar molt amb el problema de l’enllaç anterior i és fàcil d’atraure pensant que els sistemes E2EE ben dissenyats ofereixen la solució final. Tanmateix, aquest pensament pot posar-vos en problemes, perquè un atacant normalment sol buscar els enllaços més febles del sistema. Per exemple, probablement sigui molt més fàcil agafar el vostre telèfon o ordinador i configurar un registrador d’entrada per llegir tot el que escriviu que trencar missatges xifrats per cable. La conclusió és que si m’encarregués de comunicar un secret d’importància vital / crítica, només utilitzaria les comunicacions electròniques com a mètode d’últim recurs.
Per tant, hi ha riscos de seguretat mitjançant qualsevol comunicació, però encara utilitzeu un navegador web per fer banca, comprar articles, correu electrònic, etc. És un risc acceptat per les enormes comoditats adquirides. Realment la pregunta és ... quins riscos de seguretat són semespecífics d’aquest lloc? Alguns em vénen al cap:
- Potser el risc més gran i el més exclusiu d’aquest servei és que els nostres usuaris no facin un bon criteri a l’hora de discernir entre allò que és adequat enviar i allò que no és adequat enviar . De vegades, la distinció entre "Estic còmode enviant aquesta informació enviant un missatge de correu electrònic (només desitjo que se suprimeixi després de llegir-la)" i "No em sento còmode enviant aquesta informació enviant un missatge de correu electrònic: el correu electrònic és un transport inadequat" pot ser força subtil.
- Sempre hi ha l'amenaça que els operadors d'aquest lloc són realment uns actors dolents que atreuen la gent a utilitzar el servei per aconseguir un objectiu final fosc. Ens trobem amb un plausiblement fiable (ho fem tot fàcil i gratuït), que aconsegueix molta gent que utilitza el servei, tot amb una intenció sinistra. Bwhahahahaha! Com podríeu confiar en nosaltres?
- Hi ha la possibilitat que el nostre codi tingui errors que afectin la seguretat o simplement no pensem bé les coses i ara les nostres mancances exposen els nostres usuaris a un perill innecessari. Esperem que no, però no ho podem descartar.
- A diferència dels tech-titans (és a dir, Google / Facebook / Whatsapp) que tenen terabits de dades encriptades que flueixen constantment dins i fora de les seves enormes xarxes, on és fàcil que les comunicacions privades es combinin amb altres serveis de trànsit i centralitzats independents (és a dir, Signal, Telegram i nosaltres) destaquen. És fàcil que un operador de xarxa o fins i tot una gran organització / govern vegi que l’adreça IP xxxx utilitza el servei XYZ.
- Tot i que no és realment específic d’aquest lloc, ja que es pot utilitzar contra qualsevol lloc web, els atacs man-in-the-middle (MITM) són una preocupació vàlida .
Què feu sobre els atacs home-al-mig (MITM)?
Tots els usuaris de llocs web poden ser víctimes d’un atac MITM: aquest lloc no és diferent de tots els altres que hi ha al web en aquest sentit. Un atac MITM és quan un atacant és capaç d'interceptar i modificar les comunicacions entre el navegador de l'usuari i el servidor web del lloc. Això permet a l'atacant modificar qualsevol codi o contingut del lloc mentre apareix a l'usuari final com el lloc al qual està acostumat. Prenem algunes mesures per fer més difícil un atac MITM:
- HSTS s’utilitza per obligar els navegadors a connectar-se només mitjançant TLS. El nostre servidor està configurat per ignorar la comunicació que no sigui TLS que no sigui per redirigir. Només s’admet TLS 1.2 o superior.
- DNSSEC s’utilitza per signar la zona del nostre domini. Això podria aturar la falsificació del DNS dels atacs MITM implementats si l'usuari utilitza un resolutiu recursiu conscient de DNSSEC.
- Utilitzem un servei per supervisar les autoritats certificadores que emeten certificats TLS no autoritzats que facin referència al nostre domini.
- Hem publicat extensions de navegador per donar suport al xifratge de missatges mitjançant el codi emmagatzemat al dispositiu de l'usuari final.
Quins avantatges ofereixen les extensions del navegador?
Oferim extensions de navegador com a mitjà per proporcionar comoditat i seguretat addicionals. En poques paraules ... Les extensions faciliten i envien missatges temporals. També es guanya certa seguretat perquè tot el codi utilitzat per xifrar i preparar un missatge s’emmagatzema localment dins de l’extensió. Com que el codi s’emmagatzema localment, això ofereix al remitent certa protecció contra atacs MITM . No obstant això, val la pena assenyalar que, si bé les extensions ofereixen més protecció contra un atac MITM que compromet el contingut del missatge, un atac MITM encara podria ser eficaç (és a dir, determinar l'adreça IP del remitent si no s'utilitza TOR / VPN / etc.).
Com puc saber amb seguretat que tot el que s’envia està encriptat de cap a extrem?
A diferència de molts altres populars clients de xat encriptats de punta a punta (E2EE), és bastant senzill veure exactament el que ens envia quan envieu un missatge. El tutorial de vídeo següent mostra com confirmar que no tenim manera de desxifrar els missatges enviats al servidor.
A més, si us hi plantegeu, sempre que no siguem cap agència secreta que intenti recollir missatges sensibles, no podrem desxifrar missatges, ja que tenir aquesta capacitat només ens crea problemes. Ni tan sols volem emmagatzemar missatges, però és un mal necessari per enviar-los.Com funciona el xifratge d'extrem a extrem en aquest lloc?
En aquest moment, estem utilitzant xifratge simètric (AES-GCM 256bit) amb claus derivades de contrasenyes (mínim de 200.000 iteracions de PBKDF2 + SHA-256). El xifratge asimètric no s’utilitza perquè existeixen requisits per a 1) l’emissor que inicia la comunicació 2) l’emissor i el destinatari no estan en línia alhora i 3) no hi ha informació sobre el destinatari i 4) intentem que les coses siguin reals senzilles i la gestió de claus sigui complicat. L'API web Crypto estàndard s'utilitza per a totes les funcions criptogràfiques, inclosa la RNG. Bàsicament, això és el que passa:
- L'usuari final introdueix un missatge de text i pot especificar diverses opcions, inclosa una contrasenya.
- Es genera una contrasenya segura per obtenir una clau. Si l'usuari ha especificat una contrasenya, es combina amb la contrasenya generada.
- Es fa una trucada a l'API per obtenir el nombre d'iteracions PBKDF2 + SHA-256 necessàries (aquest pas és necessari per al control de correu brossa )
- Es genera una sal de 32 bytes
- Una clau es deriva de la sal i la contrasenya
- Es genera un vector d’inicialització de 12 bytes (IV)
- El missatge es xifra mitjançant la clau i IV.
- El recompte d'iteracions, salt, IV i text xifrat s'envien al servidor (juntament amb alguna altra informació com TTL, RTL, etc.)
- El servidor retorna una identificació aleatòria que fa referència al missatge
- A continuació, el navegador presenta a l’usuari final un enllaç que després es pot compartir amb un destinatari. Tota la informació sobre el missatge es guarda al component hash de l'URL i, per tant, no s'envia al servidor durant una sol·licitud GET estàndard.
- L'enllaç es comparteix amb un destinatari.
- Al destinatari se li demana si vol desxifrar i veure el missatge.
- Quan el destinatari tria veure el missatge, el navegador fa una sol·licitud especificant l'identificador del missatge.
- Si el remitent requereix que es completi el CAPTCHA, el destinatari es dirigeix a un altre URL per demostrar que és humà (un cop superat es torna cap enrere).
- El servidor envia el missatge xifrat i, de manera predeterminada, suprimirà el missatge en aquest moment si el text de lectura en directe (RTL) és un.
- El destinatari desxifrarà el missatge i se li demanarà una contrasenya si cal.
La clau de desxifratge pot estar a l'URL?
Sí. Si no s’utilitza una contrasenya, qualsevol persona amb l’enllaç pot llegir el missatge. Això, òbviament, afecta la seguretat perquè si es pot interceptar el mètode utilitzat per enviar l'enllaç, es podrà interceptar el missatge. Totes les solucions per eliminar aquest problema introdueixen passos i complexitats addicionals que afecten l'experiència de l'usuari (és a dir, les coses s'han de configurar en els dos extrems abans d'enviar el missatge). En última instància, si dues parts s’enviaran missatges mútuament amb freqüència, existeixen millors solucions suposant que ambdues parts puguin gestionar l’ús d’aquestes solucions.
Però la clau de desxifratge no ha d’estar a l’URL?
Correcte. L’autor del missatge pot especificar una contrasenya per protegir-lo. Aquesta contrasenya s'utilitza per obtenir una clau secreta que no forma part de l'URL . Si s’utilitza una contrasenya segura i es comunica de manera segura al destinatari (o ja ho saben), proporciona protecció contra les interceptacions. No obstant això, l’inconvenient és que el destinatari ha de conèixer i introduir correctament la contrasenya. Aquí teniu una manera d’enviar la contrasenya al destinatari que ofereix una certa protecció contra la intercepció:
- Xifreu la contrasenya en un missatge amb la configuració predeterminada i envieu aquest enllaç al destinatari.
- Quan el destinatari fa clic a l'enllaç i desxifra el missatge, sap que ningú més no ha obtingut la contrasenya perquè el missatge que conté la contrasenya s'esborra quan es recupera. No obstant això, si hi ha un atac MITM actiu o si el dispositiu o el dispositiu del destinatari han estat compromesos, encara és possible que una altra part pugui obtenir la contrasenya.
- Confirmeu amb el destinatari que han obtingut correctament la contrasenya. Per exemple, si el destinatari us informa que quan va anar a recuperar la contrasenya que el missatge ja havia estat esborrat, sabeu que algú ha obtingut la contrasenya abans que el destinatari i que, per tant, la contrasenya es troba compromesa i no s’hauria d’utilitzar.
- Mitjançant la contrasenya que el destinatari va confirmar que posseïa, ara podeu enviar un missatge amb la mateixa contrasenya per xifrar.
Aquest servei no lliura l'enllaç al destinatari?
Això és correcte: generem l'enllaç i deixem al remitent la millor manera de lliurar-lo al destinatari. L'objectiu d'aquest servei és proporcionar una opció que ofereixi menys permanència en transports de missatges existents com ara correu electrònic / xat / text / etc. Per tant, l’expectativa és que l’enllaç que generem que apunti al missatge temporal s’enviï mitjançant un transport de missatges existent. Això té implicacions de seguretat que els usuaris haurien d’entendre. Prenem un missatge de text SMS com a exemple, ja que es tracta d’un mètode de comunicació força insegur. Quan utilitzeu aquest servei per enviar un missatge temporal, amb la configuració predeterminada, qualsevol persona amb l'enllaç pot llegir el missatge i no s'ofereix cap protecció contra la intercepció. Aquest servei encara proporciona una comunicació més temporal que pot millorar la privadesa i la seguretat. A més, es pot utilitzar una contrasenya per proporcionar protecció contra les interceptacions.
Com puc protegir la meva privadesa tant com sigui possible mentre utilitzo aquest servei?
Tal com es comenta en altres preguntes d’aquestes PMF, tot i que ja fem moltes coses per protegir la vostra privadesa i, tot i que no recopilem cap informació personal, algunes de les informacions relacionades amb els registres les enviam i recopilem en virtut de la vostra utilització d’un navegador web. Tot i això, hi ha diverses maneres de protegir encara més la vostra privadesa. Una manera d’utilitzar de manera gratuïta, basada en programari de codi obert i que funciona força bé, és utilitzar el navegador Tor . Aquest navegador està dissenyat per protegir la vostra privadesa en diversos nivells, inclòs l’ús de la xarxa Tor . El nostre lloc ja és accessible a través de la xarxa de ceba Tor, el que significa que l'accés al nostre lloc mitjançant Tor no requereix l'ús d'un node de sortida, cosa que nega algú que escolta el trànsit del node de sortida . Tot i això, tingueu en compte que, fins i tot en aquest escenari, el vostre proveïdor d'Internet pot veure que utilitzeu Tor, tot i que no per a què. Fins i tot podeu connectar-vos a una VPN i després iniciar el navegador Tor per obtenir dues capes d’anonimat; Tanmateix, tingueu en compte que el vostre proveïdor d'Internet encara pot veure que utilitzeu una VPN en aquest escenari, tot i que no per a què. Si no voleu que el vostre proveïdor d'Internet conegui quins protocols utilitzeu, podeu connectar-vos a una gran xarxa WiFi pública, com ara una biblioteca, un centre educatiu, etc. i després utilitzar el navegador Tor.
Què passa si no confio en els Estats Units?
Els nostres servidors es troben als Estats Units. A més, el nostre proveïdor de CDN, Cloudflare, és una empresa amb seu als Estats Units. Hem intentat eliminar la necessitat de confiar en nosaltres o en el país on resideixen els nostres servidors simplement perquè no recopilem informació personal, no podem desxifrar cap missatge i tot s’esborra poc després de rebre’ls. Tot i això, podem entendre certa desconfiança, ja que es basa en la web i, sobretot, si resideu en determinats països. Tenim alguns plans per oferir opcions a Islàndia i Suïssa per a persones a qui els costa confiar en els Estats Units. Si us plau, feu-nos-ho saber , ja que no estarem motivats a oferir alternatives tret que hi hagi una demanda real.
Què feu per evitar el correu brossa?
Sempre que permeteu que algú publiqui un missatge que es pugui retransmetre mitjançant un enllaç, convideu els spammers. Resoldre aquest problema no és del tot senzill. No volem carregar cap CAPTCHA de tercers com a part del procés d’enviament de missatges per alguns motius:
- Odiamos els CAPTCHA: triguen temps i són molestos
- La càrrega de JavaScript de tercers pot ser invasiva per a la privadesa i la seguretat
- Executar el nostre propi CAPTCHA significa que ens inscrivim en un joc interminable de whack-a-mole
- Finalment, és possible que la gent vulgui poder interactuar amb aquest servei mitjançant l'API
- S’incrementa el nombre d’iteracions PBKDF2 / SHA-256 necessàries
Tots els missatges només es poden recuperar un nombre reduït de vegades, un atribut poc atractiu per als spammers, ja que depenen d’enviar molts missatges. Com que un spammer hauria de crear molts missatges per a qualsevol campanya de correu brossa, hem optat per fer que aquesta tasca sigui tan costosa computacionalment com per fer que abusar d’aquest servei per correu brossa sigui un esforç poc atractiu. Això s'aconsegueix fent un seguiment de les xarxes que publiquen missatges, mesurats en termes de recuperacions possibles totals. La informació de la xarxa en si es comparteix de manera segura de manera que no podem inferir la xarxa real a partir del hash. A mesura que una xarxa concreta publica més missatges, augmentem el nombre d’iteracions PBKDF2 / SHA-256 necessàries per publicar el següent missatge. Això fa que es requereixi molt de temps de CPU només per publicar un sol missatge. Esperem que aquest mètode sigui adequat per frenar l'abús de correu brossa i, al mateix temps, no afectar els usuaris reals. - Recopileu informes de correu brossa dels usuaris quan recuperin un missatge
Hi ha un botó "Informa de correu brossa" just a sota del missatge quan un usuari recupera un missatge. Si un missatge és correu brossa, esperem que alguns trigin els 3 segons necessaris a fer clic al botó. Quan rebem un informe de correu brossa, ens avisa i també afecta els impactes de les iteracions PBKDF2 / SHA-256 necessàries per a una xarxa determinada.
Per què hi ha una opció per exigir al destinatari que completi un CAPTCHA?
Si bé és cert que no ens agraden els CAPTCHA, reconeixem que serveixen per a un propòsit i tenen un temps i un lloc (almenys per ara). Aquesta és una manera senzilla perquè l’emissor tingui la seguretat que el destinatari és humà i que els processos automatitzats no accedeixen al missatge.
Qui gestiona aquest servei i per què és gratuït?
Només som un parell de nois que de vegades teníem la dificultat de no tenir bones opcions per ajudar a protegir la nostra privadesa. Sovint això resultava de comunicar-se amb amics i familiars que no tenien gaire cura amb la manera com manegaven els seus dispositius i informació. En altres ocasions, això es produïa quan s’utilitzaven fòrums basats en web com Reddit o s’utilitzaven sistemes de suport basats en web. Hem trobat algunes solucions de missatges temporals basades en web, però cap ha ofert E2EE, cosa que significa que no podíem confiar en elles. Per tant, acabem de construir la nostra pròpia solució i decidim donar-la perquè altres es puguin beneficiar d’ella.
Com puc confiar en les respostes a les preguntes anteriors?
Realment, no hauríeu de confiar en cap lloc web només perquè diu certes coses; normalment és una bona idea verificar qualsevol reclamació. Hem intentat eliminar el requisit de confiar en nosaltres el màxim possible mitjançant l'ús del xifratge d'extrem a extrem. Per exemple, és bastant fàcil d’ auditar que no podem llegir cap missatge ja que estan encriptats . També hem mantingut el codi javascript que fa funcionar aquest lloc molt senzill perquè sigui fàcil de llegir i entendre. Fer que tot el codi sigui de codi obert permet a la gent verificar el que s’està executant; no obstant això, tingueu en compte que no hi ha manera de verificar realment el que està executant el servidor. Tot i que és cert que gran part del requisit de confiança s’elimina amb el xifratge d’extrem a extrem, continua sent un factor que pesen molt els nostres usuaris a l’hora de decidir utilitzar aquest servei o no.