Однак, наскільки мені відомо, що стосується зв’язку поштовий сервер-пошта-сервер, більшість електронних листів все ще передаються у простому тексті та не шифруються, завдяки чому хтось із мережі може прочитати їхній вміст.
Правильно. SMTP, як і HTTP, є типовим текстом за замовчуванням.
У наші дні багато поштових серверів підтримують TLS (раніше відомий як SSL) для SMTP. (Сюди входить Gmail.) Однак у нього є ті ж самі проблеми, що й у HTTP [S]: сертифікати, видані відомими ЦА, коштують грошей, а самопідписані - нічим не потрібні 1 для захисту від атак MitM . Якщо ваш поштовий сервер здійснює сувору перевірку сертифікату одержувача (як це роблять веб-браузери), він може не доставити повідомлення серверам, які використовують сертифікати, що підписуються самостійно, або внутрішні офісні організації. Якщо цього немає , то він не може бути впевнений, що він розмовляє з правильним сервером, а не з самозванцем .
Крім того, TLS є відносно недавнім доповненням до SMTP, тому навіть коли поштовий сервер одержувача підтримує TLS, відправник може не бути або він може бути відключений за замовчуванням.
1 (Якщо сервер, що відправляє, підтримує DANE (TLSA), і адміністратор приймаючого сервера піклується про публікацію записів TLSA в DNS. Це рідко робиться і дещо стомлює.)
Чи є якісь технології, які дають користувачеві певні гарантії, що його електронні листи надійно надсилаються від кінця до кінця?
Два найпоширеніші стандарти безпеки електронної пошти:
OpenPGP , заснований на веб-довірі та вільний у користуванні. Реалізація з відкритим кодом - це GnuPG ( для Windows , для Thunderbird ), а оригінальний PGP перетворився на комерційний PGP Desktop .
Для веб-клієнтів електронної пошти, FireGPG можливість - забирай
S / MIME , заснований на інфраструктурі X.509 Реалізовано більшістю настільних клієнтів (включаючи Outlook, Thunderbird, Mail.app). Однак порівняно непопулярний завдяки тій же структурі, що базується на повноваженнях, як і TLS / SSL: підписані сертифікати коштують грошей, а самопідписані сертифікати не можуть бути достовірно підтверджені.
В обох випадках для шифрування потрібно, щоб одержувач вже використовував систему та створив / отримав ключ. (Для підписання використовується ключ відправника відправника . Звичайна практика - як підписувати, так і шифрувати повідомлення.)
Чому б не повідомити користувачеві про те, коли шифрування не підтримується, і не дати йому вибрати, чи хоче він все-таки доставляти свою електронну пошту?
Зазвичай надіслані повідомлення стоять у черзі , і ні користувач, ні MTA не можуть знати, чи підтримує наступний стрибок TLS чи ні - до того моменту, поки повідомлення не буде надіслане , і тоді немає надійного способу запитати у користувача підтвердження. (Це можуть бути AFK, офлайн, сплячі або сценарій / програма. Якщо я надіслав це повідомлення, я хочу, щоб воно було доставлене якнайшвидше.)
Крім того, за допомогою SMTP ви ніколи не знаєте, чи буде наступний перехід остаточним чи він просто перенаправить пошту десь в іншому місці. Не рідкість резервна копія MX перебувати у зовсім іншій мережі.
Тому. захист від кінця до кінця можливий лише тоді, коли обидві сторони використовують OpenPGP або S / MIME.