често задавани въпроси

• Защо този сайт е лошо преведен? ⎃
• Колко сигурна е тази услуга?
• Защо получих връзка тук с опция за дешифриране на съобщение?
• Изтривате всичко изпратено на този сайт?
• Защо да използвам тази услуга?
• Това услуга за съобщения ли е?
• Какви са предвидените случаи на употреба?
• За какво не трябва да се използва тази услуга?
• Защо просто да не използваме PGP / Signal / OMEMO / Matrix / и т.н.?
• Какви изисквания съществуват?
• Може ли получателят да направи копие на съобщението?
• Събира ли се лична информация?
• Каква информация се регистрира?
• Какво правите, за да защитите сървърите?
• Какви рискове за сигурността са налице при използването на този сайт?
• Какво правите с атаките „човек в средата“ (MITM)?
• Какви предимства предлагат разширенията на браузъра?
• Как мога да знам със сигурност, че всичко изпратено е криптирано от край до край?
• Как работи криптирането от край до край на този сайт?
• Паролата за дешифриране може да е в URL адреса?
• Но паролата за декриптиране не трябва да е в URL адреса?
• Тази услуга не доставя връзката на получателя?
• Как мога да защитя поверителността си възможно най-много, докато използвам тази услуга?
• Ами ако нямам доверие на САЩ?
• Какво правите, за да предотвратите спама?
• Защо има опция да се изисква получателят да попълни CAPTCHA?
• Кой използва тази услуга и защо е безплатна?
• Как мога да се доверя на отговорите на горните въпроси?

Защо този сайт е лошо преведен? ⎃

Извинете, но настоящите автори говорят само английски. Имаме нужда от помощ при превода на този проект на други езици. Като просто и евтино средство да направим тази услуга достъпна за хора, които не говорят английски, ние използваме машинен превод. Резултатите обикновено са приемливи, но могат да доведат до странни формулировки или дори напълно неточна информация. Можете да ни помогнете да подобрим практическата работа за всички - моля, изпратете правилния превод .

Колко сигурна е тази услуга?

Предприехме много стъпки, за да направим тази услуга защитена по предназначение . Преди да преминем през тези стъпки, важно е да разберем следното:

• Въпреки че не можем да прочетем съобщението ви поради криптиране от край до край , генерираната връзка по подразбиране съдържа парола / ключ за дешифриране ; и следователно всеки, който притежава връзката, може да прочете съобщението ви - включително всеки, който може да го прихване.
• Тази услуга е само инструмент, който позволява изпращане на по-малко постоянни комуникации (т.е. криптирани съобщения, които се изтриват при извличане) чрез традиционни транспорти, които са по-постоянни (т.е. имейл / текст / незабавни съобщения / уебсайт / и т.н.). Това означава, че всички проблеми със сигурността / поверителността, присъщи на избрания транспорт (т.е. имейл), се наследяват, когато използвате този инструмент .
• Налични са и други решения, които предлагат по-добра сигурност в зависимост от вашите нужди и среда. Основното предимство, което тази услуга предлага в сравнение с други, е много по-ниските изисквания за получателя (т.е. те просто се нуждаят от уеб браузър и възможността да щракнат върху връзка).
• Докато настройката по подразбиране е да се изтриват съобщения при извличане, няма нищо, което да попречи на получателя да направи копие . Имайте предвид, че това се отнася за всички временни решения за съобщения - ако получателят може да види съобщението, то може да бъде копирано.
• Всички интернет комуникации могат да нарушат поверителността ви - вие търгувате с известна сигурност за удобство.
• Мрежата е предизвикателна среда по отношение на сигурността поради някои основни проблеми - това се отнася за всички уеб сайтове. Въпреки това, че сме базирани на мрежа, правим проверката на твърдението ни, че не можем да прочетем съобщението ви много по-лесно .
• Този уебсайт и неговата база данни се хостват в Съединените щати. Ние използваме Cloudflare, компания, базирана в САЩ, като нашата мрежа за доставка на съдържание (целият уеб трафик преминава през тази мрежа).

Нашата цел е да предложим тази услуга по начин, който предлага опции за подобряване на вашата поверителност и сигурност. Ето няколко стъпки, които предприехме, за да защитим вашата информация:

