Gyakran Ismételt Kérdések
- Miért van rosszul lefordítva ez az oldal? ⎃
- Mennyire biztonságos ez a szolgáltatás?
- Miért kaptam itt egy linket az üzenet visszafejtésének lehetőségével?
- Törölsz mindent, amit erre a webhelyre küldtek?
- Miért használja ezt a szolgáltatást?
- Ez egy üzenetküldő szolgáltatás?
- Melyek a tervezett felhasználási esetek?
- Mire ne használja ezt a szolgáltatást?
- Miért nem csak a PGP / Signal / OMEMO / Matrix / stb.
- Milyen követelmények vannak?
- Készíthet másolatot a címzett az üzenetről?
- Gyűjtenek személyes adatokat?
- Milyen információkat naplóznak?
- Mit tesz a szerverek biztonsága érdekében?
- Milyen biztonsági kockázatok vannak jelen webhely használatakor?
- Mit csinál az ember a közepén (MITM) támadásokkal kapcsolatban?
- Milyen előnyöket kínálnak a böngészőbővítmények?
- Honnan tudhatom biztosan, hogy bármi beküldött tartalom titkosítva van?
- Hogyan működik a végpontok közötti titkosítás ezen a webhelyen?
- A visszafejtési jelszó lehet az URL-ben?
- De a visszafejtési jelszónak nem kell szerepelnie az URL -ben?
- Ez a szolgáltatás nem juttatja el a linket a címzetthez?
- Hogyan védhetem meg a magánéletemet a lehető legnagyobb mértékben a szolgáltatás használata közben?
- Mi van, ha nem bízom az Egyesült Államokban?
- Mit tesz a spam megakadályozása érdekében?
- Miért van lehetőség a CAPTCHA kitöltésére a címzetttől?
- Ki üzemelteti ezt a szolgáltatást, és miért ingyenes?
- Hogyan bízhatok meg a fenti kérdésekre adott válaszokban?
Miért van rosszul lefordítva ez az oldal? ⎃
Sajnáljuk, de a jelenlegi szerzők csak angolul beszélnek. Segítségre van szükségünk a projekt más nyelvekre történő lefordításához. Gépi fordítást alkalmazunk egyszerű és olcsó eszközként, hogy ezt a szolgáltatást elérhetővé tegyük az angolul nem beszélő emberek számára. Az eredmények általában elfogadhatóak, de furcsa megfogalmazást vagy akár teljesen pontatlan információkat is eredményezhetnek. Segíthet javítani a felhasználói élményt mindenki számára - kérjük, küldje el a helyes fordítást .
Mennyire biztonságos ez a szolgáltatás?
Sok lépést megtettünk annak érdekében, hogy ez a szolgáltatás biztonságos legyen a rendeltetésszerű használat szempontjából . Mielőtt átmennénk ezeken a lépéseken, fontos megértenünk a következőket:
- Noha a végpontok közötti titkosítás miatt nem tudjuk elolvasni az üzenetét , a létrehozott alapértelmezett link tartalmazza a visszafejtési jelszót / kulcsot ; és ezért bárki, aki rendelkezik a linkkel, elolvashatja az üzenetét - beleértve azt is, aki képes elfogni.
- Ez a szolgáltatás csak egy olyan eszköz, amely lehetővé teszi a kevésbé állandó kommunikáció (azaz a visszakereséskor törölt titkosított üzenetek) küldését hagyományos, állandóbb transzportokon keresztül (pl. E-mail / szöveg / azonnali üzenetküldés / weboldal / stb.). Ez azt jelenti, hogy az eszköz használatakor a választott szállításnak (azaz e-mailnek) minden biztonsági / adatvédelmi kérdése öröklődik .
- Vannak más megoldások is, amelyek jobb biztonságot nyújtanak az Ön igényeitől és a környezettől függően. A szolgáltatás fő előnye a többiekhez képest sokkal alacsonyabb követelményeket támaszt a címzettekkel szemben (azaz csak egy webböngészőre és egy linkre való kattintásra van szükségük).
- Míg az alapértelmezett beállítás az üzenetek törlése visszakereséskor, semmi sem akadályozza a címzettet abban, hogy másolatot készítsen . Ne feledje, hogy ez minden ideiglenes üzenetmegoldásra vonatkozik - ha a vevő látja az üzenetet, akkor másolható.
- Minden internetes kommunikáció veszélyeztetheti a magánéletét - a kényelem érdekében valamilyen biztonságot folytat.
- A web néhány alapvető kérdés miatt kihívásokkal teli környezet a biztonság terén - ez minden weboldalra érvényes. Webalapúsága azonban megkönnyíti azon állításunk igazolását, miszerint nem tudjuk elolvasni az üzenetét .
- Ezt a weboldalt és annak adatbázisát az Egyesült Államok tárolja. Az Egyesült Államokban székhellyel rendelkező Cloudflare vállalatot használjuk tartalomszolgáltató hálózatunkként (az összes webes forgalom áthalad ezen a hálózaton).
- A szolgáltatás igénybevétele nem igényel személyes adatokat (pl. Név / e-mail / telefon / stb.). Nincs számlarendszer (azaz bejelentkezés / jelszó / stb.); ezért semmilyen adatsértés nem szivárogtathatja ki ezeket az információkat.
- Az összes üzenet tartalma végpontok közötti titkosítású . Más szavakkal, a visszafejtési kulcsot / jelszót soha nem küldjük el nekünk. Ezért nekünk, vagy bárkinek, aki az adatbázis birtokában van, nincs eszközünk az üzenet tartalmának visszafejtésére és megtekintésére.
- Az adatbázisunkban szereplő minden bejegyzés élettartama 1 perc és 2 hét között van (alapértelmezés szerint 1 hét). Ha ez az idő letelt, a rekord automatikusan törlődik. Ezért az adatbázisunkban lévő összes információt nem sokkal a létrehozása után töröljük .
- Csak a webszerver naplóinak utolsó 24 óráját tartjuk karban . Az adatbázisban tárolt minden IP-információt biztonságosan kivonatolják, ami lehetetlenné teszi az eredeti IP kibontását.
- A szolgáltatást működtető összes kód nyílt forráskódú, és megtekinthető. Könnyen láthatja a titkosítást futtató kódot - amely szándékosan rövid, tömör és kommentált.
- Számos technikai óvintézkedést hoztak a biztonság megerősítése érdekében - amelyek közül néhány a következőket tartalmazza:
- Ez az egész weboldal, az / api kivételével, statikus, és nem támogatja az oldalak szerverkódját (pl. PHP / JSP / ASP / stb.)
- A Web Crypto API , amely a böngésző része, az összes üzenettartalom titkosítására szolgál.
- A TLS a böngésző és a szervereink közötti kommunikáció titkosítására szolgál. Segít abban, hogy a kód ne lehallgatható vagy módosítható legyen szállítás közben. A TLS 1.3 támogatott, de a régebbi eszközök esetében is támogatjuk a TLS 1.2-t. A TLS régebbi verziói le vannak tiltva, mert nem olyan biztonságosak.
- A tanúsítvány átláthatósági naplóit figyeljük a tanúsítványok hibás elvesztése szempontjából. Ezenkívül közzéteszünk egy tanúsító hatóság engedélyezési (CAA) irányelvet, hogy csökkentse a tanúsítványok nem szándékos vagy rosszindulatú félrevezetésének kockázatát.
- A HTTP Strict Transport Security (HSTS) használatával biztosítjuk, hogy a böngészők mindig a TLS protokoll használatával kommunikáljanak szervereinkkel. Ezenkívül felvesszük domainjeinket az előterhelési listákba .
- Szigorú tartalombiztonsági irányelvek érvényesek a Cross Site Scripting (XSS) támadások megelőzésére.
- Az eredetközi erőforrás-irányelvek , a kereszt-eredetű beágyazási irányelvek és a kereszt-eredet-nyitó irányelvek használatával megtiltjuk a kereszt-származási kódot annak érdekében, hogy mérséklődjünk a spekulatív mellékcsatorna-támadások, például a Spectre és az Meltdown ellen. Ez védelmet nyújt más eredetű potenciálisan rosszindulatú kérelmek ellen is, mivel a böngészési kontextust kizárólag az azonos eredetű dokumentumokhoz választja el.
- Engedélyezési irányelveket alkalmazunk annak megakadályozására, hogy a böngésző olyan erőforrásokat töltsön be, amelyek veszélyeztethetik a magánéletét, például tartózkodási helyét, webkameráját, mikrofonját stb.
- A DNSSEC minden domainünkön használható a DNS-alapú MITM támadások mérséklésében.
- Számos óvintézkedést megteszünk a szerver biztonsága érdekében.
- Nincs betöltve harmadik fél kódja (pl. JQuery), és nagyon kevés erőforrás van betöltve (ellenőrizze, nyissa meg a Hálózat fület a Dev Eszközökben) - ez minimalizálja az ellenőrzéshez szükséges erőfeszítéseket. Az egyetlen kivétel az, ha CAPTCHA-ra van szükség - amely harmadik fél kódját tölti be a hCaptcha-ból . A hCaptcha kód azonban a saját CSP-szabályzatán belül a saját URL-jére töltődik be, és soha nem fér hozzá semmihez, ami köze van egy üzenethez.
- A MITM támadások elleni védelem érdekében böngészőbővítmények állnak rendelkezésre .
Miért kaptam itt egy linket az üzenet visszafejtésének lehetőségével?
Elnézést kérünk, ha hibák vannak ebben a fordításban . Ez a szolgáltatás egyszerűen továbbít egy titkosított üzenetet egyik pontról a másikra, és Ön a címzett. Az üzenetet hamarosan töröljük. A szolgáltatás üzemeltetői nem tudják elolvasni az üzenet tartalmát. Általában valaki akkor használja ezt a szolgáltatást, ha nem akarja, hogy az üzenet tartalma különféle adatbázisokban / eszközökben / szolgáltatásokban / fájlokban / stb. Maradjon. mint az e-mail / azonnali üzenet / szöveg / stb. küldésénél jellemző. Ha a visszafejtés mellett dönt, kérjük, vegye figyelembe a következőket:
- Valószínű, hogy az üzenetet azonnal törlik, miután elküldte az eszközére visszafejtés céljából. Ez azt jelenti, hogy miután rákattintott a gombra az üzenet visszafejtéséhez, már nincs másolatunk, amelyet később újra elküldhetnénk.
- Szisztematikusan töröljük az összes beérkezett információt. Az üzenetek létrehozása után egy perc és két hét között bárhol törlődnek - függetlenül attól, hogy az üzenetet valaha is visszafejtették-e. Más szóval, ha el kell olvasnia az üzenetet, ne várjon túl sokáig a visszafejtéssel.
- A feladó valószínűleg úgy véli, hogy az üzenet tartalmát körültekintően kell kezelni. Lehet, hogy még azt is jelezték, hogy nem akarnak másolatot készíteni. Kérjük, tartsa tiszteletben kívánságaikat.
- Ha az üzenet visszafejtéséhez jelszót kér, kérjük, ne zárja be a böngésző ablakát / lapját. A lista első felsorolási pontja szerint valószínűleg később nem küldhetünk újabb példányt. Csak hagyja nyitva a böngészőablakot / -lapot, amíg meg nem adja a jelszót. Ha helytelen jelszót ír be, akkor a rendszer újra kéri. A jelszót pontosan be kell írni. Ne feledje, hogy a különböző nyelvek és jelszókövetelmények kielégítése érdekében sok különböző karaktert fogadunk el a jelszavakban.
Törölsz mindent, amit erre a webhelyre küldtek?
A kuka logónkhoz híven ... minden hamarosan törlődik, miután megkapta. Minden törlése automatizált - a szerverre írva. Gondoljon erre így - a benyújtott információknak két osztálya van:
- Titkosított üzenetek, amelyekre nincs módunk a tartalom visszafejtésére
- Egyéb információk az interneten történő bárminemű beküldéshez (pl. IP-címe stb.)
- Mennyi ideig kell megőriznünk az üzenetet, ha senki sem szerzi be (1 perc és 2 hét között - alapértelmezés szerint 1 hétig).
- Hányszor lekérik az üzenetet (1 és 100 alkalommal - alapértelmezés szerint 1-szer)
Miért használja ezt a szolgáltatást?
Ez a szolgáltatás egy olyan eszköz, amely segít az elküldött / fogadott üzenetek állandóbbá tételében. A legtöbb, amit az interneten kommunikál (csevegések, szövegek, e-mailek stb.), Tárolódik és ritkán törlődik. Gyakran, amikor valamit töröl, az valójában nem törlődik, hanem töröltként van megjelölve, és már nem jelenik meg Önnek. Az összesített kommunikáció évről évre felhalmozódik az adatbázisokban és azokon az eszközökön, amelyek felett Ön nem rendelkezik irányítással. Óhatatlanul feltörik egy vagy több szervezetet / embert / eszközt, amelyek tárolják a kommunikációt, és az Ön információi kiszivárognak. Ez a probléma annyira elterjedt, hogy ma már sok olyan webhely található, amelyek nyomon követik a sértett és kiszivárogtatott szervezeteket. A végponttól végpontig titkosított ideiglenes üzenetek egyszerű megoldást kínálnak arra, hogy néhány kommunikációja kevésbé állandó legyen. Minden, a webhelyre beküldött üzenet élettartama 1 perc és 2 hét között mozog - ha ez az idő letelt, az üzenetet törlik. Ezenkívül az alapértelmezett beállítás minden üzenet törlése, amint a címzett letölti azt. Ezenkívül az összes üzenet titkosítva van a készülékről egészen a címzett eszközéig. A végpontok közötti titkosítás használatának fő célja, hogy megszüntessük a beküldött üzenetek elolvasásának képességét, ezáltal megszüntetve a bizalom követelményét. A végeredmény az, hogy ma már egyszerű egy linken keresztül titkosított üzenetet elküldeni. Ezt az üzenetet nem sokkal a küldés után, vagy visszakereséskor törlik. Nem kell speciális szoftvert telepítenie / konfigurálnia. Nem kell fiókot létrehoznia vagy személyes adatokat megadnia. A címzettnek nem kell szerepelnie az ismerőseiben, vagy akár tudnia kell erről a szolgáltatásról - az egyetlen követelmény, hogy rákattinthasson egy linkre.
Ez egy üzenetküldő szolgáltatás?
Nem. Ezt a szolgáltatást úgy tervezték, hogy kiegészítse a meglévő üzenetküldési szolgáltatásokat, mint például az azonnali üzenetküldés / e-mail / szöveg / stb. hozzáadva az elküldött üzenetek hosszú ideig történő tárolásának megakadályozását. A generált linket nem juttatjuk el a címzetthez .
Melyek a tervezett felhasználási esetek?
Tehát milyen esetekben érdemes használni ezt a szolgáltatást? Bár mindenkinek más igényei és követelményei vannak a magánélet és a biztonság szempontjából, én személy szerint a következő forgatókönyveket találtam megfelelő felhasználási eseteknek:
- Ön egy helyi internetes fórumon keresztül kommunikált a környéken található hegyi kerékpárutakról, és néha találkozik a fórumon tartózkodó emberekkel, hogy közösen megnézzék az új pályákat. Valaki a fórumról szeretné Önt felvenni, hogy a hétvégén egy ösvényhez jusson. Nem akarja, hogy otthoni címe örökre ebben a webhely fórum adatbázisában üljön. Egyszerűen küldje el a címet ezen a szolgáltatáson keresztül - a link az, ami a webhely fórum adatbázisában található, de miután a címzett elolvasta, az üzenet / cím törlődik.
- El kell küldenie testvérének a Netflix bejelentkezési adatait, mert unokahúga megőrjíti a COVID zárolása miatt, és még mindig nincs saját fiókja. Téged nem érdekel túlságosan ez a bejelentkezés, de a bátyád különösen rosszul áll abban, amit csak "digitális higiéniának" fogok nevezni, és sok próbát tett már sérült bejelentkezésekkel és rosszindulatú programokkal. A későbbi kísérletek arra késztetni, hogy tisztítsák meg a tettét, és még biztonságos üzenetek telepítése is, nem sikerült. Valószínűleg a szöveges üzenetben történő elküldés a legjobb megoldás (sajnos), de a korábbi tapasztalatok miatt kényelmetlenül érzi magát, ha a bejelentkezés az üzenetelőzményekben szerepel. Ennek a szolgáltatásnak a használata a bejelentkezés elküldéséhez egy szöveges üzenetben található linken keresztül kielégíti azt, hogy a bejelentkezés nem hagyja örökké lógni a csevegéstörténetében.
- Néha olyan irodában dolgozik, ahol sok megosztott bérlő van, akik minden órában jönnek-mennek. A WiFi használható, de a jelszót minden héten elforgatják, mivel a visszaélésekkel kapcsolatos problémák merültek fel. Sok bérlő e-mailben / SMS-ben kéri a WiFi jelszót, annak ellenére, hogy a recepción van, mert a legtöbb nem az első főbejáraton keresztül lép be. E szolgáltatás használatával az irodavezető elküldheti a WiFi jelszót egy e-mailben / szöveges válaszban szereplő linken keresztül, és kielégíti, hogy nem hagyja el a jelszót, és lehetővé teszi a címzett számára, hogy azonnal másolja a jelszót a mobileszközökön kevésbé esetlen másolási gomb segítségével.
- Az egyik tárhelyszolgáltatója részleteket kér egy olyan szerverről, amelyről azt jelentette, hogy merevlemez-meghajtó jeleit mutatja. A szükséges információk egy része kissé érzékeny - nem akarja, hogy örökké az általuk használt harmadik fél jegyrendszerében üljön. Ennek a szolgáltatásnak az igénybevételével elküldheti az információt a támogató technikusoknak anélkül, hogy az a jegyrendszerben lenne. Mivel előfordulhat, hogy több technikusnak többször kell hivatkoznia az információra, állítsa az élettartam-olvasási értéket 1-nél (azaz 20-nál nagyobb) értékre, hogy az üzenet ne törlődjön az első lekéréskor.
- Privát üzenetet kell küldenie egy másik felhasználónak a Reddit-en, hogy tudassa velük telefonszámát, hogy felhívhassák. A Reddit, mint sok más szolgáltató, korábban kiszivárogtatta a felhasználói információkat, és nem szeretné, hogy telefonszáma évekig csak a Reddit adatbázisában üljön a következő kiszivárogtatásig. Egyszerűen küldje el telefonszámát ezen a szolgáltatáson keresztül.
- Házastársa üzenettel küld Önnek, miközben Ön a munkahelyén szeretne bejelentkezni a segédprogramba, mert barátja éppen egy új programot próbált ki, amely pénzt takarított meg az elektromos számláján, és meg akarja nézni. Van egy megosztott családi jelszókezelő, amelyre emlékezteti őt, de ő csak azt szeretné, ha elküldené a bejelentkezést. Az OMEMO-t azonnali üzenetküldésre használják házastársával, ezért Ön nagyon magabiztosnak tartja, hogy az üzenetszállítás biztonságos; magát a csevegési előzményeket azonban titkosítatlanul tárolja. Házastársa nem mindig óvatos a letöltésekkel, e-mailekkel stb. Kapcsolatban, és a közüzemi számlák kissé érzékenyek, mivel felhasználhatók személyazonosság-lopásokkal a lakóhely igazolására. Ezzel a szolgáltatással elküldheti neki a bejelentkezési adatokat, hogy elkerülje a számítógépen tárolt másolatokat.
Mire ne használja ezt a szolgáltatást?
Ezt a szolgáltatást nem szabad nagyon érzékeny információkhoz használni a GYIK-ben ismertetett összes ok miatt. Az alábbiakban bemutatunk néhány példát arra, hogy mit ne tegyünk:
- Ne használja ezt a szolgáltatást egy nem megfelelő üzenet továbbítás "biztonságosabbá" tételéhez. Mivel az alapértelmezett beállítás az, hogy a jelszót tartalmazza az URL-ben, amely el tudja olvasni az üzenetet, bárki, aki rendelkezik linkkel, elolvashatja az üzenetet. Mint fentebb említettük, az eszköz használatakor a kiválasztott szállítás (pl. Szöveg) velejárója minden biztonsági / adatvédelmi probléma öröklődik. Tehát, például ha soha nem fontolgatná az e-mail használatát konkrét információk elküldéséhez annak értelmes jellege miatt, akkor ne használja ezt a szolgáltatást az e-mail ezen részének "biztonságossá" tételére.
- Ne használja ezt a szolgáltatást annak biztosítására, hogy ne készüljön másolat az üzenetről. Az, hogy a visszakeresés után azonnal töröljük a titkosított üzenet másolatát, és megnehezítjük a másolást, még nem jelenti azt, hogy az üzenet nem másolható. Mi van, ha a címzett lefényképezi a képernyőt? Mi lenne, ha csak felírnák az üzenetet? Végül, ha a címzett el tudja olvasni az üzenetet, másolat készíthető.
- Ne használja ezt a szolgáltatást annak biztosítására, hogy egy üzenet ne legyen visszavezethető Önre. Ez a szolgáltatás egy másik üzenetszolgáltatótól (pl. E-mail, csevegés stb.) Függ, hogy az üzenet az egyik pontról a másikra kerüljön. Az alkalmazott üzenetszállítás nagyon jól visszavezetheti Önre az üzenetet.
- Ne használja ezt a szolgáltatást olyan adatok küldésére, amelyek megtagadását szeretné megtenni. Az, hogy maga az üzenet törlődik, nem jelenti azt, hogy a törölt üzenetre mutató link törlődik. Ha e-mailt küld a barátjának, és az e-mail egy részében található egy link a szolgáltatásból érkező üzenetre, egy alkalmi olvasó tudja, hogy valami más volt az üzenetben. Még akkor is, ha a link által hivatkozott üzenet már régen elmúlt - egyértelmű, hogy valami mást küldött, és hogy Ön küldte el a barátjának.
Miért nem csak a PGP / Signal / OMEMO / Matrix / stb.
Ha ismeri azt a személyt, akinek biztonságos ideiglenes üzeneteket szeretne küldeni, gyakran küldi el, elvár egy csevegésszerű felületet, és / vagy elvárhatja, hogy a címzett rendelkezzen a szükséges szoftverrel és tudja, hogyan kell használni, akkor valószínűleg ez a webhely nem az legjobb megoldás. Vannak olyan nagyszerű lehetőségek, amelyek nyílt forráskódúak, támogatják az E2EE-t, nem webalapúak, sőt vannak olyanok is, mint a Signal, amelyek támogatják az ideiglenes üzeneteket is. Személyesen használok egy privát XMMP szervert és az OMEMO-t, hogy csevegjek közeli barátaimmal és családtagjaimmal. Ennek a webhelynek a használata csak akkor lehet optimális, ha nem tudja, hogy a címzett milyen szoftvert futtat, nem ismeri a telefonszámát / kapcsolattartóját, nem ismeri a technikai hozzáértését (de feltételezzük, hogy rákattinthatnak egy linkre), vagy inkább csak az elküldött üzenetet szeretné az alapul szolgáló kommunikációs szállításon kívül tartani.
Milyen követelmények vannak?
Egy modern és naprakész böngészőre van szükség, amely megfelelően végrehajtja a szabványokat, beleértve a Web Crypto API-t is. Példák: Chrome, Firefox, Edge és Safari (2020 körül vagy később).
Készíthet másolatot a címzett az üzenetről?
Igen. Annak ellenére, hogy az üzenet visszakereséskor törölheti magát, a címzett továbbra is megtekintheti az üzenetet. Bármikor a vevő teljesen megtekintheti az üzenetet, másolat készíthető - ez minden kommunikációra vonatkozik. Van egy lehetőség, hogy megnehezítse a címzett számára a másolat készítését. Ebben az esetben a másolás három akadálya valósul meg:
- A Másolás gomb eltávolításra kerül. Ez a gomb alapértelmezés szerint lehetővé teszi a címzett számára, hogy a teljes üzenetet a vágólapjára másolja.
- A Letöltés gomb eltávolításra kerül. Ez a gomb alapértelmezés szerint lehetővé teszi a címzett számára, hogy szöveges fájlként töltse le az üzenetet.
- Az üzenet szövegmezőjében lévő szöveg kiválasztásának lehetősége megszűnik.
Gyűjtenek személyes adatokat?
Nem támogatjuk a felhasználói fiókokat (azaz felhasználónév / jelszó). Nem gyűjtünk olyan információkat, amelyek azonosíthatnák Önt (például név / cím / e-mail cím / telefonszám). Lehetséges, hogy néhány személyes adat lehet az Ön által küldött üzenetben, de ez titkosítva van, és nincs módunk elolvasni. A részletekért olvassa el adatvédelmi irányelveinket .
Milyen információkat naplóznak?
Webszerverünk akár 24 órányi közös naplóformátumot is tárol minden webes tevékenységen. Ez magában foglalja a HTTP kliensek teljes IP-címének naplózását. 24 óra elteltével ez a naplózott információ automatikusan törlődik. Az / api-nak küldött összes kérés POST-el van jelölve, ami azt jelenti, hogy a webszerver soha nem naplóz üzenetre vonatkozó információkat. Ezenkívül minden, az adatbázisba mentett információt hatékonyan naplózunk. Az adatbázis minden bejegyzésének, beleértve az anonimizált és kivonatolt IP-címeket is, lejárati ideje (TTL) van, amely után automatikusan törli őket. A TTL lejárati ideje 1 perc és 2 hét között változik.
Mit tesz a szerverek biztonsága érdekében?
A szerver biztonsága nyilvánvaló aggodalomra ad okot. Két fő területre koncentrálunk a biztonság megőrzése érdekében:
- Először is a lehető legkevesebbet tároljuk a lehető legkevesebb ideig, hogy ha a kiszolgáló valaha is veszélybe kerül, az esetleges információszivárgás ne károsítsa felhasználóinkat. Az adatbázisban tárolt összes üzenet titkosításra kerül, semmilyen módon nem lehet visszafejteni őket. Nincs tárolva olyan üzenet, amely bármely felhasználónkat összekapcsolná, mivel nem gyűjtünk személyes adatokat a felhasználóinktól. Az adatbázisban szereplő összes rekord lejárati ideje (TTL) 1 perc és 2 hét között mozog - miután ez az idő letelt, a rekord automatikusan törlődik. Ezért az adatbázisban valaha található információk túlnyomó részét már régen törölték.
- Számos intézkedést megteszünk a kompromisszumok megakadályozása érdekében, és minden bekövetkező kompromisszumot tartalmazunk:
- A webkiszolgáló, az nginx , elszigetelt tárolóban fut, kiváltságos felhasználóként, a naplókon kívül máshoz sem írási hozzáféréssel. A tároló a saját SELinux kontextusában fut, megakadályozva ezzel a fájlrendszer változását és a tárolóból történő könnyű menekülést. A PHP / ASP / JSP / stb. Nem támogatott. - csak statikus erőforrásokat szolgál ki.
- Az / api kódot a Go-ban írják, aminek köszönhetően eléggé rugalmasabbá kell tennie a túlcsorduló sebezhetőségek (gyakori támadási vektor) pufferelését. A Go folyamat egy elkülönített tárolóban is fut, előretekintő felhasználóként, anélkül, hogy az adatbázison kívül máshoz írási hozzáférést biztosítana. A tároló a saját SELinux kontextusában fut, megakadályozva ezzel a fájlrendszer változását és a tárolóból történő könnyű menekülést. Az adatbázis, a badgerdb , a Go folyamat része (nincs külső adatbázis-függőség / folyamat).
- A kiszolgáló kompromisszumának legfőbb veszélye, hogy a támadó úgy módosíthatja a fájlokat, hogy az veszélyeztesse felhasználóink magánéletét / biztonságát. A dedikált folyamat figyelemmel kíséri az összes webhelyfájlt az esetleges változásokra, és azonnal értesít minket a változás esetére.
- Minden adminisztrációs hozzáférés védett és csak engedélyezett hálózatokra korlátozódik.
Milyen biztonsági kockázatok vannak jelen webhely használatakor?
Mielőtt konkrétan foglalkoznék e kockázatok némelyikével, úgy gondolom, hogy egy félig rövid analógia segíthet összefoglalni az internetes kommunikáció használatával kapcsolatos kockázatokat. Képzelje el, hogy bármely rendszer csak annyira biztonságos, mint a lánc leggyengébb láncszeme. Most képzeljen el egy olyan forgatókönyvet, amikor egy zárt szobában két ember van, és semmilyen eszköz nincs arra, hogy bármit is láthassanak, halljanak vagy rögzítsenek. Az egyik továbbít egy üzenetet a másiknak, akit az üzenet elolvasása után megéget. Ha valaki azon a szobán kívül szeretné megszerezni a már átadott üzenetet, az nehéz lesz. Mi a leggyengébb láncszem az üzenet megszerzéséhez? Nincs olyan sok link, amelyek közül választhatna - ez elég rövid lánc. Most képzelje el, hogy amikor az interneten üzenetet küld arról, hogy legalább egymillió link van a láncban - sok közülük gyenge - sokan teljesen kívül esnek az ön irányításában, és ez a valóság.
A titkosítás használata nagyban hozzájárulhat a fenti egymillió linkprobléma megoldásához, és könnyű elgondolkodtatni abban, hogy a jól megtervezett E2EE rendszerek kínálják a végső megoldást. Ez a gondolkodás azonban bajba sodorhatja, mert a támadó általában csak a rendszer gyengébb láncszemeit követi. Például valószínűleg sokkal könnyebb átvenni a telefont vagy a számítógépet, és beállítani egy bemeneti naplózót, hogy csak elolvassa mindazt, amit beír, mint a titkosított üzenetek feltörése a vezetéken. A lényeg az, hogy ha egy létfontosságú / kritikus fontosságú titok közlését kapnám feladatomra, akkor az elektronikus kommunikációt csak végső megoldásként használnám.
Tehát bármilyen kommunikáció esetén vannak biztonsági kockázatok, de továbbra is webböngészőt használ banki szolgáltatásokhoz, dolgok vásárlásához, e-mailekhez stb. Ez a megszerzett hatalmas kényelem miatt elfogadott kockázat. Valóban a kérdés ... milyen biztonsági kockázatok vannak félig specifikusak ezen a webhelyen? Néhányan eszembe jutnak:
- Talán a legnagyobb kockázat és a szolgáltatás egyedülállója, hogy a felhasználóink nem fogják megítélni jó megítélésüket, ha különbséget tesznek a küldés és a nem megfelelő között . Néha meglehetősen finom lehet a különbségtétel: "Könnyen elküldöm e-mailben ezeket az információkat - csak azt szeretném, ha az e-mailt elolvasnám az elolvasás után" és az "Nem vagyok kényelmesen elküldeni e-mailben ezeket az információkat - az e-mail nem megfelelő szállítás" között.
- Mindig fennáll annak a veszélye, hogy az oldal üzemeltetői valójában rossz szereplők, akik csábítják az embereket a szolgáltatás igénybevételére valamilyen sötét cél elérése érdekében. Valószínűleg megbízhatóan találkozunk - tegyünk mindent könnyűvé és ingyenesé - sok embert vegyen igénybe a szolgáltatás - mindeközben baljós szándékkal. Bwhahahahaha! Hogyan tudna megbízni bennünk?
- Előfordulhat, hogy kódunk hibáival hat, amelyek befolyásolják a biztonságot, vagy egyszerűen nem gondoltuk jól át a dolgokat, és hiányosságaink most szükségtelen veszélynek teszik ki felhasználóinkat. Reméljük, hogy nem - de nem zárhatjuk ki.
- Ellentétben a technikai titánokkal (azaz a Google / Facebook / Whatsapp), amelyek titkosított adatainak terabitjai folyamatosan áramlanak be és ki hatalmas hálózataikból, ahol könnyen privát kommunikáció keveredhet más forgalommal, önálló központosított szolgáltatásokkal (pl. Signal, Távirat, és mi) kiemelkednek. Egy hálózatüzemeltető, vagy akár egy nagy szervezet / kormány számára könnyen belátható, hogy az xxxx IP cím XYZ szolgáltatást használ.
- Noha nem igazán jellemző erre a webhelyre, mivel bármely webhely ellen használható, a Man-in-the-közép (MITM) támadások érvényes aggodalomra adnak okot .
Mit csinál az ember a közepén (MITM) támadásokkal kapcsolatban?
A weboldalak minden felhasználója potenciálisan MITM-támadás áldozata lehet - ez a webhely ebben a tekintetben nem különbözik a weben található összes többi személytől. A MITM támadás az, amikor a támadó képes elfogni és módosítani a felhasználó böngészője és a webhely webszervere közötti kommunikációt. Ez lehetővé teszi a támadó számára, hogy módosítsa a webhely bármelyik kódját / tartalmát, miközben a végfelhasználó számára továbbra is a megszokottnak tűnik. Néhány intézkedést megteszünk a MITM-támadás megnehezítése érdekében:
- A HSTS arra használható, hogy a böngészőket csak a TLS-en keresztül csatlakozzon. Szerverünk úgy van konfigurálva, hogy az átirányításon kívül hagyja figyelmen kívül a nem TLS kommunikációt. Csak a TLS 1.2 vagy újabb verzió támogatott.
- A DNSSEC a domainünk zónájának aláírására szolgál. Ez megállíthatja a megvalósított MITM támadások hamisítását, ha a felhasználó DNSSEC-tudatos rekurzív megoldót alkalmaz.
- Szolgáltatást használunk a tartományunkra hivatkozó, illetéktelen TLS-tanúsítványokat kiadó tanúsító hatóságok felügyeletére.
- Böngészőbővítményeket tettünk közzé, amelyek támogatják az üzenet titkosítását a végfelhasználó eszközén tárolt kód használatával.
Milyen előnyöket kínálnak a böngészőbővítmények?
Böngészőbővítményeket kínálunk , amelyek extra kényelmet és biztonságot nyújtanak. Egyszerűen fogalmazva ... A bővítmények megkönnyítik az ideiglenes üzenetek küldését. Némi biztonságot azért is szerez, mert az üzenet titkosításához és előkészítéséhez használt összes kódot helyileg tárolják a kiterjesztésben. Mivel a kódot helyileg tárolják, ez némi védelmet nyújt a feladónak a MITM támadásokkal szemben . Érdemes azonban felhívni a figyelmet arra, hogy bár a bővítmények nagyobb védelmet nyújtanak az üzenet tartalmát veszélyeztető MITM-támadással szemben, a MITM-támadás mégis hatékony lehet (azaz meghatározhatja a feladó IP-címét, ha nem használ TOR / VPN / stb.).
Honnan tudhatom biztosan, hogy bármi beküldött tartalom titkosítva van?
Sok más népszerű end-to-end titkosított (E2EE) csevegő klienstől eltérően meglehetősen egyszerű pontosan megnézni, hogy mit küld nekünk, amikor üzenetet küld. Az alábbi videó bemutató bemutatja, hogyan lehet megerősíteni, hogy nincs lehetőségünk a szerverre küldött üzenetek visszafejtésére.
Továbbá, ha belegondolunk, mindaddig, amíg nem vagyunk titkos ügynökségek, akik érzékeny üzeneteket próbálnak gyűjteni, nincs előnyünk, ha visszafejtjük az üzeneteket, mivel ez a képesség csak problémákat okoz számunkra. Nem is akarunk üzeneteket tárolni - ez azonban egy szükségszerű rossz, hogy eljusson hozzájuk.Hogyan működik a végpontok közötti titkosítás ezen a webhelyen?
Jelenleg szimmetrikus titkosítást (AES-GCM 256bit) használunk jelszavakból levezetett kulcsokkal (legalább 150 000 PBKDF2 / SHA-256 ismétlés). Az aszimmetrikus titkosítást nem használják, mert követelmények vonatkoznak arra, hogy 1) a kommunikációt kezdeményező küldő 2) a küldő és a címzett ne legyen online egyszerre, és 3) nincs információ a címzettről, és 4) megpróbáljuk a dolgokat egyszerűvé tenni és a kulcskezelés bonyolult. A szokásos Web Crypto API-t minden kriptográfiai funkcióhoz használják, beleértve az RNG-t is. Alapvetően a következő történik:
- A végfelhasználó választ egy jelszót, vagy automatikusan generál egyet
- API-hívás történik a szükséges PBKDF2 / SHA-256 iterációk számának megszerzéséhez ( erre a lépésre van szükség a levélszemét-vezérléshez )
- 32 bájtos só keletkezik
- A kulcs a sóból és a jelszóból származik
- Egy 12 bájtos inicializáló vektor (IV) jön létre
- Az üzenet a + IV billentyűvel van titkosítva
- Az iterációszám, a só, az IV és a titkosított szöveg elküldésre kerül a szerverre (néhány egyéb információval együtt, pl. TTL, RTL stb.)
- A szerver véletlenszerű azonosítót ad vissza az üzenetre hivatkozva
- Ezután a böngésző egy linket mutat be a végfelhasználó számára, amely tartalmazza a visszaküldött azonosítót és jelszót, vagy egy jelszó nélküli linket (ebben az esetben a címzettnek tudnia kell és meg kell adnia a jelszót)
- Ha a jelszó a link része, akkor az URL kivonatban van , ezért soha nem küldi el a szervernek, amikor a címzett GET kérést küld
- A címzett megkérdezi, hogy kívánja-e visszafejteni és megtekinteni az üzenetet
- A böngésző kérést küld az üzenet azonosítójának megadásával
- Ha a feladó megköveteli egy CAPTCHA kitöltését, a címzettet egy másik URL-re irányítják, hogy igazolja, hogy ember (ha átadta őket, visszairányítják).
- A szerver elküldi a titkosított üzenetet, és alapértelmezés szerint ezen a ponton törli az üzenetet, ha az azonnali olvasás (RTL) egy
- A címzett visszafejti az üzenetet jelszóval (és a rendszer kéri a jelszó megadását, ha nem szerepel az URL-ben)
A visszafejtési jelszó lehet az URL-ben?
Igen. Ez nyilvánvalóan befolyásolja a biztonságot, mert ha a link elküldésére használt módszer nem biztonságos, az üzenet társítással nem biztonságos. A probléma kiküszöbölésére szolgáló összes megoldás további lépéseket és összetettségeket vezet be, amelyek befolyásolják a felhasználói élményt (azaz a dolgokat mindkét oldalon be kell állítani az üzenet elküldése előtt). Egy aszimmetrikus séma, amelynek során a címzett kezdeményez egy üzenet iránti kérelmet és elküldi azt a kérési linket, működhet a "minden mulandó" kulcsfontosságú követelményünkkel - ez megvalósítható. Végül, ha két fél gyakran üzen egymásnak, jobb megoldások léteznek, feltéve, hogy mindkét fél képes kezelni ezeket a megoldásokat.
De a visszafejtési jelszónak nem kell szerepelnie az URL -ben?
Helyes. Ha a visszafejtési jelszó nem szerepel a hivatkozásban, akkor a címzett kéri a jelszót. Ha a jelszót biztonságosan közlik a címzettel (vagy már tudják), ez védelmet nyújt az elfogás ellen. A hátrány azonban az, hogy a címzettnek tudnia kell és helyesen kell megadnia a jelszót. Íme egy módja annak, hogy elküldje a jelszót a címzettnek, amely némi védelmet nyújt a lehallgatás ellen:
- Titkosítsa a jelszót egy üzenetben az alapértelmezett beállításokkal, és küldje el ezt a linket a címzettnek.
- Amikor a címzett rákattint a linkre és visszafejti az üzenetet, tudja, hogy senki más nem kapta meg a jelszót előttük, mert a jelszót tartalmazó üzenet törlődik a visszakereséskor. Ha azonban aktív MITM támadás történik, vagy ha az Ön eszköze vagy a címzett eszköze veszélybe került, akkor is lehetséges, hogy egy másik fél megszerezheti a jelszót.
- Erősítse meg a címzettel, hogy sikeresen megszerezte a jelszót. Például, ha a címzett arról tájékoztatja Önt, hogy amikor elment a jelszó lekérésére, és hogy az üzenetet már törölték, akkor tudja, hogy valaki más szerezte meg a jelszót a címzett előtt, és ezért a jelszó sérült, és nem szabad használni.
- A címzett által megerősített jelszó használatával most küldhet üzenetet ugyanazzal a jelszóval a titkosításhoz - csak ossza meg a link azon verzióját, amely nem tartalmazza a jelszót.
Ez a szolgáltatás nem juttatja el a linket a címzetthez?
Ez helyes - mi generáljuk a linket, és a feladóra bízzuk, hogyan lehet a legjobban eljuttatni a címzetthez. Ennek a szolgáltatásnak az a célja, hogy olyan opciót nyújtson, amely kevesebb állandóságot kínál a meglévő üzenetszállításokban, például e-mail / chat / text / stb. Ezért elvárás, hogy az általunk generált link, amely az ideiglenes üzenetre mutat, egy meglévő üzenetszállításon keresztül kerüljön elküldésre. Ennek vannak biztonsági vonatkozásai, amelyeket a felhasználóknak meg kell érteniük. Vegyünk példaként egy SMS-t, mivel ez egy elég bizonytalan kommunikációs módszer. Ha ezt a szolgáltatást ideiglenes üzenet-link küldésére használja szöveges üzenetben, akkor az alapértelmezett módot használja, amelynél a jelszó szerepel a linkben, bárki, aki rendelkezik linkkel, elolvashatja az üzenetet, és nem nyújt védelmet lehallgatás ellen. Ez a szolgáltatás továbbra is ideiglenesebb kommunikációt biztosít, amely javíthatja az adatvédelmet és biztonságot. Ezenkívül dönthet úgy, hogy jelszó nélkül küldi a linket, és ez védelmet nyújt az elfogás ellen.
Hogyan védhetem meg a magánéletemet a lehető legnagyobb mértékben a szolgáltatás használata közben?
Ahogy a jelen GYIK-ben máshol is tárgyaltuk, annak ellenére, hogy már most sokat teszünk az Ön személyes adatainak védelme érdekében, és bár nem gyűjtünk személyes adatokat, a naplóval kapcsolatos információkat mi és mások küldünk be és gyűjtünk Ön által, egy webböngésző segítségével. Azonban még többféle módon védheti magánéletét. A szabadon használható, nyílt forráskódú szoftvereken alapuló és nagyon jól használható módszer a Tor böngésző használata . Ezt a böngészőt úgy alakítottuk ki, hogy több szinten megvédje magánéletét - beleértve a Tor hálózat használatát is . Webhelyünk már elérhető a Tor hagymahálózaton keresztül, ami azt jelenti, hogy a Toron keresztül történő eléréshez nem szükséges kilépési csomópont használata, ami tagadja, hogy valaki lehallgassa a kilépési csomópont forgalmát . Ne feledje azonban, hogy még ebben a forgatókönyvben is az internetszolgáltatója láthatja, hogy Tor-t használ - bár nem mire. Akár csatlakozhat egy VPN-hez, majd elindíthatja a Tor böngészőt a névtelenség két rétegéhez; ne feledje azonban, hogy az internetszolgáltatója továbbra is láthatja, hogy VPN-t használ ebben a forgatókönyvben - bár nem mire. Ha nem szeretné, hogy internetszolgáltatója tudja, milyen protokollokat használ, csatlakozhat egy nagy nyilvános WiFi hálózathoz, például könyvtárhoz, iskolához stb., Majd használhatja a Tor böngészőt.
Mi van, ha nem bízom az Egyesült Államokban?
Szervereink az Egyesült Államokban találhatók. Ezen felül CDN szolgáltatónk, a Cloudflare, az Egyesült Államokban székhellyel rendelkező vállalat. Megpróbáltuk elhárítani annak szükségességét, hogy bízzunk bennünk vagy abban az országban, ahol szervereink laknak, pusztán azért, mert nem gyűjtünk személyes adatokat, nem tudunk visszafejteni egyetlen üzenetet sem, és mindent röviddel azután megkapunk, hogy megkapjuk. Megérthetünk azonban bizonyos bizalmatlanságokat, mivel webalapúak, és különösen, ha bizonyos országokban élsz. Tervezünk Izlandon és Svájcban olyan lehetőségeket kínálni, akik nehezen bíznak az USA-ban. Kérjük, ossza meg velünk, ha ez vonatkozik Önre, mivel nem leszünk motiváltak alternatívákat kínálni, hacsak nincs igazi igény.
Mit tesz a spam megakadályozása érdekében?
Bármikor megengedi valakinek, hogy küldjön egy linken keresztül továbbítható üzenetet, meghívja a spammereket. Ennek a problémának a megfékezése nem teljesen egyértelmű. Néhány okból nem akarunk egy harmadik féltől származó CAPTCHA-t betölteni az üzenetküldési folyamat részeként:
- Utáljuk a CAPTCHA-kat - időbe telik és idegesítő
- A harmadik fél javascriptjének betöltése sértheti az adatvédelmet és a biztonságot
- Saját CAPTCHA rendszerünk futtatása azt jelenti, hogy regisztrálunk egy soha véget nem érő mole játékra
- Végül az emberek azt szeretnék, hogy képesek legyenek interakcióba lépni ezzel a szolgáltatással az API-n keresztül
- A szükséges PBKDF2 / SHA-256 ismétlések számának növelése
Az összes üzenet csak néhányszor tölthető le - ez nem vonzó tulajdonság a spammerek számára, mivel sok üzenet elküldésére támaszkodnak. Mivel a spamelőnek sok üzenetet kell létrehoznia az adott spam kampányhoz - úgy döntöttünk, hogy ezt a feladatot számítási szempontból annyira drágává tesszük, hogy a spam miatti visszaélés nem tetszetős törekvéssé váljon. Ez úgy valósul meg, hogy nyomon követi az üzeneteket küldő hálózatokat - az összes lehetséges letöltés szempontjából mérve. Maga a hálózati információ biztonságosan el van hasítva, így a kivonatból nem következtethetünk a valós hálózatra. Mivel egy adott hálózat további üzeneteket tesz közzé, emeljük a következő üzenet elküldéséhez szükséges PBKDF2 / SHA-256 ismétlések számát. Ez nagyon gyorsan azt eredményezi, hogy csak egyetlen üzenet elküldéséhez sok CPU idő szükséges. Remélhetőleg ez a módszer megfelelő lesz a spamekkel való visszaélések visszaszorítására, ugyanakkor nem érinti a valódi felhasználókat. - Gyűjtsön spamjelentéseket a felhasználóktól, amikor üzenetet kapnak
Közvetlenül az üzenet alatt van egy "Spam bejelentése" gomb, amikor a felhasználó letölt egy üzenetet. Ha egy üzenet spam, remélhetőleg néhányan eltartják azt a 3 másodpercet, amelyre az adott gombra kattintanak. Ha spamjelentést kapunk, az figyelmeztet minket, és figyelembe veszi az adott hálózat szükséges PBKDF2 / SHA-256 iterációit is.
Miért van lehetőség a CAPTCHA kitöltésére a címzetttől?
Bár igaz, hogy nem szeretjük a CAPTCHA-kat, elismerjük, hogy azok célt szolgálnak, és idejük és helyük van (legalábbis egyelőre). Ez egyszerű módja annak, hogy a feladó bizonyos fokú bizonyosságot szerezzen arról, hogy a címzett ember, és hogy az automatizált folyamatok nem férnek hozzá az üzenethez.
Ki üzemelteti ezt a szolgáltatást, és miért ingyenes?
Csak néhány srác vagyunk, akik néha szembesültek azzal a nehézséggel, hogy nincsenek jó lehetőségek a magánéletünk védelmében. Gyakran ez abból adódott, hogy kommunikáltunk olyan barátaikkal és családtagjaikkal, akik nem voltak túl óvatosak az eszközök és információk kezelésében. Máskor ez webalapú fórumok, például a Reddit vagy webalapú támogatási rendszerek használatakor következett be. Találtunk néhány webalapú ideiglenes üzenetmegoldást, de egyik sem kínált E2EE-t, ami azt jelentette, hogy nem bízhatunk bennük. Tehát csak megépítettük a saját megoldásunkat, és úgy döntöttünk, hogy odaadjuk, hogy mások is profitálhassanak belőle.
Hogyan bízhatok meg a fenti kérdésekre adott válaszokban?
Tényleg nem szabad megbízni egyetlen weboldalban sem, csak azért, mert bizonyos dolgokat mond - ez általában jó ötlet az állítások igazolására. A végpontok közötti titkosítás alkalmazásával a lehető legnagyobb mértékben megpróbáltuk eltávolítani a bennünk való bizalom követelményét. Például elég könnyen ellenőrizhető, hogy egyetlen üzenetet sem tudunk elolvasni, mivel azok titkosítva vannak . A webhelyet futtató javascript kódot is nagyon egyszerűvé tettük, hogy könnyen olvasható és érthető legyen. Az összes kód nyílt forráskódúvá tétele lehetővé teszi az emberek számára, hogy ellenőrizzék, mi fut; azonban ne feledje, hogy nincs mód arra, hogy valóban ellenőrizze, mi a szerver fut. Bár igaz, hogy a megbízhatósági követelmények nagy része végpontok közötti titkosítással megszűnik, a felhasználóink mégis súlyosan mérlegelik, amikor úgy döntenek, hogy igénybe veszik ezt a szolgáltatást.