Ваша. Розумна. Пошта.
Швидкий, кросплатформний поштовий клієнт, створений фільтрувати зайвий шум, щоб ви могли зосередитися на тому, що справді важливо.
💡Шифрування електронної пошти: процес, який перетворює ваше повідомлення на нечитабельний код, щоб лише передбачений одержувач (чи його пристрій) міг знову перетворити його на слова. Більшість вашої електронної пошти непомітно шифрується тієї ж миті, коли ви натискаєте «Надіслати». Чи залишиться вона такою протягом усього шляху — це вже інше питання. Майже вся електронна пошта шифрується під час передавання за замовчуванням (це TLS, і це відбувається автоматично). Справжнє наскрізне шифрування, коли ніхто, окрім вас та одержувача, ніколи не зможе прочитати повідомлення, — це окремий, необов'язковий рівень, який ви маєте увімкнути самостійно.
Більшість людей вважає, що «моя електронна пошта зашифрована» означає, що ніхто, крім одержувача, не може її прочитати. Зазвичай це не зовсім так.
Сучасна електронна пошта зазвичай передається через TLS (transport layer security) — ту саму технологію, що стоїть за замочком в адресному рядку вашого браузера. Вона шифрує з'єднання між поштовими серверами, крок за кроком. Gmail спілкується з Outlook, Outlook — із сервером вашої компанії, і так далі. Кожен крок заблоковано. Але на кожному сервері вздовж шляху саме повідомлення лежить розшифрованим, доступним для читання будь-кому, хто керує цим сервером. Це шифрування під час передавання, і сьогодні воно автоматичне практично у кожного великого провайдера.
Наскрізне шифрування — це щось інше, і суворіше. Ключі є лише у вас та вашого одержувача. Не у вашого поштового провайдера, не у їхнього поштового провайдера, ні в кого посередині. Стаття глосарія Spark про наскрізне шифрування детальніше розкриває саме цей механізм. Для більшості повсякденної електронної пошти (домовитися про обід, переслати мем) TLS цілком достатньо. А для підписаного контракту, медичної картки чи банківських даних клієнта? Ось тоді вам справді важливо розуміти різницю між цими двома речами.
Поштові клієнти зазвичай підключаються до вашого провайдера через TLS автоматично, без потреби у налаштуванні з вашого боку.
Є три, які варто знати.
TLS (під час передавання) — це стандарт: непомітний, автоматичний, не потребує жодних дій. Він не дає нікому прочитати вашу пошту, поки вона рухається через інтернет. Він не заважає самому поштовому серверу — чи будь-кому, хто зламає цей сервер — прочитати повідомлення, щойно воно надійде. Хороша основа. Але не куленепробивна.
S/MIME використовує сертифікат, прив'язаний до вашої особи, для шифрування та цифрового підписування повідомлень наскрізно. Поширений в корпоративному та державному середовищі, де ІТ-відділ видає вам сертифікат. Outlook підтримує його нативно. Безкоштовний особистий Gmail — ні. S/MIME у Gmail доступний лише через платні плани Google Workspace, налаштовується адміністратором, а не є чимось, що ви вмикаєте самостійно.
PGP (Pretty Good Privacy) покладається на пару публічного та приватного ключів, яку ви генеруєте та керуєте самостійно. Жодного центру сертифікації, жодної компанії, що щось видає — лише ви тримаєте ключі. Потужно, по-справжньому приватно. Але водночас найбільш ручний із трьох, що якраз і є причиною, чому він так і не став масовим за межами кіл, зосереджених на приватності, та технічних кіл.
Зрозумійте, що насправді означає «зашифровано», перш ніж довіряти цьому. Конфіденційний режим — це не шифрування. Це посилання з терміном дії, яке можна відкликати.
У будь-якому разі увімкніть двофакторну автентифікацію. Шифрування захищає повідомлення під час передавання. Воно не робить нічого, якщо хтось просто ввійде безпосередньо у ваш обліковий запис.
Використовуйте S/MIME або PGP для всього по-справжньому конфіденційного: контрактів, медичних даних, фінансових записів. Для списку покупок достатньо самого лише TLS.
Захищайте вкладення паролем, коли повне шифрування недоступне. Заблокований PDF, надісланий разом із паролем через окремий канал (повідомлення, дзвінок), охоплює напрочуд багато випадків.
Уточніть в ІТ-відділі вашого одержувача, перш ніж вважати, що S/MIME просто працюватиме. Сертифікати з обох боків мають узгоджуватися, інакше повідомлення не розшифрується коректно.