• Използването на услугата не изисква никаква лична информация (т.е. име / имейл / телефон / и т.н.). Няма система за акаунт (т.е. вход / парола / и т.н.); следователно, всяко нарушение на данните не може да изтече тази информация.
• Цялото съдържание на съобщението е криптирано от край до край . С други думи, ключът / паролата за дешифриране никога не ни се изпращат. Следователно ние или някой друг, който притежава базата данни, нямаме средства за дешифриране и преглед на съдържанието на съобщението.
• Всеки запис в нашата база данни има време за живот, вариращо от 1 минута до 2 седмици (по подразбиране до 1 седмица). След като изтече това време, записът автоматично се изтрива. Следователно всяка информация в нашата база данни ще бъде изтрита скоро след нейното създаване .
• Поддържаме само последните 24 часа регистрационни файлове на уеб сървъра . Всяка IP информация, съхранявана в базата данни, е сигурно хеширана, което прави невъзможно извличането на оригиналния IP.
• Целият код, захранващ тази услуга, е с отворен код и е достъпен за преглед. Можете лесно да видите кода, който изпълнява криптирането - който е умишлено кратък, кратък и коментиран.
• Взети са редица технически предпазни мерки, които спомагат за укрепването на сигурността - някои от тях включват:
  • Целият този уеб сайт, различен от / api, е статичен и не поддържа сървърния код в страници (т.е. PHP / JSP / ASP / и т.н.)
  • Web Crypto API , който е част от браузъра, се използва за криптиране на цялото съдържание на съобщението.
  • TLS се използва за криптиране на комуникацията между вашия браузър и нашите сървъри. Той помага да се гарантира, че кодът не може да бъде прихванат или модифициран при преминаване. Поддържа се TLS 1.3, но ние също поддържаме TLS 1.2 за по-стари устройства. По-старите версии на TLS са деактивирани, защото не са толкова сигурни.
  • Регистрационните файлове за прозрачност на сертификатите се наблюдават за грешно издаване на сертификати. Освен това публикуваме политика за упълномощаване на сертифициращ орган (CAA), за да намалим риска от неволно или злонамерено издаване на сертификат.
  • Използваме HTTP Strict Transport Security (HSTS), за да гарантираме, че браузърите винаги комуникират с нашите сървъри, използвайки протокола TLS. Освен това включваме нашите домейни в списъците за предварително зареждане .
  • Налага се строга Политика за сигурност на съдържанието, за да се предотвратят атаки между сайтове (XSS) .
  • Използвайки политика за кръстосан източник, политика за вграждане на кръстосан произход и политика за отваряне на кръстосан произход, ние забраняваме кода за кръстосан произход, за да помогнем за смекчаване срещу спекулативни атаки на странични канали като Spectre и Meltdown Това също така предлага защита срещу потенциално злонамерени заявки от друг произход, като изолира контекста на сърфирането изключително към документи от същия произход.
  • Ние използваме Политика за разрешения, за да предотвратим зареждането на браузъра на ресурси, които могат да компрометират поверителността ви, като вашето местоположение, уеб камера, микрофон и др.
  • DNSSEC се използва във всички наши домейни, за да помогне за смекчаване на DNS-базирани MITM атаки.
  • Вземаме редица предпазни мерки, за да защитим сървъра.
  • Не се зарежда код на трета страна (т.е. jQuery) и се зареждат много малко ресурси (продължете и отворете раздела Мрежа в Dev Tools, за да проверите) - това минимизира усилията, необходими за одит. Единственото изключение е, ако се изисква CAPTCHA - който зарежда код на трета страна от hCaptcha . Кодът hCaptcha обаче се зарежда на собствения си URL адрес в собствените си правила на CSP и в нито един момент няма достъп до нещо, свързано със съобщение.
  • Като средство за предпазване от MITM атаки се предлагат разширения на браузъра .

Защо получих връзка тук с опция за дешифриране на съобщение?

Извиняваме се, ако има грешки в този превод . Тази услуга просто предава криптирано съобщение от една точка на друга и вие сте получателят. Съобщението скоро ще бъде изтрито. Операторите на тази услуга нямат начин да прочетат съдържанието на съобщението. Обикновено някой използва тази услуга, когато не иска съдържанието на съобщението да остане в различни бази данни / устройства / услуги / файлове / и т.н. както е типично при изпращане на имейл / незабавно съобщение / текст / и т.н. Ако решите да дешифрирате, моля, имайте предвид следното:

• Вероятно съобщението ще бъде изтрито веднага след като бъде изпратено до вашето устройство за дешифриране. Това означава, че след като щракнете върху бутона за дешифриране на съобщението, вече нямаме копие, което да ви изпратим отново по-късно.
• Систематично изтриваме цялата получена информация. Съобщенията ще бъдат изтрити навсякъде между една минута и две седмици след създаването му - независимо дали съобщението някога е дешифрирано. С други думи, ако трябва да прочетете съобщението, не чакайте твърде дълго, за да го дешифрирате.
• Подателят вероятно вярва, че със съдържанието на съобщението трябва да се работи внимателно. Може дори да са посочили, че искат да не се правят копия. Моля, уважете техните желания.
• Ако бъдете подканени да въведете парола за дешифриране на съобщение, не затваряйте прозореца / раздела на браузъра. Според първата точка в този списък е вероятно да не можем да изпратим друго копие по-късно. Просто оставете прозореца / раздела на браузъра отворени, докато можете да въведете паролата. Ако въведете неправилна парола, ще бъдете подканени отново. Паролата трябва да бъде въведена точно. Имайте предвид, че за да отговорим на различни езици и изисквания за пароли, ние приемаме много различни символи в паролите.

Изтривате всичко изпратено на този сайт?

Вярно с нашето лого на кошчето ... всичко се изтрива скоро след получаването му. Изтриването на всичко е автоматизирано - това се записва в сървъра. Помислете за това по този начин - има два класа подадена информация:

• Шифровани съобщения, за които нямаме средства за дешифриране на съдържанието
• Друга информация, присъща на изпращането на каквото и да е в мрежата (т.е. вашия IP адрес и т.н.)

В случай на съобщения, можете да контролирате кога ги изтриваме, като посочите:

• Колко дълго трябва да пазим съобщението, ако никой не го изтегли (вариращо от 1 минута до 2 седмици - по подразбиране до 1 седмица).
• Колко пъти е изтеглено съобщението (вариращо от 1 до 100 пъти - по подразбиране до 1 път)

По подразбиране всичко за дадено съобщение се изтрива, след като се извлече веднъж или е на 1 седмица - което от двете се случи първо. Когато става въпрос за изтриване на цялата друга информация, присъща на изпращането на каквото и да е в мрежата (т.е. вашия IP адрес и т.н.), ние не ви даваме никакъв контрол върху това кога и как се изтрива - ние просто изтриваме цялата на всеки 24 часа .

