Internet Engineering Task Force (IETF) se dlouhodobě snaží o bezpečný a důvěryhodný internet. Nejnovějším příspěvkem na tomto poli je nový standard zavádějící bezpečnější přístup k elektronické poště. Přestože máme rok 2018, stále je v této oblasti co dohánět, protože velká část pošty putuje internetem v otevřené podobě nebo s velmi slabým zabezpečením.
Výsledkem je RFC 8314, ve kterém Chris Newman z Oracle a Keith Moore z Windrock vysvětlují, že v některých případech není komunikace mezi klientem a serverem šifrovaná. Zároveň dokument novelizuje celou řadu předchozích standardů a zavádí přísnější přístup s cílem zajistit uživatelům výrazně vyšší bezpečnost.
Oportunistické šifrování nestačí
Dokument identifikuje hlavní nedostatky v komunikaci mezi e-mailovým klientem (MUA) a servery. Ty mohou být přitom dvojího druhu – pro odesílání pošty (Submission) a příjem pošty (Access). Používají různé protokoly jako Internet Message Access Protocol (IMAP) (RFC3501), Post Office Protocol (POP) (RFC1939) a Simple Mail Transfer Protocol (SMTP) Submission (RFC6409).
Obvykle se při jejich použití používá zabezpečení pomocí Transport Layer Security (TLS) (RFC5246), ale často to není prováděno tím nejlepším způsobem vzhledem k utajení e-mailové komunikaci při přenosu internetem.
Typickým příkladem je takzvané oportunistické (česky příležitostné) šifrování. Předchozí standardy (RFC 2595, 3207 a 3501) totiž doporučovaly používat právě tento způsob. Klient se k serveru připojí běžným otevřeným protokolem bez šifrování a teprve v průběhu komunikace může navrhnout přechod na šifrovanou komunikaci pomocí příkazu STARTTLS.
Konkrétní podoba šifrovaného kanálu pak závisí na dohodnutých schopnostech obou stran. Jinými slovy: pokud o to klient výslovně požádá, může být zahájeno vyjednávání o sestavení nového šifrovaného kanálu pro bezpečnější komunikaci. K němu ovšem vůbec nemusí dojít, pokud se protistrany nedohodnou, přenese se pošta v klidu nešifrovaně. Navíc začátek celé komunikace vždy probíhá v otevřeném prostředí a může tak být odposloucháván nebo manipulován.
Řešení existuje, je jím implicitní šifrování, tedy použití odděleného TCP portu, na kterém se nejprve vždy povinně naváže TLS spojení a teprve v něm probíhá komunikace s poštovním serverem. Čerstvě vydané RFC tedy pro protokoly POP, IMAP, SMTP a další příbuzné doporučuje právě použití této bezpečnější metody.
Klient musí ověřovat certifikáty
Nový dokument zavádí povinnou validaci certifikátů na straně klienta, který se tak musí při navazování spojení řídit RFC 7817. V případě POP3S a IMAPS s tím není problém, protože implicitní TLS je dnes na serverech už velmi rozšířené. Jinak je to ale v případě SMTP, kde je stále ještě častým zvykem používat oportunistické šifrování se STARTTLS. Aby byl přechod pro uživatele pokud možno hladký, měly by servery po přechodné období implementovat jak STARTTLS na portu 587, tak bezpečnější implicitní TLS na portu 465.
TCP port 465 původně vznikl pro TLS variantu SMTP, ale poté se ukázalo, že není možné nijak pomocí MX záznamu signalizovat šifrování (a tedy ani použití jiného portu). Proto se stále pro komunikaci mezi servery používá původní port 25 a vyhrazení nového portu 465 bylo zrušeno. Řada uživatelů ale už mezi tím začala nový port používat pro doručení pošty ze svého klienta s implicitním TLS. Tento postup se nyní formalizuje zavedením nové služby Submissions.
Port 25 není určen pro klienty
Stále rozšířené je použití TCP portu 25 také pro doručení pošty na odesílající server (SMTP Submission), pro které jsou ovšem vyhrazeny už zmíněné porty 587 a 465. Tvůrci nového RFC proto říkají, že by poskytovatelé služeb měli své uživatele co nejdříve přesunout na bezpečnější varianty – ať už oportunistické nebo implicitní. To navíc bez ohledu na to, zda se uživatelé při použití dané služby musejí autentizovat.
Port 25 by tak měl být vyhrazen pro komunikaci mezi servery a klienti by přes něj neměli vůbec poštu na svůj odesílací server předávat. Bohužel je historicky na použití tohoto portu řada uživatelů zvyklá, takže i někteří poskytovatelé poštovních služeb nabízejí přijetí pošty přes tento port. Zároveň ale poskytovatelé připojení často použití portu 25 blokují kvůli boji s odchozím spamem, takže jsou uživatelé chtě něchtě tlačeni do použití správných rozhraní.
Změny na obou stranách
Výše uvedené změny se týkají e-mailových klientů (Thunderbird, Outlook, Apple Mail a dalších), ale také serverů. Ty podle RFC musí implementovat TLS na zmíněných komunikačních protokolech a měly by tak učinit i na jakýchkoliv dalších. Povinně musí TLS umožnit na těch protokolech, kde se uživatel přihlašuje pomocí jména a hesla.
Poskytovatelé poštovních služeb by co nejdříve měli ukončit podporu nešifrovaných protokolů, čemuž by měla předcházet postupná migrace uživatelů na šifrované kanály. Za bezpečné se při tom považuje TLS verze 1.1 a vyšší. Server by měl buďto spojení se starší verzí úplně odmítnout nebo přijmout, ale poté zamítnout přihlášení uživatele. Druhá varianta umožňuje navázat komunikaci a poté předat zprávu o důvodu selhání, přináší ale riziko vyzrazení přihlašovacích údajů uživatele. Po nových uživatelích by tak mělo být od začátku požadováno použití TLS alespoň verze 1.1.
RFC 8314 zavádí řadu nových MUST a SHOULD pro obě strany komunikace: klienta i server. Cílem je opustit zastaralé oportunistické šifrování a přinést i do přenosu elektronické pošty podobné standardy, na jaké jsme zvyklí například u HTTPS. Bohužel svět webu a svět elektronické pošty dělí dvě dekády (alespoň po formalizační stránce) a starší protokoly se novým trendům obecně přizpůsobují pomaleji.
ČLÁNKY DO MAILU