Питання що часто задаються
- Чому цей сайт погано перекладений? ⎃
- Наскільки безпечна ця послуга?
- Чому я отримав тут посилання з можливістю розшифрувати повідомлення?
- Ви видаляєте все, що надійшло на цей сайт?
- Навіщо користуватися цією послугою?
- Це послуга обміну повідомленнями?
- Які випадки використання призначені?
- Для чого не слід використовувати цю послугу?
- Чому б просто не використовувати PGP / Signal / OMEMO / Matrix / тощо?
- Які вимоги існують?
- Чи може одержувач зробити копію повідомлення?
- Чи збирається якась особиста інформація?
- Яка інформація реєструється?
- Що ви робите для захисту серверів?
- Які ризики безпеки існують при використанні цього веб-сайту?
- Що ви робите щодо атак "людина посередині" (MITM)?
- Які переваги пропонують розширення браузера?
- Як я можу точно знати, що що-небудь подане зашифроване наскрізне?
- Як працює наскрізне шифрування на цьому веб-сайті?
- Пароль для розшифровки може бути в URL-адресі?
- Але пароль для розшифровки не обов’язково повинен бути в URL -адресі?
- Ця послуга не доставляє посилання одержувачу?
- Як я можу максимально захистити свою конфіденційність під час використання цієї послуги?
- Що робити, якщо я не довіряю США?
- Що ви робите для запобігання спаму?
- Чому існує можливість вимагати від одержувача заповнення CAPTCHA?
- Хто використовує цю послугу і чому вона безкоштовна?
- Як я можу довіряти відповідям на вищезазначені питання?
Чому цей сайт погано перекладений? ⎃
Вибачте, але нинішні автори розмовляють лише англійською мовою. Нам потрібна допомога у перекладі цього проекту на інші мови. Як простий і недорогий засіб зробити цю послугу доступною для людей, які не володіють англійською мовою, ми використовуємо машинний переклад. Зазвичай результати є прийнятними, але можуть спричинити дивні формулювання або навіть зовсім неточну інформацію. Ви можете допомогти нам покращити досвід роботи для всіх - надішліть правильний переклад .
Наскільки безпечна ця послуга?
Ми зробили багато кроків, щоб зробити цю послугу безпечною для використання за призначенням. Перш ніж перейти до цих кроків, важливо зрозуміти наступне:
- Хоча ми не можемо прочитати ваше повідомлення через наскрізне шифрування , створене посилання за замовчуванням містить пароль / ключ для розшифрування ; а отже, кожен, хто має посилання, може прочитати ваше повідомлення - включаючи всіх, хто може його перехопити.
- Ця послуга - це лише інструмент, що дозволяє надсилати менш постійні повідомлення (тобто зашифровані повідомлення, які видаляються під час отримання) за допомогою традиційних транспортних засобів, які є більш постійними (тобто електронна пошта / текст / обмін миттєвими повідомленнями / веб-сайт / тощо. Це означає, що будь-які проблеми безпеки / конфіденційності, властиві вибраному транспорту (тобто електронна пошта), успадковуються під час використання цього інструменту .
- Доступні й інші рішення, які забезпечують кращий захист залежно від ваших потреб та оточення. Головною перевагою, яку пропонує ця послуга порівняно з іншими, є набагато нижчі вимоги до одержувача (тобто їм просто потрібен веб-браузер і можливість натискати посилання).
- Хоча за замовчуванням налаштуваннями є видалення повідомлень при отриманні, одержувач нічого не заважає зробити копію . Майте на увазі, що це стосується всіх тимчасових рішень для повідомлень - якщо одержувач бачить повідомлення, його можна скопіювати.
- Усі інтернет-комунікації можуть порушити вашу конфіденційність - ви торгуєте певною безпекою для зручності.
- Що стосується безпеки, Інтернет є складним середовищем через деякі основні проблеми - це стосується всіх веб-сайтів. Однак наявність веб-сервісу полегшує перевірку нашої заяви про те, що ми не можемо прочитати ваше повідомлення набагато простіше .
- Цей веб-сайт та його база даних розміщені в США. Ми використовуємо Cloudflare, компанію, що базується в США, як нашу мережу доставки вмісту (весь веб-трафік проходить через цю мережу).
- Використання послуги не вимагає жодної особистої інформації (тобто імені / електронної пошти / телефону / тощо). Немає системи облікових записів (тобто логін / пароль / тощо); отже, будь-яке порушення даних не може просочувати цю інформацію.
- Весь вміст повідомлення наскрізне зашифроване . Іншими словами, ключ / пароль для дешифрування нам ніколи не надсилається. Отже, ми, або хтось інший, хто має базу даних, не маємо засобів для дешифрування та перегляду вмісту повідомлення.
- Кожен запис у нашій базі даних має час життя від 1 хвилини до 2 тижнів (за замовчуванням до 1 тижня). Після закінчення цього часу запис автоматично видаляється. Тому будь-яка інформація в нашій базі даних буде видалена незабаром після її створення .
- Ми підтримуємо лише останні 24 години журналів веб-серверів . Будь-яка інформація про IP, що зберігається в базі даних, надійно хешована, що робить неможливим отримання оригінального IP.
- Весь код, що працює на цій службі, є відкритим і доступний для перевірки. Ви можете легко побачити код, який запускає шифрування - який навмисно короткий, стислий та коментований.
- Для посилення безпеки вживається ряд технічних запобіжних заходів, серед яких є:
- Весь цей веб-сайт, крім / api, є статичним і не підтримує серверний код на сторінках (тобто PHP / JSP / ASP / тощо).
- API Web Crypto , який є частиною браузера, використовується для шифрування всього вмісту повідомлень.
- TLS використовується для шифрування зв'язку між вашим браузером та нашими серверами. Це допомагає гарантувати, що код не може бути перехоплений або змінений під час передачі. Підтримується TLS 1.3, але ми також підтримуємо TLS 1.2 для старих пристроїв. Старі версії TLS вимкнено, оскільки вони не настільки захищені.
- Журнали прозорості сертифікатів контролюються на предмет помилок у видачі сертифікатів. Крім того, ми публікуємо політику уповноваженого органу із сертифікації (CAA), щоб зменшити ризик ненавмисних або зловмисних помилок.
- Ми використовуємо HTTP Strict Transport Security (HSTS), щоб гарантувати, що браузери завжди спілкуються з нашими серверами, використовуючи протокол TLS. Крім того, ми включаємо наші домени в списки попереднього завантаження .
- Для запобігання атакам між сайтами (XSS) застосовується сувора Політика безпеки вмісту .
- Використовуючи політику перехресного джерела, політику вбудовування перехресного походження та політику відкриття перехресного походження , ми забороняємо код перехресного походження, щоб допомогти пом’якшити ситуацію проти спекулятивних атак бічних каналів, таких як Spectre і Meltdown. Це також забезпечує захист від потенційно шкідливих запитів з іншого походження, ізолюючи контекст перегляду виключно до документів того самого походження.
- Ми застосовуємо політику дозволів, щоб запобігти завантаженню браузером ресурсів, які можуть порушити вашу конфіденційність, наприклад ваше місцезнаходження, веб-камера, мікрофон тощо.
- DNSSEC використовується на всіх наших доменах, щоб допомогти пом'якшити атаки MITM на основі DNS.
- Ми вживаємо ряд запобіжних заходів, щоб захистити сервер.
- Не завантажується сторонній код (тобто jQuery) і завантажується дуже мало ресурсів (відкрийте вкладку Мережа в Dev Tools для перевірки) - це мінімізує зусилля, необхідні для аудиту. Єдиний виняток - це якщо потрібно CAPTCHA - який завантажує сторонній код із hCaptcha . Однак код hCaptcha завантажується на власну URL-адресу всередині своїх власних правил CSP і жодного разу не має доступу до будь-чого, що має відношення до повідомлення.
- Як засіб захисту від атак MITM доступні розширення браузера .
Чому я отримав тут посилання з можливістю розшифрувати повідомлення?
Просимо вибачення, якщо у цьому перекладі є помилки. Ця послуга просто передає зашифроване повідомлення з однієї точки в іншу, і ви є одержувачем. Повідомлення незабаром буде видалено. Оператори цієї послуги не мають можливості прочитати вміст повідомлення. Зазвичай хтось використовує цю послугу, коли не хоче, щоб вміст повідомлення залишався всередині різних баз даних / пристроїв / служб / файлів / тощо. як це характерно під час надсилання електронного листа / миттєвого повідомлення / тексту / тощо. Якщо ви вирішите розшифрувати, майте на увазі наступне:
- Цілком ймовірно, що повідомлення буде видалено відразу після того, як воно буде надіслане на пристрій для розшифровки. Це означає, що після того, як ви натиснете кнопку, щоб розшифрувати повідомлення, у нас більше не буде копії, щоб надіслати вас знову пізніше.
- Ми систематично видаляємо всю отриману інформацію. Повідомлення будуть видалятися десь від однієї хвилини до двох тижнів після його створення - незалежно від того, чи повідомлення коли-небудь розшифровувалось. Іншими словами, якщо вам потрібно прочитати повідомлення, не чекайте занадто довго, щоб його розшифрувати.
- Відправник, ймовірно, вважає, що зі змістом повідомлення слід поводитися обережно. Можливо, вони навіть вказали, що не хочуть робити копії. Будь ласка, поважайте їх побажання.
- Якщо вам буде запропоновано ввести пароль для розшифровки повідомлення, не закривайте вікно / вкладку браузера. За першим пунктом у цьому списку, швидше за все, ми не зможемо надіслати іншу копію пізніше. Просто залиште вікно / вкладку браузера відкритими, поки не зможете ввести пароль. Якщо ви введете неправильний пароль, вам буде запропоновано знову. Пароль потрібно вводити точно. Майте на увазі, що для того, щоб врахувати різні мови та вимоги до паролів, ми приймаємо багато різних символів у паролях.
Ви видаляєте все, що надійшло на цей сайт?
Вірний логотипу нашого кошика ... все видаляється незабаром після його отримання. Видалення всього відбувається автоматично - це записується на сервер. Подумайте про це так - існує два класи поданої інформації:
- Зашифровані повідомлення, для яких у нас немає засобів для дешифрування вмісту
- Інша інформація, властива надсиланню будь-чого в Інтернеті (тобто Ваша IP-адреса тощо)
- Як довго ми повинні зберігати повідомлення, якщо його ніхто не отримує (від 1 хвилини до 2 тижнів - за замовчуванням до 1 тижня).
- Скільки разів отримується повідомлення (від 1 до 100 разів - за замовчуванням до 1 разу)
Навіщо користуватися цією послугою?
Ця послуга - це інструмент, який допомагає зробити повідомлення, які ви надсилаєте / отримуєте, менш постійними. Більша частина того, що ви спілкуєтесь в Інтернеті (чати, тексти, електронні листи тощо), зберігається і рідко видаляється. Часто, коли ви щось видаляєте, воно насправді не видаляється, а позначається як видалене і більше не відображається вам. Ваші сукупні зв’язки накопичуються рік у рік у базах даних та на пристроях, якими ви не контролюєте. Неминуче одна або кілька організацій / людей / пристроїв, що зберігають ваші зв’язки, піддаються злому, а ваша інформація витікає. Ця проблема настільки поширена, що зараз існує багато веб-сайтів, які відстежують організації, які були скомпрометовані та просочили дані користувачів. Наскрізні зашифровані тимчасові повідомлення - це просте рішення, яке допоможе зробити деякі з ваших комунікацій менш постійними. Кожне повідомлення, надіслане на цей сайт, має час життя від 1 хвилини до 2 тижнів - після закінчення цього часу повідомлення видаляється. Крім того, типовим налаштуванням є видалення будь-якого повідомлення після того, як одержувач його отримає. Крім того, усі повідомлення шифруються від вашого пристрою аж до пристрою одержувача. Основною метою використання наскрізного шифрування є вилучення нашої можливості читати будь-які надіслані повідомлення, тим самим усуваючи деякі вимоги довіри. Кінцевим результатом є те, що тепер легко відправити зашифроване повідомлення за простим посиланням. Це повідомлення видаляється незабаром після надсилання або після отримання. Вам не потрібно встановлювати / налаштовувати спеціальне програмне забезпечення. Вам не потрібно створювати обліковий запис або надавати будь-яку особисту інформацію. Одержувач не повинен бути у ваших контактах або навіть знати про цю послугу - єдина вимога, щоб вони могли натиснути посилання.
Це послуга обміну повідомленнями?
Ні. Ця послуга призначена для доповнення існуючих служб обміну повідомленнями, таких як обмін миттєвими повідомленнями / електронна пошта / текст / тощо. додавши можливість запобігти тривалому збереженню відправлених повідомлень. Ми не доставляємо сформоване посилання одержувачу .
Які випадки використання призначені?
Тож якими сценаріями доцільно користуватися цією послугою? Хоча у кожного різні потреби та вимоги щодо їхньої конфіденційності та безпеки, я особисто знайшов наступні сценарії як відповідні випадки використання:
- Ви спілкувались на місцевому веб-форумі про маршрути для гірських велосипедів у цьому районі, а іноді зустрічаєтесь із людьми на форумі, щоб разом перевірити нові стежки. Хтось із форуму хоче забрати вас до вас, щоб проїхати автотранспортом на ці вихідні. Ви не хочете, щоб ваша домашня адреса постійно сиділа у базі даних форуму веб-сайту. Просто надішліть адресу за допомогою цієї служби - посилання є тим, що знаходиться в базі даних форуму веб-сайту, але після прочитання одержувачем повідомлення / адреса видаляється.
- Вам потрібно надіслати братові свій логін на Netflix, тому що ваша племінниця зводить його з розуму через блокування COVID, і він все ще не має власного рахунку. Ви не надто піклуєтесь про цей логін, але ваш брат особливо погано сприймає те, що я просто називатиму "цифровою гігієною", і він мав багато випробувань із порушеними логінами та шкідливим програмним забезпеченням. Подальші спроби змусити його очистити свій вчинок і навіть встановлення безпечного обміну повідомленнями для нього не втрималися. Просто надіслати його за допомогою текстового повідомлення - це, мабуть, найкращий варіант (на жаль), але вам незручно, коли цей логін сидить у його історії повідомлень через минулий досвід. Використання цієї послуги для надсилання входу за посиланням у текстовому повідомленні задовольняє не дозволяючи логіну назавжди зависати в його історії чату.
- Ви іноді працюєте в офісі, де є багато спільних орендарів, які приходять і їдуть у будь-який час. Wi-Fi доступний для використання, але пароль обертається щотижня, оскільки виникають проблеми із зловживаннями. Багато орендарів електронною поштою / текстом запитують пароль Wi-Fi, навіть якщо він стоїть на стійці реєстрації, оскільки більшість не входить через головний вхід. Використовуючи цю послугу, менеджер офісу може надіслати пароль WiFi за посиланням у відповіді на електронну пошту / текст, задовольняючи тим, що пароль не затримується, а також дозволяє одержувачу негайно скопіювати пароль за допомогою кнопки копіювання, яка менш незграбна на мобільних пристроях.
- Один із ваших хостинг-провайдерів запитує у вас подробиці про сервер, про який ви повідомили, що має ознаки жорсткого диска, який, здається, псується. Деяка інформація, яка їм потрібна, є делікатною - ви не хочете, щоб вона вічно сиділа в системі квитків третьої сторони, яку вони використовують. Використовуючи цю послугу, ви можете надіслати інформацію технічним спеціалістам, не перебуваючи в системі квитків. Оскільки багатьом технічним спеціалістам може знадобитися посилатися на інформацію кілька разів, встановіть показники читання для перевищення більше 1 (тобто, можливо, 20), щоб повідомлення не видалялося при першому пошуку.
- Вам потрібно надіслати приватне повідомлення іншому користувачеві Reddit, щоб повідомити йому ваш номер телефону, щоб він міг вам зателефонувати. Reddit, як і багато інших провайдерів, раніше просочував інформацію про користувачів, і ви не хочете, щоб ваш номер телефону просто сидів у базі даних Reddit роками до наступного витоку. Просто надішліть свій номер телефону за допомогою цієї послуги.
- Ваш чоловік / дружина повідомляє вам, коли ви на роботі, бажаючи ввійти в систему, оскільки її подруга щойно спробувала нову програму, яка заощадила її гроші на рахунку за електроенергію, і вона хоче перевірити це. Існує спільний сімейний менеджер паролів, про який ви нагадуєте їй, але вона просто хоче, щоб ви надіслали логін. OMEMO використовується для обміну миттєвими повідомленнями з вашим чоловіком / дружиною, і тому ви впевнені, що перевезення повідомлень безпечно; однак сама історія чату зберігається незашифрованою. Ваш чоловік не завжди обережно ставиться до завантажень, електронних листів тощо, а оплата комунальних послуг є делікатною, оскільки їх можна використовувати для крадіжки особистих даних для підтвердження місця проживання. Ви можете надіслати їй дані для входу за допомогою цієї служби, щоб уникнути збереження копії на її комп’ютері.
Для чого не слід використовувати цю послугу?
Ця послуга не повинна використовуватися для дуже конфіденційної інформації з усіх причин, пояснених у цьому FAQ. Нижче наведено кілька прикладів того, чого не можна робити:
- Не використовуйте цю послугу, щоб зробити невідповідну передачу повідомлень "більш безпечною". Оскільки за замовчуванням параметр включає пароль в URL-адресу, яка може читати повідомлення, будь-хто, хто має посилання, може прочитати повідомлення. Як зазначалося вище, будь-які проблеми безпеки / конфіденційності, властиві вибраному транспорту (тобто тексту), успадковуються під час використання цього інструменту. Так, наприклад, якщо ви ніколи не розглядали можливість використання електронної пошти для надсилання конкретної інформації через її чутливий характер, тоді ви не повинні використовувати цю послугу для "захисту" цієї частини електронного листа.
- Не використовуйте цю послугу, щоб переконатися, що повідомлення не зроблено. Те, що ми видаляємо свою копію зашифрованого повідомлення відразу після отримання, і ми ускладнюємо копіювання, не означає, що повідомлення не можна скопіювати. Що робити, якщо одержувач сфотографує свій екран? Що робити, якщо вони просто записують повідомлення? Зрештою, якщо одержувач може прочитати повідомлення - можна зробити копію.
- Не використовуйте цю послугу, щоб переконатись, що повідомлення неможливо простежити до вас. Ця послуга залежить від іншого постачальника передачі повідомлень (тобто електронної пошти, чату тощо), щоб отримувати повідомлення від однієї точки до іншої. Використовуваний транспорт передачі повідомлень цілком може простежити повідомлення назад до вас.
- Не використовуйте цю послугу для надсилання будь-чого, що ви хочете відмовити у надсиланні. Те, що саме повідомлення видалено, не означає, що посилання, що вказує на видалене повідомлення, видалено. Якщо ви надсилаєте електронний лист своєму другові, і частина цього електронного листа містить посилання на повідомлення від цієї служби, випадковий читач дізнається, що в повідомленні є щось інше. Навіть якщо повідомлення, на яке посилається посилання, вже давно зникло - очевидно, що було надіслано щось інше і що воно було надіслане вами вашому другу.
Чому б просто не використовувати PGP / Signal / OMEMO / Matrix / тощо?
Якщо ви знаєте людину, якій хочете надіслати захищені тимчасові повідомлення, часто надсилаєте їх, очікуєте інтерфейсу, схожого на чат, та / або можете розраховувати, що одержувач має необхідне програмне забезпечення та знає, як ним користуватися, цей веб-сайт, мабуть, не є найкраще рішення. Є чудові варіанти, які мають відкритий код, підтримують E2EE, а не Інтернет, і навіть такі, як Signal, які також підтримують тимчасові повідомлення. Я особисто використовую приватний сервер XMMP та OMEMO для спілкування з близькими друзями та родиною. Використання цього веб-сайту може бути оптимальним лише в тому випадку, якщо ви не знаєте, яке програмне забезпечення працює одержувач, не знаєте його телефонний номер / контакт-дескриптор, не знаєте їх технічної кваліфікації (але припустимо, що вони можуть натиснути посилання), або ви просто вважаєте за краще зберігати повідомлення, яке ви відправляєте, за межі основного транспортного зв'язку.
Які вимоги існують?
Потрібен сучасний та сучасний веб-браузер, який належним чином реалізує стандарти, включаючи API Web Crypto. Приклади включають: 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 все одно може бути ефективною (тобто для визначення IP-адреси відправника, якщо не використовує TOR / VPN / тощо).
Як я можу точно знати, що що-небудь подане зашифроване наскрізне?
На відміну від багатьох інших популярних наскрізних зашифрованих (E2EE) клієнтів чату, досить просто побачити, що саме надсилається нам, коли ви надсилаєте повідомлення. Наведений нижче відеоурок демонструє, як підтвердити, що у нас немає можливості розшифрувати повідомлення, надіслані на сервер.
Крім того, якщо ви задумаєтесь, поки ми не якесь секретне агентство, яке намагається збирати конфіденційні повідомлення, нам не буде корисно розшифрувати повідомлення, оскільки наявність цієї можливості лише створює нам проблеми. Ми навіть не хочемо зберігати повідомлення - однак необхідне зло їх доставляти.Як працює наскрізне шифрування на цьому веб-сайті?
На даний момент ми використовуємо симетричне шифрування (AES-GCM 256 біт) з ключами, отриманими від паролів (мінімум 150 000 ітерацій PBKDF2 / SHA-256). Асиметричне шифрування не застосовується, оскільки існують вимоги до 1) відправника, який ініціює спілкування 2) відправника та одержувача, що не перебуває одночасно в Інтернеті та 3) немає інформації про одержувача та 4) ми намагаємось зробити все реально простим, а управління ключами є складний. Стандартний API веб-крипто використовується для всіх криптографічних функцій, включаючи RNG. В основному, ось що відбувається:
- Кінцевий користувач вибирає пароль або він створюється автоматично
- Здійснюється виклик API для отримання кількості необхідних ітерацій PBKDF2 / SHA-256 ( цей крок необхідний для контролю спаму )
- Генерується 32-байтова сіль
- Ключ походить від солі та пароля
- Генерується 12-байтовий вектор ініціалізації (IV)
- Повідомлення зашифровано за допомогою клавіші + IV
- Кількість ітерацій, сіль, IV і зашифрований текст надсилаються на сервер (разом з деякою іншою інформацією, такою як TTL, RTL тощо).
- Сервер повертає випадковий ідентифікатор, що посилається на повідомлення
- Потім браузер представляє кінцевому користувачеві посилання, яке містить повернені ідентифікатор та пароль або посилання без пароля (у такому випадку одержувач повинен знати та ввести пароль)
- Якщо пароль є частиною посилання, він знаходиться в хеші URL-адреси , і тому ніколи не надсилається на сервер, коли одержувач робить запит GET
- Одержувач отримує запит, якщо він хоче розшифрувати та переглянути повідомлення
- Браузер робить запит із зазначенням ідентифікатора повідомлення
- Якщо відправник вимагає заповнення CAPTCHA, одержувач направляється на іншу URL-адресу, щоб довести, що вони люди (як тільки вони пройдуть, вони будуть спрямовані назад)
- Сервер надсилає зашифроване повідомлення і за замовчуванням видалить повідомлення в цей момент, якщо режим читання в реальному часі (RTL) є одним
- Одержувач розшифрує повідомлення за допомогою пароля (і буде запропоновано ввести пароль, якщо його немає в URL-адресі)
Пароль для розшифровки може бути в URL-адресі?
Так. Це, очевидно, впливає на безпеку, оскільки якщо метод, що використовується для надсилання посилання, є небезпечним, повідомлення є небезпечним через асоціацію. Усі способи усунення цієї проблеми передбачають додаткові кроки та складності, що впливають на взаємодію з користувачем (тобто речі слід налаштувати на обох кінцях перед надсиланням повідомлення). Асиметрична схема, згідно з якою одержувач ініціює запит на повідомлення та надсилає це посилання на запит, може працювати з нашою ключовою вимогою "все є швидкоплинним" - це може бути реалізовано. Зрештою, якщо дві сторони збираються часто відправляти повідомлення одна одній, існують кращі рішення, якщо обидві сторони можуть впоратись із використанням цих рішень.
Але пароль для розшифровки не обов’язково повинен бути в URL -адресі?
Правильно. Якщо пароль для дешифрування не міститься у посиланні, одержувачу буде запропоновано ввести пароль. Якщо пароль надійно повідомлений одержувачу (або вони його вже знають), це забезпечує захист від перехоплення. Однак недоліком є те, що одержувач повинен знати і правильно вводити пароль. Ось один із способів надіслати пароль одержувачу, який пропонує певний захист від перехоплення:
- Зашифруйте пароль у повідомленні з налаштуваннями за замовчуванням і надішліть це посилання одержувачу.
- Коли одержувач натискає посилання та розшифровує повідомлення, він знає, що ніхто інший не отримав до нього пароль, оскільки повідомлення, що містить пароль, видаляється після отримання. Однак, якщо є активна атака MITM або якщо ваш пристрій або пристрій одержувача були скомпрометовані, то все ще можливо, що інша сторона може отримати пароль.
- Підтвердьте одержувача, що він успішно отримав пароль. Наприклад, якщо одержувач повідомляє вам, що коли він збирався отримати пароль, що повідомлення вже видалено, то ви знаєте, що хтось інший отримав пароль до одержувача, і тому пароль зламаний і його не слід використовувати.
- Використовуючи пароль, який одержувач підтвердив, що він володіє, тепер ви можете надіслати повідомлення, використовуючи той самий пароль для шифрування - просто поділіться версією посилання, яка не містить пароля.
Ця послуга не доставляє посилання одержувачу?
Це правильно - ми генеруємо посилання та залишаємо відправнику, як найкраще доставити його одержувачу. Мета цього сервісу - запропонувати опцію, що пропонує менше постійності в існуючих транспортних повідомленнях, таких як електронна пошта / чат / текст / тощо. Отже, очікується, що посилання, яке ми генеруємо, яке вказує на тимчасове повідомлення, надсилається за допомогою існуючого транспорту повідомлень. Це має наслідки для безпеки, які користувачі повинні розуміти. Візьмемо для прикладу текстове повідомлення SMS, оскільки це досить небезпечний спосіб спілкування. Якщо ви використовуєте цю послугу для надсилання тимчасового посилання на повідомлення за допомогою текстового повідомлення, якщо ви використовуєте режим за замовчуванням, згідно з яким пароль входить у посилання, кожен, хто має посилання, може прочитати повідомлення, і захист від перехоплення не пропонується. Ця послуга все ще забезпечує більш тимчасове спілкування, яке може підвищити конфіденційність та безпеку. Крім того, ви можете надіслати посилання без пароля, і це забезпечить захист від перехоплення.
Як я можу максимально захистити свою конфіденційність під час використання цієї послуги?
Як обговорювалося в інших розділах цього Поширеного запитання, хоча ми вже багато робимо для захисту вашої конфіденційності, і хоча ми не збираємо жодну особисту інформацію, деяка інформація, пов’язана з журналом , надсилається та збирається нами та іншими за допомогою вас за допомогою веб-браузера. Однак існує кілька способів ще більше захистити вашу конфіденційність. Один із способів, яким можна користуватися безкоштовно на основі програмного забезпечення з відкритим кодом і який працює досить добре, - використовувати браузер Tor . Цей браузер призначений для захисту вашої конфіденційності на декількох рівнях, включаючи використання мережі Tor . Наш сайт вже доступний через цибульну мережу Tor, що означає, що для доступу до нашого сайту через Tor не потрібно використовувати вузол виходу, що заважає комусь підслуховувати трафік вузла виходу . Однак майте на увазі, що навіть за цього сценарію ваш провайдер бачить, що ви використовуєте Tor, хоча не для чого. Ви навіть можете підключитися до VPN, а потім запустити браузер Tor для двох шарів анонімності; однак, майте на увазі, що ваш провайдер все ще може бачити, що ви використовуєте VPN у цьому сценарії - хоча не для чого. Якщо ви не хочете, щоб ваш провайдер знав, які протоколи ви використовуєте, ви можете підключитися до великої загальнодоступної мережі WiFi, наприклад, бібліотеки, школи тощо, а потім скористатися браузером Tor.
Що робити, якщо я не довіряю США?
Наші сервери знаходяться в США. Крім того, наш постачальник CDN, Cloudflare, є компанією, що базується в США. Ми спробували усунути необхідність довіряти нам або країні, в якій проживають наші сервери, просто тому, що ми не збираємо особисту інформацію, не можемо розшифрувати жодні повідомлення, і все видаляється незабаром після її отримання. Однак ми можемо зрозуміти певну недовіру, оскільки вона заснована на Інтернеті, особливо якщо ви живете в певних країнах. Ми плануємо запропонувати варіанти в Ісландії та Швейцарії людям, яким важко довіряти США. Будь ласка, повідомте нам, якщо це стосується вас, оскільки ми не будемо спонукані пропонувати альтернативні варіанти, якщо не буде реального попиту.
Що ви робите для запобігання спаму?
Щоразу, коли ви дозволяєте комусь розміщувати повідомлення, яке може передаватися за посиланням, ви запрошуєте спамерів. Приборкати цю проблему не зовсім просто. Ми не хочемо завантажувати сторонні CAPTCHA як частину процесу надсилання повідомлень з кількох причин:
- Ми ненавидимо капчу - вони вимагають часу і дратують
- Завантаження стороннього javascript може порушити конфіденційність та безпеку
- Запуск нашого власного CAPTCHA означає, що ми підписуємося на нескінченну гру в халепу
- Врешті-решт люди можуть захотіти мати можливість взаємодіяти з цією службою через API
- Збільшення кількості необхідних ітерацій PBKDF2 / SHA-256
Усі повідомлення можна отримати лише невелику кількість разів - непривабливий атрибут для спамерів, оскільки вони покладаються на надсилання великої кількості повідомлень. Оскільки спамеру доведеться створювати багато повідомлень для будь-якої спам-кампанії - ми вирішили зробити це завдання настільки обчислювально дорогим, щоб зробити зловживання цією службою щодо спаму непривабливою справою. Це досягається шляхом відстеження мереж, що розміщують повідомлення - вимірюється як загальна кількість можливих пошуків. Сама інформація про мережу надійно хешована, так що ми не можемо зробити висновок про реальну мережу з хешу. Оскільки дана мережа публікує більше повідомлень, ми збільшуємо кількість ітерацій PBKDF2 / SHA-256, необхідних для розміщення наступного повідомлення. Це дуже швидко призводить до того, що для того, щоб опублікувати одне повідомлення, потрібно багато часу процесора. Сподіваємось, цей метод буде достатнім для запобігання зловживанню спамом і водночас не впливатиме на реальних користувачів. - Збирайте звіти про спам від користувачів, коли вони отримують повідомлення
Коли користувач отримує повідомлення, прямо під повідомленням є кнопка "Повідомити про спам". Якщо повідомлення є спамом, сподіваємось, для натискання цієї кнопки деяким знадобиться 3 секунди. Коли ми отримуємо звіт про спам, він попереджає нас, а також впливає на необхідні ітерації PBKDF2 / SHA-256 для даної мережі.
Чому існує можливість вимагати від одержувача заповнення CAPTCHA?
Хоча це правда, що ми не любимо капчу, ми усвідомлюємо, що вони слугують певній цілі та мають час і місце (принаймні зараз). Це простий спосіб відправника отримати певне запевнення в тому, що одержувач є людиною і що автоматизовані процеси не отримують доступ до повідомлення.
Хто використовує цю послугу і чому вона безкоштовна?
Ми всього лише пара хлопців, котрі часом стикалися із скрутним становищем, оскільки у нас немає хороших варіантів для захисту нашої приватності. Часто це було наслідком спілкування з друзями та членами сім'ї, які не дуже обережно ставилися до своїх пристроїв та інформації. В інших випадках це виникало при використанні веб-форумів, таких як Reddit, або при використанні веб-систем підтримки. Ми знайшли кілька тимчасових рішень для тимчасових повідомлень, але жодне не пропонувало E2EE, що означало, що ми не могли їм довіряти. Тож ми просто створили своє власне рішення і вирішили його подарувати, щоб інші могли отримати від нього користь.
Як я можу довіряти відповідям на вищезазначені питання?
Дійсно, вам не слід довіряти будь-якому веб-сайту лише тому, що він пише певні речі - зазвичай це гарна ідея перевірити будь-які претензії. Ми спробували зняти вимогу довіряти нам якомога більше, використовуючи наскрізне шифрування. Наприклад, досить легко перевірити, що ми не можемо прочитати жодні повідомлення, оскільки вони зашифровані . Ми також зробили дуже простим код JavaScript на цьому веб-сайті, щоб його було легко прочитати та зрозуміти. Зробити весь код відкритим, можна людям перевірити, що працює; Однак майте на увазі, що немає можливості по-справжньому перевірити, що працює на сервері. Хоча це правда, що більша частина вимог довіри скасовується за допомогою наскрізного шифрування, це все одно є фактором, який наші користувачі значно зважують, приймаючи рішення про використання цієї послуги чи ні.