Защо да използвам тази услуга?

Тази услуга е инструмент, който помага да направите съобщенията, които изпращате / получавате, по-малко постоянни. Повечето от това, което комуникирате в Интернет (чатове, текстове, имейли и т.н.), се съхраняват и рядко се изтриват. Често, когато изтриете нещо, то всъщност не се изтрива, а по-скоро се маркира като изтрито и вече не ви се показва. Вашите обобщени комуникации се натрупват година след година в бази данни и на устройства, над които нямате контрол. Неизбежно е една или повече от организациите / хората / устройствата, съхраняващи вашите комуникации, да бъдат хакнати и информацията ви да изтече. Този проблем е толкова широко разпространен, че сега има много уеб сайтове, които проследяват организациите, които са били компрометирани и са изтекли потребителски данни. Шифрованите временни съобщения от край до край са просто решение, което помага да направите някои от вашите комуникации по-малко постоянни. Всяко съобщение, изпратено на този сайт, има време за живот, вариращо от 1 минута до 2 седмици - след изтичане на това време съобщението се изтрива. Освен това настройката по подразбиране е да се изтрие всяко съобщение, след като получателят го извлече. Освен това всички съобщения се криптират от вашето устройство до устройството на получателя. Основната цел при използването на криптиране от край до край е да премахнем способността си да четем всички изпратени съобщения, като по този начин премахваме част от изискването за доверие. Крайният резултат е, че вече е лесно да изпратите криптирано съобщение чрез проста връзка. Това съобщение се изтрива скоро след изпращане или при изтегляне. Не е необходимо да инсталирате / конфигурирате специален софтуер. Не е необходимо да създавате акаунт или да предоставяте каквато и да е лична информация. Получателят не трябва да е във вашите контакти или дори да знае за тази услуга - единственото изискване е да може да щракне върху връзка.

Това услуга за съобщения ли е?

Не. Тази услуга е предназначена да допълва съществуващите услуги за съобщения като незабавни съобщения / имейл / текст / и т.н. чрез добавяне на способността да се предотврати съхраняването на изпратени съобщения за дълго време. Ние не доставяме генерираната връзка на получателя .

Какви са предвидените случаи на употреба?

И така, какви са някои сценарии, при които е подходящо да се използва тази услуга? Въпреки че всеки има различни нужди и изисквания, що се отнася до тяхната поверителност и сигурност, аз лично намерих следните сценарии като подходящи случаи на употреба:

• Вие общувахте чрез местен уеб форум за пътеки за планинско колоездене в района и понякога се срещате с хора във форума, за да проверите заедно нови пътеки. Някой от форума иска да ви вземе у вас, за да пътувате с кола до пътека този уикенд. Не искате вашият домашен адрес да стои завинаги в тази база данни на форума на този уеб сайт. Просто изпратете адреса чрез тази услуга - връзката е тази, която се намира в базата данни на форума на уебсайта, но след като бъде прочетена от получателя, съобщението / адресът се изтрива.
• Трябва да изпратите на брат си данните си за вход в Netflix, защото племенницата ви го подлудява поради блокиране на COVID и той все още няма собствен акаунт. Не се интересувате твърде много от това влизане, но брат ви е особено зле в това, което аз просто ще нарека „цифрова хигиена“ и е имал много изпитания с компрометирани данни за вход и злонамерен софтуер. Последвалите опити да го накара да изчисти постъпката си и дори инсталирането на сигурни съобщения за него не успяха да се придържат. Простото изпращане чрез текстово съобщение е може би най-добрият вариант (за съжаление), но ви е неудобно да имате това влизане в неговата история на съобщенията поради миналия опит. Използването на тази услуга за изпращане на данните за вход чрез връзка в текстово съобщение удовлетворява не позволяването на данните за вход да останат завинаги в неговата история на чата.
• Понякога работите в офис, в който има много общи наематели, които идват и си отиват по всяко време. Налице е WiFi за използване, но паролата се върти всяка седмица, тъй като има проблеми със злоупотреба. Много наематели изпращат имейл / текст с искане за парола за WiFi, въпреки че е на рецепцията, тъй като повечето не влизат през предния главен вход. Използвайки тази услуга, мениджърът на офиса може да изпрати паролата за WiFi чрез връзка в имейл / текстов отговор, като не позволява паролата да се задържи, а също така позволява на получателя незабавно да копира паролата чрез бутон за копиране, който е по-малко тромав на мобилните устройства.
• Един от вашите доставчици на хостинг ви пита за подробности за сървър, за който сте докладвали, че показва признаци на твърд диск, който изглежда се разваля. Част от информацията, от която се нуждаят, е малко чувствителна - не искате тя да стои вечно в системата за билети на трета страна, която използват. Използвайки тази услуга, можете да изпратите информацията на техниците за поддръжка, без тя да се намира в системата за билети. Тъй като може да се наложи няколко техници да се позовават на информацията многократно, задайте стойностите за четене на живо по-големи от 1 (т.е. може би 20), така че съобщението да не се изтрива при първото извличане.
• Трябва да изпратите лично съобщение до друг потребител на Reddit, за да му съобщите телефонния номер, за да може да ви се обади. Reddit, както и много други доставчици, изтича информация за потребителите в миналото и не искате телефонният ви номер да стои в базата данни на Reddit в продължение на години до следващото изтичане. Просто изпратете телефонния си номер чрез тази услуга.
• Съпругът ви ви изпраща съобщения, докато сте на работа, за да искате да влезете в помощната програма, защото нейният приятел току-що опита нова програма, която й спести пари от сметката за електричество и тя иска да я провери. Има споделен мениджър на семейни пароли, за който й напомняте, но тя просто иска да изпратите данните за вход. OMEMO се използва за незабавни съобщения с вашия съпруг и затова се чувствате много уверени, че транспортът на съобщения е сигурен; обаче самата история на чата се съхранява нешифрована. Съпругът ви не винаги е предпазлив по отношение на изтеглянията, имейлите и т.н., а сметките за комунални услуги са малко чувствителни, тъй като могат да бъдат използвани за кражба на самоличност, за да се докаже местожителство. Можете да й изпратите данните за вход, използвайки тази услуга, за да избегнете съхранение на копие на нейния компютър.

