Tudásbázis

Végponttól végpontig tartó titkosítás

A böngésződben készült OpenPGP-kulcsok. A másik OpenEmail-címre küldött leveled lezárható, mielőtt elhagyná a fület, a neked címzett lezárt levél pedig az olvasópanelen nyílik meg, a te gépeden visszafejtve. A kulcsok soha nem a mieink, hogy átadjuk őket.

Részletek

Mindkét fele végponttól végpontig be van kötve. Ha olyan címzettnek írsz, akinek a kulcsa közzé van téve, a törzs a böngészőben záródik le, mielőtt a kérés elhagyná; a kiszolgáló olyan páncélt kap, amelyet nem tud olvasni, pgp-mime jelölést tesz rá, és valódi multipart/encrypted üzenetet épít. Az olvasás ugyanígy fut visszafelé: a titkosított szöveg letöltődik, a fülön belül visszafejtődik, és közönséges levélként jelenik meg.
Az algoritmus ugyanaz, amit mindenki más is használ: OpenPGP, az openpgp.js révén, és PGP/MIME a vonalon. Egy v4-es kulcs Curve25519-en, ugyanaz a forma, amelyet a Proton ad ki, és amelyet a gpg állít elő az alapértelmezett modern algoritmusával. Vagyis az a levél, amelyet ez olvas, elvben ugyanaz a levél, amit a Thunderbird, a gpg és a Proton előállít, és itt semmi nem saját formátum, amelyet később vissza kellene fejteni.
A gyakorlatban viszont ez OpenEmail és OpenEmail között működik. Ebben a kódbázisban sehol nincs Web Key Directory, kulcskiszolgáló-lekérdezés vagy Autocrypt fejlécelemzés: a címzett kulcsa egyedül a saját címtárunkban található meg, amely az ebből az alkalmazásból közzétett kulcsokat tartja olyan emberektől, akiknek a címe itt üzemeltetett domainen van. Arra sincs mód, hogy kiadd a kulcsodat. Az alkalmazás közzéteszi a nyilvános feledet abban a címtárban, és nem kínál sem másolást, sem exportálást, tehát egy Thunderbirdöt használó levelezőpartnernek nincs támogatott módja megszerezni. A tágabb PGP-világgal való együttműködés a formátum tulajdonsága, nem olyasmi, amit a termék már megtesz helyetted.
Az olvasás nincs így korlátozva, mert a visszafejtéshez nem kell címtár. Minden PGP/MIME vagy beágyazott PGP-üzenet, amely ebbe a postafiókba olyan kulcsra lezárva érkezik, amely ebben a böngészőben megvan, megnyílik, bárki is küldte és bármilyen klienst használt. Ide tartoznak azok az üzenetek is, amelyek egy azóta lecserélt kulcsra lettek lezárva: a visszavont kulcsok a kulcstartóban maradnak, és a jelenlegi mellett azokat is végigpróbáljuk, tehát a csere nem kerül a már megkapott leveleidbe.
A zöld azt jelenti: megnyitva, és máshogy nem érhető el. A Részletek → Biztonság sor csak akkor vált zöldre, ha egy visszafejtés ebben a fülben ténylegesen nyílt szöveget adott vissza, soha nem az üzenet valamelyik mezőjéből, és soha nem abból, hogy titkosított boríték érkezett. Azt írja: „Végponttól végpontig titkosítva. Megnyitva a kulcsoddal ebben a böngészőben”. Minden, ami ennél kevesebb, saját mondatot kap, nem közöset: még keressük, a kulcs zárolva, olyan kulcsra lezárva, amely ebben a böngészőben nincs meg, nem sikerült megnyitni, itt egyáltalán nincs kulcs, és ez a böngésző nem engedte, hogy megnézzük. A „nem tudtuk ellenőrizni” és a „nincs meg a kulcsod” különböző állítások, és a sor rákényszerít, hogy elolvasd, melyiket kaptad.
Az S/MIME továbbra sem nyitható meg. Ez CMS egy X.509-es tanúsítvány alatt, az openpgp.js nem tud vele mit kezdeni, és a termékben nincs tanúsítványtár, amely a kulcsot tartaná, ha tudna, tehát az S/MIME-üzenet azt írja, hogy az OpenEmail nem tudja megnyitni, és nem is kap felkínált feloldást, amely semmit nem érne.
A privát fél a böngésződben jön létre, és soha nem hagyja el: sem titkosítva, sem mentésben, sem támogatói eszközben. A kiszolgáló soha nem kapja meg, tehát itt nincs mit átadni, bíróilag elkérni vagy kiszivárogtatni. Jelmondattal zárolva tárolódik egy saját IndexedDB-adatbázisban, az openemail-keyring nevűben, szándékosan távol a „töröld a gyorsítótárad” tanácstól és a hibakereső konzol visszaállításától: mindkettő letörli a lekérdezési gyorsítótárat, és egy mellette tárolt kulcs miatt a szokásos támogatói tanács végleg megsemmisítené a fiók által valaha kapott összes titkosított üzenetet. A fiókod törlése viszont törli, mert ott a levél is megy vele. A feloldás 15 perc tétlenségig, legfeljebb pedig 8 órán át tartja a memóriában, azután a következő lezárt üzenet olvasásakor újra kéri a jelmondatot.
Nincs letét és nincs helyreállítás, és ez végleges, nem megépítetlen. A jelmondatod az egyetlen bejárat; ha elfelejted, minden üzenet, amelyet bárki rád zárt, a kiszolgálóinkon marad titkosított szövegként, amelyet senki nem tud elolvasni, mi sem. A levél elveszett, és semennyi kérés nem hozza vissza. A regisztrációs képernyő ezt kimondja, mielőtt az első kulcs létrejönne, egy kötelezően kipipálandó jelölőnégyzet mögött, a mentési fájl kötelező, és a Kész gomb addig letiltva marad, amíg le nem töltötted. Az a fájl szándékosan az itteni böngésző extra nyugalmi védelme nélkül íródik, hogy a régebbi gpg-változatokba is importálható legyen: az a mentés, amelyet máshol nem tudsz megnyitni, nem mentés. A kulcs ráadásul egy eszköz egy böngészőjében él, és egy telefonon vagy egy második laptopon addig nincs semmi, amíg oda nem importálod azt a fájlt.
A címtár nyilvános kulcsokat tart és semmi mást, és a kulcs emberhez tartozik, nem postafiókhoz, hiszen egy címhez kötött kulcsot át kellene másolni mindenkihez, akivel az a cím meg van osztva, ami letét más néven. A kikereséshez bejelentkezett munkamenet és küldési jogosultság kell, soha nem nyilvános végpont, mert egy nyílt címvizsgálat olyan orákulum, amely bárkinek elárulja, mely címek élő postafiókok itt. Ugyanazt válaszolja arra, hogy „ezt nem mi üzemeltetjük”, és arra, hogy „mi üzemeltetjük, de senki nem tett közzé kulcsot”, mert a kettő megkülönböztetése csak bejelentkezés mögé tolná az orákulumot, nem szüntetné meg. És a kulcs kiadása abban a pillanatban megszűnik, amikor a tulajdonosa elveszíti a hozzáférését a címhez, nem akkor, amikor valakinek eszébe jut visszavonni.
Minden bájt a böngészőben záródik le abban a pillanatban, amikor leírod, és éppen ettől működnek egyáltalán a késleltetett küldések: az időzített vagy a visszavonási ablakban ülő üzenet titkosított szövegként tárolódik, és később egy olyan sor küldi el, amelynél nincs kulcs, és semmit nem tud elolvasni belőle. Az a címzett, akinek a címtári kikeresése MEGHIÚSULT, blokkolja a küldést, nem kerül csendben olyan kezelésbe, mintha nem lenne kulcsa. És a lezárt üzenet csak olyan úton megy ki, amely az üzenetet egészben viszi. Az a kimenő út, amely HTML-törzset venne át, a páncélt látható szövegként küldené el, és sikert jelentene, ezért az oda kerülő küldést elutasítjuk, mielőtt egyetlen bájt is elhagyná a gépet, nem utána.
Mibe kerül a lezárás, mérve, nem tippelve: a páncél nagyjából 1,86-szorosa a nyers bájtoknak, tehát a küldési út által megengedett 5 MB-ba körülbelül 2,7 MB melléklet fér bele, és a szerkesztő elutasítja az ennél nagyobb csomagot, mielőtt másodperceket töltene olyasmi titkosításával, amelyet a szállítás úgyis visszautasítana. A titkosított levél nem jelent megnyitást és kattintást, mert a címzettenkénti követés úgy működik, hogy a törzs személyenként változik, egyetlen lezárt blokk pedig nem tud változni, az átírt hivatkozás pedig olyan hivatkozás, amelyet mi olvasni tudunk, ami az állítás ellentéte. A titkosított küldés idempotenciakulccsal sem deduplikálható soha: a friss munkamenetkulcstól a titkosított szöveg minden próbálkozásnál más bájtsor, tehát az újrapróbálkozás sosem ad ugyanolyan ujjlenyomatot, mint az eredetije.
Az időzítés íráskor zár le, nem küldéskor. A szerkesztő azokkal a kulcsokkal építi a titkosított szöveget, amelyek a címzettjeidnél az írás napján vannak, nem azon a napon, amikor az üzenet elmenne; ezt a szabályt ez a termék már alkalmazza a sablonokra és a fordításokra, ahol az időzített üzenet azt viszi, amit jóváhagytál, nem azt, ami utána megváltozott. A különbség az, hogy egy elavult sablon csak elavult, egy elavult kulcs viszont olvashatatlan, ezért a szerkesztő szavakkal nevezi meg a dátumot ahelyett, hogy fenntartást kínálna: „Most lezárva, elküldve ekkor: …. Mindenkinek, aki rajta van, a ma meglévő kulcsára lesz szüksége.” A másik felét őrző elutasítás bekerült, de még soha nem szólalt meg, mert ilyen üzenet még nem létezhet: ha létezne, az utólagos szerkesztése elutasításra kerülne, nem csendben átmenne, hiszen a törzs javítása nyílt szöveget írna a titkosított szövegre, a címzettek módosítása pedig azt változtatná meg, kire lett lezárva, és bármelyik nyíltan kézbesít, miközben minden képernyő továbbra is titkosítottnak nevezi.
Két dolgot a szerkesztő egyáltalán nem kínál fel, és ezt ki is mondja, ahelyett hogy a vonalon bukna el. A sablon a kiszolgálón jelenik meg egy közzétett verzióból, tehát ebben a böngészőben nincs mit lezárni. A válasz pedig maga alá idézi a beszélgetést, és ez az idézet azután fűződik hozzá, hogy a törzs lezárult volna, így a teljes levélszál olvasható másolata a pecséten kívül maradna, tehát a válaszok és a továbbítások addig nem titkosíthatók, amíg az idézett előzmény be nem kerül a titkosított szövegbe.
Ebből semmi nem rejti el a tárgysorodat, azt, hogy kinek írtál, és azt, hogy mikor. A tárgy a lezárt üzeneten is nyíltan utazik, pontosan úgy, mint bármelyik máson, és az olvasópanel ezt magán az üzeneten kiírja: „A tárgy és a címek nyíltan utaztak; ez a szöveg nem.” A PGP a törzset fedi le, és semelyik megvalósítása nem fedi le a többit. A piszkozatok is lezáratlanok, mert az automatikus mentés írás közben folyamatosan nyílt szöveget ír a postafiókodba, mert a csendes nem-mentés munkát veszítene, és a lakat ezt szavakkal közli.
A lezártan érkező levél felismerése volt az első, és ez ma is áll. A PGP/MIME, a beágyazott PGP-páncél és az S/MIME korábban üres törzsként és két értelmetlen mellékletként jelent meg, mert az elemző csak a sima szöveget és a HTML-t tekinti olvashatónak, a többit pedig a fájlsávba ejtette. Ezek a részek most azonosítva vannak, a protokoll kelléktára kimarad a mellékletlistából, a titkosított szöveg sértetlenül tárolódik – ebből fejt vissza az olvasó, nem tölt le semmi újat –, és az az üzenet, amelyet itt senki nem tud megnyitni, ezt világosan ki is mondja.
Az aláírt üzenetet külön dologként kezeljük, mert az is. Az ilyennek a törzse olvasható, tehát a keresés, a szabályok és minden más tovább működik rajta; soha nincs lakat mögé zárva, és soha nem megy át visszafejtésen. A sor azt jelenti, hogy „A feladó aláírta. Az aláírás nincs ellenőrizve”, halványítva, és halvány is marad addig, amíg valami itt ténylegesen ellenőrizni nem tud egy aláírást, amit ma semmi sem tesz, azon az üzeneten sem, amelynek a visszafejtése sikerült. Látni, hogy egy üzenet lezárt, nem ugyanaz, mint megnyitni, és megnyitni nem ugyanaz, mint tudni, ki zárta le.
Titkosított üzeneten a törzset visszatartjuk mindentől, ami különben olvasná: a keresési részlettől, az adathalászat-pontozó törzsmenetétől, a mesterséges intelligenciára utaló ellenőrzéstől, a szabályok törzsfeltételeitől, a naptármeghívó-importtól és a levélszál-összefoglalóktól. Az adathalászat-ellenőrzés hitelesítési fele továbbra is fut, mert a DMARC, a DKIM és az SPF olyan fejlécekből olvasódik, amelyeket a titkosított szöveg nem rejt el. A visszafejtés ezen semmit nem változtat. A nyílt szöveg csak abban a fülben létezik, amelyik megnyitotta, tehát a lezárt üzenet kereshetetlen marad, és az olvasás után is kimarad a mesterséges intelligenciára épülő funkciókból, fordítást pedig nem kínálunk rá. Ez az állítás ára, nem hiányosság.