За какво не трябва да се използва тази услуга?

Тази услуга не трябва да се използва за много чувствителна информация поради всички причини, обяснени в този FAQ. По-долу са дадени някои примери за това, което не трябва да се прави:

• Не използвайте тази услуга, за да направите неподходящ транспорт на съобщения „по-сигурен“. Тъй като настройката по подразбиране е да включва паролата в URL адреса, който може да прочете съобщението, всеки с връзката може да прочете съобщението. Както бе споменато по-горе, всички проблеми със сигурността / поверителността, присъщи на избрания транспорт (т.е. текст), се наследяват, когато използвате този инструмент. Така например, ако никога не бихте помислили да използвате имейл за изпращане на конкретна информация поради нейния чувствителен характер, не бива да използвате тази услуга, за да „защитите“ тази част от имейла.
• Не използвайте тази услуга, за да сте сигурни, че не се прави копие на съобщението. Това, че изтриваме нашето копие на криптираното съобщение веднага след извличането и затрудняваме копирането, не означава, че съобщението не може да бъде копирано. Какво ще стане, ако получателят направи снимка на екрана си? Ами ако просто напишат съобщението? В крайна сметка, ако получателят може да прочете съобщението - може да се направи копие.
• Не използвайте тази услуга, за да сте сигурни, че съобщението не може да бъде проследено до вас. Тази услуга зависи от друг доставчик на транспорт на съобщения (т.е. имейл, чат и т.н.), за да получи съобщението от една точка до друга. Използваният транспорт за съобщения може много добре да проследи съобщението до вас.
• Не използвайте тази услуга за изпращане на всичко, което искате да откажете. Това, че самото съобщение е изтрито, не означава, че връзката, сочеща към изтритото съобщение, е изтрита. Ако изпратите имейл до ваш приятел и част от този имейл има връзка към съобщение от тази услуга, случаен читател ще разбере, че в съобщението има нещо друго. Дори съобщението, посочено от връзката, отдавна да е изчезнало - ясно е, че е изпратено нещо друго и че е изпратено от вас до ваш приятел.

Защо просто да не използваме PGP / Signal / OMEMO / Matrix / и т.н.?

Ако познавате човека, на когото искате да изпратите сигурни временни съобщения, изпращате ги често, очаквате интерфейс, подобен на чат, и / или можете да очаквате получателят да има необходимия софтуер и да знае как да го използва, този уебсайт вероятно не е най-доброто решение. Има страхотни опции, които са с отворен код, поддържат E2EE, а не уеб-базирани и дори някои като Signal, които също поддържат временни съобщения. Аз лично използвам частен XMMP сървър и OMEMO за чат с близки приятели и семейство. Използването на този сайт може да е оптимално само ако не знаете какъв софтуер работи получателят, не знаете техния телефонен номер / дръжка за контакт, не познавате техническите си умения (но приемете, че могат да щракнат върху връзка), или просто предпочитате да запазите съобщението, което изпращате, извън основния транспорт за комуникация.

Какви изисквания съществуват?

Изисква се модерен и актуален уеб браузър, който правилно прилага стандарти, включително Web Crypto API. Примерите включват: Chrome, Firefox, Edge и Safari (около 2020 г. или по-късно).

Може ли получателят да направи копие на съобщението?

Да. Въпреки че съобщението може да се изтрие при изтегляне, получателят пак може да го види. Винаги когато получателят може да разгледа напълно съобщението, може да се направи копие - това се отнася за всички комуникации. Има опция за затрудняване на получателя да направи копие. В този случай се прилагат три пречки за копиране:

• Бутонът за копиране е премахнат. Този бутон по подразбиране позволява на получателя да копира цялото съобщение в своя клипборд.
• Бутонът за изтегляне е премахнат. Този бутон по подразбиране позволява на получателя да изтегли съобщението като текстов файл.
• Възможността за избор на текст в текстовото поле на съобщението е премахната.

Тези защити срещу копиране обаче са слаби, защото могат да бъдат заобиколени. Също така получателят винаги може просто да направи екранна снимка или снимка на съобщението.

Събира ли се лична информация?

Не поддържаме потребителски акаунти (т.е. потребителско име / парола). Ние не събираме никаква информация, която може да ви идентифицира (т.е. име / адрес / имейл / телефон). Възможно е в съобщението, което изпращате, да има някаква лична информация, но тя е криптирана и няма как да я прочетем. Моля, прегледайте нашата политика за поверителност за пълни подробности.

Каква информация се регистрира?

Нашият уеб сървър поддържа до 24 часа общ дневник във всички уеб дейности. Това включва регистриране на пълния IP адрес на HTTP клиенти. След 24 часа тази регистрирана информация се изтрива автоматично. Всички заявки, изпратени до / api, се публикуват, което означава, че уеб сървърът никога не регистрира конкретна информация за съобщението. Освен това всяка информация, записана в базата данни, се записва ефективно. Всички записи в базата данни, включително анонимизирани и хеширани IP адреси, имат време на изтичане (TTL), след което автоматично се изтриват. Времето за изтичане на TTL варира между 1 минута и 2 седмици.

Какво правите, за да защитите сървърите?

Сигурността на сървъра е очевидна грижа. Има две основни области, върху които се фокусираме, за да бъдем сигурни:

• Първо, ние съхраняваме възможно най-малко за възможно най-малко време, така че ако сървърът някога бъде компрометиран, всяко изтичане на информация няма да навреди на нашите потребители. Всички съобщения, съхранявани в базата данни, са шифровани, без средства за тяхното декриптиране. Няма съхранено нищо, което да свързва някакво съобщение с някой от нашите потребители, тъй като не събираме никаква лична информация от нашите потребители. Всички записи в базата данни имат време на изтичане (TTL), вариращо от 1 минута до 2 седмици - след изтичането на това време записът се изтрива автоматично. Следователно, по-голямата част от информацията, която някога е била в базата данни, вече е била изтрита отдавна.
• Ние предприемаме редица мерки за предотвратяване на компромис и съдържаме всеки компромис, който се случи:
  • Уеб сървърът, nginx , се изпълнява в изолиран контейнер като непривилегирован потребител, без достъп за запис до нищо различно от регистрационните файлове. Контейнерът се изпълнява в рамките на собствения си контекст на SELinux, като допълнително предотвратява промени в файловата система или лесно излизане от контейнера. Няма поддръжка за PHP / ASP / JSP / и т.н. - просто обслужване на статични ресурси.
  • Кодът, който се изпълнява / api, е написан в Go, което би трябвало да го направи доста устойчив на буфериране на уязвимости при препълване (често срещан вектор за атака). Процесът Go също се изпълнява в изолиран контейнер като потребител без право на достъп, без достъп до запис, различен от базата данни. Контейнерът се изпълнява в рамките на собствения си контекст на SELinux, като допълнително предотвратява промени в файловата система или лесно излизане от контейнера. Базата данни, badgerdb , е част от процеса Go (без външна зависимост / процес на база данни).
  • Основната опасност от компромис със сървъра е, че нападателят може да модифицира файлове по начин, който би застрашил поверителността / сигурността на нашите потребители. Специален процес следи всички файлове на уебсайта за всякакви промени и ни предупреждава незабавно в случай на промяна.
  • Целият административен достъп е защитен и ограничен до оторизирани мрежи.

Какви рискове за сигурността са налице при използването на този сайт?

Преди да разгледам конкретно някои от тези рискове, мисля, че полукратка аналогия може да помогне за обобщаване на рисковете при използването на всякакви интернет комуникации. Визуализирайте, че всяка система е толкова сигурна, колкото най-слабото звено във веригата. Сега си представете сценарий, в който има двама души в запечатана стая без никакви средства да видят, чуят или запишат каквото и да било. Единият ще предаде съобщение на другия, който при прочитането му ще го изгори. Ако някой извън тази стая иска да получи съобщението, което вече е било предадено, това ще бъде трудно. Коя е най-слабата връзка за получаване на съобщението? Няма толкова много връзки, от които да избирате - това е доста къса верига. Сега си представете, че когато изпратите съобщение в интернет, че има поне един милион връзки във веригата - много от тях слаби - много от тях напълно извън вашия контрол - и това е реалност.

Използването на криптиране може значително да помогне за горепосочения проблем с връзката и е лесно да бъдете привлечени да мислите, че добре проектираните системи E2EE предлагат крайното решение. Това мислене обаче може да ви създаде неприятности, защото нападателят обикновено просто преследва по-слабите връзки в системата. Например, вероятно е много по-лесно да поемете телефона или компютъра си и да настроите входен регистратор, за да чете само всичко, което въвеждате, отколкото да разбивате криптирани съобщения по проводника. Изводът е, че ако ми беше възложена задачата да предам тайна от жизненоважно / критично значение, щях да използвам електронните комуникации само като краен метод.

Така че съществуват рискове за сигурността при използване на всякакви комуникации, но все пак използвате уеб браузър за банкиране, купуване на неща, имейл и т.н. Това е приет риск за огромните спечелени удобства. Наистина въпросът е ... какви рискове за сигурността са полуспецифични за този сайт? Няколко идват на ум:

• Може би най-големият и най-уникалният за тази услуга е, че нашите потребители няма да използват добра преценка, когато различават кое е подходящо да се изпрати и кое не е подходящо да се изпрати . Понякога разграничението между „Удобно ми е да изпращам тази информация по имейл - просто ми се иска имейлът да бъде изтрит след четене“ и „Не ми е удобно да изпращам тази информация по електронната поща - имейл е неподходящ транспорт“ може да бъде доста фино.
• Винаги съществува заплаха, че операторите на този сайт всъщност са лоши актьори, примамващи хората да използват услугата, за да получат някаква мрачна крайна цел. Попадаме на правдоподобно надеждни - направете всичко лесно и безплатно - накарайте много хора да използват услугата - през цялото време със зловещо намерение. Bwhahahahaha! Как бихте могли да ни се доверите?
• Има шанс нашият код да има грешки, които оказват влияние върху сигурността или просто не сме обмислили добре нещата и нашите недостатъци сега излагат потребителите ни на ненужна опасност. Надяваме се, че не - но не можем да го изключим.
• За разлика от технологичните титани (т.е. Google / Facebook / Whatsapp), които имат терабити от криптирани данни, които непрекъснато се вливат и излизат от огромните им мрежи, където е лесно частните комуникации да се смесват с друг трафик, самостоятелни централизирани услуги (т.е. Signal, Telegram и ние) се открояват. Лесно е за мрежов оператор или дори за голяма организация / правителство да види, че IP адресът xxxx използва услугата XYZ.
• Макар и да не са специфични за този сайт, тъй като той може да се използва срещу всеки уеб сайт, атаките „човек в средата“ (MITM) са основателна грижа .

Какво правите с атаките „човек в средата“ (MITM)?

Всички потребители на уеб сайтове могат потенциално да станат жертва на MITM атака - този сайт не се различава от всички останали в мрежата в това отношение. MITM атака е, когато нападателят е в състояние да прихваща и модифицира комуникациите между браузъра на потребителя и уеб сървъра на сайта. Това позволява на нападателя да модифицира кода / съдържанието на сайта, като същевременно се показва на крайния потребител като сайта, с който е свикнал. Предприемаме някои мерки, за да затрудним MITM атаката:

• HSTS се използва, за да принуди браузърите да се свързват само чрез TLS. Нашият сървър е конфигуриран да игнорира комуникация, различна от TLS, освен да пренасочва. Поддържат се само TLS 1.2 или по-нова версия.
• DNSSEC се използва за подписване на зоната на нашия домейн. Това може да спре DNS подправянето на внедрени MITM атаки, ако потребителят използва DNSSEC осъзнат рекурсивен преобразувател.
• Използваме услуга за наблюдение на сертифициращи органи, които издават неупълномощени TLS сертификати, отнасящи се до нашия домейн.
• Публикувахме разширения на браузъра, за да поддържаме криптиране на съобщения, използвайки код, съхраняван на устройството на крайния потребител.

MITM атака обаче все още е възможна - особено ако нападателят контролира мрежова / публична ключова инфраструктура, какъвто би бил случаят за големи / мощни организации или правителства. Ние предлагаме разширения на браузъра, които могат да помогнат за намаляване на някои MITM рискове.

Какви предимства предлагат разширенията на браузъра?

Ние предлагаме разширения на браузъра като средство за осигуряване на допълнително удобство и допълнителна сигурност. Просто казано ... Разширенията правят изпращането на временни съобщения по-бързо и лесно. Получава се и известна сигурност, защото целият код, използван за криптиране и подготовка на съобщение, се съхранява локално в разширението. Тъй като кодът се съхранява локално, това предлага на подателя известна защита срещу MITM атаки . Струва си обаче да се отбележи, че докато разширенията предлагат по-голяма защита срещу MITM атака, която компрометира съдържанието на съобщението, MITM атака все още може да бъде ефективна (т.е. за определяне на IP адреса на подателя, ако не се използва TOR / VPN / и т.н.).

Как мога да знам със сигурност, че всичко изпратено е криптирано от край до край?

За разлика от много други популярни криптирани (E2EE) клиенти за чат, е доста лесно да видите точно какво ни се изпраща, когато изпращате съобщение. По-долу видеоурокът показва как да потвърдим, че нямаме начин да дешифрираме съобщенията, изпратени до сървъра.

Освен това, ако се замислите, стига да не сме някаква тайна агенция, която се опитва да събира чувствителни съобщения, няма полза за нас да можем да дешифрираме съобщения, тъй като тази възможност само ни създава проблеми. Ние дори не искаме да съхраняваме съобщения - необходимото зло е да ги доставим обаче.

Как работи криптирането от край до край на този сайт?

Понастоящем използваме симетрично криптиране (AES-GCM 256bit) с ключове, получени от пароли (минимум 150 000 повторения на PBKDF2 / SHA-256). Асиметричното криптиране не се използва, защото съществуват изисквания за 1) подател, иницииращ комуникацията 2) изпращач и получател, които не са едновременно онлайн и 3) липсва информация за получателя и 4) ние се опитваме да поддържаме нещата реални прости и управлението на ключовете е сложно. Стандартният уеб крипто API се използва за цялата криптографска функционалност, включително RNG. По принцип ето какво се случва:

1. Крайният потребител избира парола или тя се генерира автоматично
2. Извършва се API извикване, за да се получи броят на необходимите итерации PBKDF2 / SHA-256 ( тази стъпка е необходима за контрол на спама )
3. Генерира се 32 байтова сол
4. Ключът е извлечен от солта и паролата
5. Генерира се 12-байтов вектор за инициализация (IV)
6. Съобщението се кодира с помощта на клавиша + IV
7. Броят на итерациите, солта, IV и шифърът се изпращат към сървъра (заедно с друга информация като TTL, RTL и др.)
8. Сървърът връща произволен идентификатор, отнасящ се до съобщението
9. След това браузърът представя на крайния потребител връзка, която съдържа върнатите ID и парола или връзка без паролата (в този случай получателят трябва да знае и да въведе паролата)
10. Ако паролата е част от връзката, тя е в хеша на URL адреса и следователно никога не се изпраща до сървъра, когато получателят направи заявката GET
11. Получателят ще бъде подканен, ако желае да дешифрира и прегледа съобщението
12. Браузърът отправя заявка, посочвайки идентификатора на съобщението
13. Ако подателят изисква попълване на CAPTCHA, получателят се насочва към друг URL, за да докаже, че са хора (след като преминат, те се насочват обратно)
14. Сървърът изпраща шифрованото съобщение и по подразбиране ще изтрие съобщението в този момент, ако четенето за предаване (RTL) е едно
15. Получателят ще дешифрира съобщението с паролата (и ще бъде подканен за паролата, ако не е в URL адреса)

Тази настройка е изключително проста и предлага криптиране на съобщението от устройството на подателя до устройството на получателя, но разбира се липсва гаранцията, която асиметричното криптиране може да предложи по отношение на това, че само някой, притежаващ частния ключ на получателя, може да дешифрира съобщението. Всеки с връзката може да отвори съобщението в сценария по подразбиране, при който паролата е част от URL адреса - това подчертава значението на използването на подходящ транспорт за връзката (т.е. имейл / чат / текст / и т.н.) - решение, оставено на подател. Може да имаме, ако има интерес, да пуснем и поддръжка за една много основна асиметрична схема, при която получателят инициира заявка за съобщение и изпраща тази връзка към подателя на съобщението. Тази настройка би премахнала необходимостта от парола в URL адреса, но също така елиминира възможността подателят да инициира.

Паролата за дешифриране може да е в URL адреса?

Да. Това очевидно се отразява на сигурността, защото ако методът, използван за изпращане на връзката, е несигурен, съобщението е несигурно чрез асоцииране. Всички решения за отстраняване на този проблем въвеждат допълнителни стъпки и сложности, които оказват влияние върху потребителския опит (т.е. нещата трябва да бъдат настроени в двата края преди изпращане на съобщението). Асиметрична схема, при която получателят инициира заявка за съобщение и изпраща тази връзка за заявка, може да работи с нашето ключово изискване "всичко е краткотрайно" - това може да бъде приложено. В крайна сметка, ако две страни ще си изпращат съобщения често, съществуват по-добри решения, при условие че и двете страни могат да се справят с използването на тези решения.

Но паролата за декриптиране не трябва да е в URL адреса?

Правилно. Ако паролата за декриптиране не е включена във връзката, получателят ще бъде подканен да я въведе. Ако паролата е сигурно съобщена на получателя (или те вече я знаят), това осигурява защита срещу прихващане. Недостатъкът обаче е, че получателят трябва да знае и правилно да въведе паролата. Ето един начин да изпратите паролата до получателя, който предлага известна защита срещу прихващане:

1. Криптирайте паролата в съобщение с настройките по подразбиране и изпратете тази връзка на получателя.
2. Когато получателят кликне върху връзката и дешифрира съобщението, те знаят, че никой друг не е получил паролата преди тях, тъй като съобщението, съдържащо паролата, се изтрива при извличане. Въпреки това, ако има активна MITM атака или ако вашето устройство или устройството на получателя е било компрометирано, все още е възможно друга страна да получи паролата.
3. Потвърдете с получателя, че успешно са получили паролата. Например, ако получателят ви информира, че когато е отишъл да извлече паролата, че съобщението вече е било изтрито, тогава знаете, че някой друг е получил паролата преди получателя и че паролата следователно е компрометирана и не трябва да се използва.
4. Използвайки паролата, която получателят потвърди, че притежава, сега можете да изпратите съобщение, използвайки същата парола за криптиране - просто споделете версията на връзката, която не съдържа паролата.

Тази услуга не доставя връзката на получателя?

Това е правилно - генерираме връзката и я оставяме на подателя как най-добре да я доставим на получателя. Целта на тази услуга е да предостави опция, предлагаща по-малко постоянство в съществуващите транспортни съобщения като имейл / чат / текст / и т.н. Следователно, очакването е, че връзката, която генерираме, която сочи към временното съобщение, се изпраща чрез съществуващ транспорт на съобщение. Това има последици за сигурността, които потребителите трябва да разберат. Нека вземем SMS текстово съобщение като пример, тъй като това е доста несигурен метод за комуникация. Когато използвате тази услуга за изпращане на временна връзка към съобщение чрез текстово съобщение, ако използвате режима по подразбиране, при който паролата е включена в връзката, всеки с връзката може да прочете съобщението и не се предлага защита срещу прихващане. Тази услуга все още осигурява по-временна комуникация, която може да подобри поверителността и сигурността. Освен това можете да изберете да изпратите връзката без парола и това ще осигури защита срещу прихващане.

Как мога да защитя поверителността си възможно най-много, докато използвам тази услуга?

Както беше обсъдено на друго място в този често задаван въпрос, въпреки че вече правим много за защита на вашата поверителност и въпреки че не събираме никаква лична информация, част от информацията, свързана с регистрационния файл, се изпраща и събира от нас и други по силата на вас, използвайки уеб браузър. Има обаче множество начини да защитите поверителността си още повече. Един от начините, който е безплатен за използване, базиран на софтуер с отворен код и работи доста добре, е използването на Tor Browser . Този браузър е проектиран да защитава поверителността ви на множество нива - включително използването на мрежата Tor . Нашият сайт вече е достъпен чрез Tor onion мрежа, което означава, че достъпът до нашия сайт чрез Tor не изисква използването на изходен възел, който отрича някой, който подслушва трафика на изходния възел . Имайте предвид обаче, че дори в този сценарий вашият доставчик на интернет може да види, че използвате Tor - макар и не за какво. Можете дори да се свържете с VPN и след това да стартирате Tor Browser за два слоя анонимност; имайте предвид обаче, че вашият доставчик на интернет все още вижда, че използвате VPN в този сценарий - макар и не за какво. Ако не искате вашият доставчик на интернет да знае какви протоколи използвате, можете да се свържете с голяма обществена WiFi мрежа като библиотека, училище и т.н. и след това да използвате браузъра Tor.

Ами ако нямам доверие на САЩ?

Нашите сървъри се намират в САЩ. Освен това нашият доставчик на CDN, Cloudflare, е компания със седалище в САЩ. Опитахме се да премахнем необходимостта да се доверяваме на нас или на държавата, в която се намират нашите сървъри, просто защото не събираме лична информация, не можем да дешифрираме съобщения и всичко се изтрива малко след получаването му. Въпреки това можем да разберем известно недоверие, тъй като то е уеб-базирано и особено ако живеете в определени страни. Имаме някои планове да предложим опции в Исландия и Швейцария за хора, които трудно се доверяват на САЩ. Моля, уведомете ни, ако това се отнася за вас, тъй като няма да сме мотивирани да предлагаме алтернативи, освен ако няма реално търсене.

Какво правите, за да предотвратите спама?

Всеки път, когато позволите на някого да публикува съобщение, което може да бъде предадено чрез връзка, вие каните спамери. Ограничаването на този проблем не е напълно лесно. Не искаме да зареждаме CAPTCHA на трета страна като част от процеса на изпращане на съобщения по няколко причини:

• Мразим CAPTCHA - те отнемат време и са досадни
• Зареждането на javascript от трета страна може да навреди на поверителността и сигурността
• Пускането на собствения ни CAPTCHA означава, че се записваме за безкрайна игра whack-a-mol
• В крайна сметка хората може да искат да могат да взаимодействат с тази услуга чрез API

Може би бихме могли да заобиколим проблема с API чрез използване на някаква API ключова система, но тогава трябва да съберем потребителска информация, която не искаме да правим. Също така, какво е да спрете спамерите да получават много API ключове? Не можем да разглеждаме съобщенията, за да направим извод за тяхната нежеланост (което в най-добрия случай е много проблематично), тъй като освен шифроването на съобщенията, ние имаме политика за предаване на съдържание на съобщението. Предвид тези изисквания, ние използваме два метода за предотвратяване на нежелана поща:

• Увеличаване на броя на необходимите итерации PBKDF2 / SHA-256
  Всички съобщения могат да бъдат извлечени само малък брой пъти - непривлекателен атрибут за спамерите, тъй като разчитат на изпращане на много съобщения. Тъй като спамърът ще трябва да създаде много съобщения за дадена спам кампания - ние избрахме да направим тази задача толкова изчислително скъпа, че да направим злоупотребата с тази услуга за нежелана поща непривлекателно начинание. Това се постига чрез проследяване на мрежите, които публикуват съобщения - измерени като общи възможни извличания. Самата мрежова информация е сигурно хеширана, така че да не можем да направим заключение за реалната мрежа от хеша. Тъй като дадена мрежа публикува повече съобщения, ние увеличаваме броя на итерациите PBKDF2 / SHA-256, необходими за публикуване на следващото съобщение. Това много бързо води до много време на процесора, за да се публикува само едно съобщение. Надяваме се, че този метод ще бъде подходящ за ограничаване на злоупотребата със спам и в същото време няма да засегне реалните потребители.
• Събирайте отчети за нежелана поща от потребители, когато те извличат съобщение
  Има бутон „Доклад за спам“ точно под съобщението, когато потребителят изтегли съобщение. Ако съобщението е спам, надяваме се, че някои ще отнеме 3 секунди, необходими за щракване върху този бутон. Когато получим доклад за спам, той ни предупреждава и също така влияе върху необходимите итерации PBKDF2 / SHA-256 за дадена мрежа.

Ако знаете, че спамерите злоупотребяват с тази услуга, моля, подайте сигнал за злоупотреба .

Защо има опция да се изисква получателят да попълни CAPTCHA?

Въпреки че е вярно, че не харесваме CAPTCHA, ние осъзнаваме, че те служат на определена цел и имат време и място (поне засега). Това е прост начин за подателя да получи известна увереност, че получателят е човек и че автоматизираните процеси нямат достъп до съобщението.

Кой използва тази услуга и защо е безплатна?

Ние сме просто двойка момчета, които понякога са били изправени пред затруднението да не разполагат с добри опции, които да ни помогнат да защитим поверителността си. Често това се дължи на общуването с приятели и членове на семейството, които не са особено внимателни с начина, по който се справят с техните устройства и информация. Понякога това се е случвало при използване на уеб базирани форуми като Reddit или при използване на уеб базирани системи за поддръжка. Открихме някои уеб базирани решения за временни съобщения, но нито едно не предлага E2EE, което означава, че не можем да им вярваме. Така че ние просто изградихме наше собствено решение и решихме да го подарим, за да могат другите да се възползват от него.

Как мога да се доверя на отговорите на горните въпроси?

Наистина не бива да се доверявате на който и да е уеб сайт, само защото той казва определени неща - обикновено е добра идея да проверите каквито и да било искове. Опитахме се да премахнем изискването да ни се доверяваме възможно най-много чрез използване на криптиране от край до край. Например, доста лесно е да се провери, че не можем да четем съобщения, тъй като те са криптирани . Също така поддържаме много прост кода на javascript, работещ на този сайт, така че да е лесен за четене и разбиране. Осъществяването на целия код с отворен код позволява на хората да проверят какво работи; имайте предвид обаче, че няма начин наистина да проверите какво работи сървърът. Макар да е вярно, че голяма част от изискването за доверие се премахва с криптиране от край до край, все още е фактор, който нашите потребители претеглят много, когато решават да използват тази услуга или не.