O projektu PRISM organizace NSA, který umožňuje přímý přístup k informacím a komunikaci lidí využívajících služby některých velkých poskytovatelů služeb, se toho psalo mnoho. Komu se to nelíbí, nemá jinou možnost než přestat využívat služby těchto poskytovatelů nebo nějakým způsobem obsah vyměňovaných zpráv a souborů šifrovat.
Tím se zde zabývat nechci. Chci se trochu více zaměřit na druhý typ odposlechů – zachytávání „surové“ datové komunikace na optických trasách zejména na hranicích států nebo na podmořských kabelech. Zde lze zachytávat cokoliv, třeba e-maily putující po internetu prostřednictvím SMTP protokolu.
Podle mého názoru většina e-mailové komunikace nepoužívá šifrovaný přenos dat (TLS), a tak e-maily putují otevřeně. To znamená, že teoreticky si obsah e-mailů může přečíst kdokoliv kdo má nějaký přístup k zařízením (routery, servery) nebo datovým trasám po cestě mezi odesílatelem a příjemcem. To se netýká jen SMTP protokolu, který slouží k předání zprávy od odesílatele na server a dále na další servery až do cíle, ale také POP3 a IMAP protokolů, kterými si příjemce vyzvedává zprávy ze serveru.
U protokolů POP3 a IMAP problém není tak velký – ty si konfigurují koncoví uživatelé u sebe v počítači, jsou si vědomi, že existují šifrované varianty, vyžadují je a snad každý poskytovatel e-mailových služeb POP3S a IMAPS podporuje. A když už je na takovém serveru povoleno toto šifrování, jistě je tam zapnutá i podpora šifrovaného SMTP, a tak uživatel může i odchozí e-mail předat serveru svého poskytovatele šifrovaně.
Jenže to řeší jen komunikaci mezi e-mailovým klientem na počítači koncového uživatele a e-mailovým serverem poskytovatele. Než odeslaný e-mail dorazí do cíle, musí obvykle absolvovat nejméně jeden další přenos pomocí SMTP protokolu mezi servery.
O šifrování HTTP komunikace povědomí asi všichni máme. Dáváme si pozor, zda osobní údaje a hesla vyplňujeme jen přes HTTPS, a asi většina z nás ví jak na potřebné certifikáty a klíče. Ale řešíte to samé u SMTP?
Šifrované SMTP, které zde budu prezentovat, není všelék na neodposlechnutelnou komunikaci. Zajišťuje jen šifrování na úrovni TCP/IP spojení mezi servery, které si zprávu předávají. Tedy zamezí pasivnímu odposlechu komunikace na routerech a datových trasách. Stále ale mohou mít ke zprávám přístup administrátoři SMTP serverů, přes které pošta jde nebo kde máte umístěny své schránky. Úplné utajení obsahu zprávy zajistíte jen end-to-end šifrováním (např. PGP), tedy k zašifrování dojde v e-mailovém programu odesílatele a k dešifrování až v e-mailovém programu příjemce. A nejlepší je samozřejmě kombinace obojího, protože pokud použijeme jen end-to-end šifrování, ale nikoliv TLS, stále může kdokoliv na cestě odposlechnout hlavičky SMTP (tedy metadata, která údajně NSA skladuje dlouho – na rozdíl od obsahu zpráv) a z těch lze také lecos zjistit a odvodit.
Stejně musíme myslet na to, že po internetu bude zpráva putovat šifrovaně od odesílatele až k příjemci jen v případě, že všechny servery na cestě TLS u SMTP podporují.
V tomto článku se tedy zaměříme jen na šifrování SMTP.
Šifrované SMTP
Pro šifrování SMTP komunikace existuje několik možností. Nejprve je potřeba rozlišit dvě situace:
- mail submission – e-mailový program (MUA – Mail User Agent) předává zprávu prvnímu e-mailovému serveru (MTA – Mail Transfer Agent), obvykle svého poskytovatele připojení nebo hostingových služeb
- mail transfer – jeden MTA předává zprávu dalšímu MTA (buď cílovému serveru nebo nějakému po cestě)
Nejdůležitější je TCP port 25. Ten je primárně určen pro předávání e-mailů mezi servery (mail transfer). Po navázání spojení není komunikace hned šifrována. Server po přijetí pozdravu EHLO sdělí klientovi, jaká rozšíření a parametry komunikace nabízí. Pokud server podporuje TLS, oznámí dostupnost příkazu STARTTLS. Pokud TLS podporuje také klient, zavolá příkaz STARTTLS a tím se klient i server přepnout do šifrovaného režimu. Pokud klient nebo server TLS nepodporují, dojde k výměně e-mailu nešifrovaně (pokud není chování na jedné nebo druhé straně explicitně určeno jinak). Toto je definováno v RFC 3207.
Historicky také existuje port 465 (SMTPS), kde je komunikace šifrována hned od počátku (podobně jako HTTPS). Je určen pro mail submission (MUA předává zprávu MTA). Používání portu 465 však není v souladu s RFC, přesto je u poskytovatelů e-mailových služeb rozšířen.
Pro mail submission oficiálně existuje port 587 dle RFC 6409. Stejně jako port 25 funguje v základu nešifrovaně, ale používá STARTTLS.
Moderní SMTP servery by měly používat porty 25 a 587 – to má umožnit oddělení příjmu e-mailů od jiných serverů a příjmu e-mailů od vlastních uživatelů (na těchto portech se pak aplikují různá zabezpečení a pravidla). V praxi se však často pro obojí používá jen port 25.
Mail transmission a TLS
Dále nás v tomto textu bude zajímat mail transmission na portu 25. E-mailový server vystupuje při SMTP komunikaci buď v roli serveru, tedy přijímá spojení od jiného MTA a přebírá e-mail k doručení dále, nebo vystupuje v roli SMTP klienta, tedy naváže spojení s cílovým MTA a odešle e-mail. Aby toto datové spojení bylo šifrované, musí být TLS podpora zapnuta na obou stranách.
V případě SMTP serveru je to trochu složitější. Znamená to nejen obecně zapnout podporu TLS, ale také mít a nastavit příslušný certifikát a soukromý klíč pro asymetrickou kryptografii. U serveru v rámci TLS komunikace také obvykle požadujeme autentizaci (kontrolu platnosti certifikátu a porovnání názvu hostitele s názvem certifikátu) – podobně jako si WWW prohlížeč kontroluje platnost certifikátu od webového serveru při použití HTTPS.
U SMTP klienta je nastavení jednodušší. Od něj obvykle nevyžadujeme autentizaci vůči serveru (pro mail transmission), ale pouze šifrování. Stačí tedy jen podporu TLS zapnout, není nutné řešit certifikáty a klíče (s výjimkou certifikátů nám důvěryhodných certifikačních autorit, pomocí kterých budeme kontrolovat certifikáty serverů). Jenže zde je velký problém – v softwaru pro provoz SMTP serverů je TLS ve výchozím stavu obvykle vypnuté.
Postfix a TLS
Na linuxových serverech je asi nejpoužívanějším softwarem Postfix. Ten má TLS pro SMTP klienta taktéž standardně vypnuté. Vysvětlení, proč tomu tak je, se zřejmě nachází již v první větě dokumentace k TLS u Postfixu:
By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on thousands and thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix. (zdroj)
Nedokážu říci, zda je OpenSSL opravdu tak nebezpečné. Dříve bývalo v OpenSSL mnoho chyb, ale v současné době už to tak hrozné nebude.
Máte-li tedy linuxový server a používáte-li jej pouze pro odeslání e-mailů (tedy nemáte na něm schránky, a tedy nezabývali jste se podporou šifrování pro POP3, IMAP a SMTP – typicky u webových serverů), s velkou pravděpodobností odchází vaše e-maily nešifrovaně. Ve výchozí konfiguraci je to vypnuté a většina administrátorů a tom vůbec neví.
Chceme-li zapnout podporu TLS v roli klienta (tedy pro odchozí e-maily), stačí do hlavního konfiguračního souboru main.cf uvést toto:
smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache smtp_tls_loglevel = 1 smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Položka smtp_tls_security_level zapne podporu TLS a říká, jaké zabezpečení podporujeme nebo vyžadujeme:
- may – Pokud server TLS podporuje (nabídne STARTTLS), použijeme jej. Pokud ne nebo navázání TLS spojení selže, tak jej nevyžadujeme a komunikujeme bez TLS.
- encrypt – Šifrování komunikace je vyžadováno. Pokud server TLS nepodporuje nebo se navázání šifrovaného spojení nezdaří, není zpráva doručena a je odložena (deferred).
- verify – TLS je vyžadováno, server musí mít platný certifikát od důvěryhodné certifikační autority a současně název hostitele musí odpovídat názvu certifikátu nebo alternativnímu DNS názvu v certifikátu. Pokud cokoliv z toho neplatí, není zpráva předána.
- další varianty, které však zde aktuálně nevyužijeme (více v dokumentaci Postfix TLS Support)
V ideálním světě, kde by všechny SMTP servery podporovaly TLS a používaly důvěryhodné certifikáty, bychom samozřejmě použili úroveň verify. Jenže v současném reálném světě bychom si e-mail neposlali skoro nikam, a tak nám musí stačit úroveň may, ve které nezabráníme man-in-the-middle útokům (neprovádíme autentizaci serveru, může nám být podstrčen cizí). Pro některé konkrétní SMTP servery můžeme změnit chování pomocí smtp_tls_policy_maps (třeba u serverů v rámci naší organizace).
Další položkou smtp_tls_session_cache_database zapneme TLS session cache. Tedy při více spojení na stejný server si pamatujeme dohodnutý klíč a další věci a snížíme režii navazování šifrovaného spojení. Položkou smtp_tls_loglevel upravíme úroveň logování, aby byly logy ukecanější a my měli více informací o činnosti TLS.
Pokud chceme ověřovat certifikáty serverů, musíme Postfixu sdělit, které jsou nám důvěryhodné certifikační autority. To učiníme parametrem smtp_tls_CAfile, což je odkaz na soubor, obsahující certifikáty kořenových certifikačních autorit. Takový soubor bude obvykle součástí nějakého balíčku vaší linuxové distibuce (obvykle ca-certificates). V příkladu uvedená cesta platí pro distibuce rodiny Red Hat (RHEL, Fedora, CentOS, Scientific Linux). U Debianu a spol. se jedná soubor /etc/ssl/certs/ca-certificates.crt. Toto celé má smysl jen v případě, že používáme úroveň bezpečnosti verify (v ideálním světě nebo v privátní síti), jinak je jedno, zda je spojení trusted nebo nikoliv. Bohužel na veřejném e-mailovém serveru na internetu to nevyužijeme.
Nastavení TLS v roli SMTP serveru je složitější. Nejprve musíme mít příslušný certifikát a soukromý klíč. Buď si vyrobíme nějaký self-signed (ale ten nebude globálně důvěryhodný a nebude tedy fungovat autentizace) nebo využijeme služeb některé z důvěryhodných certifikačních autorit. Postfix v posledních verzích podporuje také DANE protokol pro možnost ověřování certifikátů pomocí DNS, ale na jeho rozšíření a reálné použití si budeme muset ještě počkat. Pak se budeme moci certifikačních autorit zbavit a vše bude výrazně snazší.
Konfigurace Postfixu pak bude vypadat takto:
smtpd_tls_cert_file = /etc/postfix/config/ssl.crt smtpd_tls_key_file = /etc/postfix/config/ssl.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
Položka smtpd_tls_security_level může mít hodnoty none (TLS nenabízíme), may (TLS nabízíme, ale nevyžadujeme) a encrypt (TLS vyžadujeme, ale toto RFC v případě veřejných serverů nedovoluje).
Do souboru, uvedeného v smtpd_tls_cert_file, patří váš certifikát (musí být první) a případně také intermediate certifikáty vaší certifikační autority (v pořadí od nejnižšího k nejvyššímu), pokud jsou používány. SMTP klienti totiž budou mít jen kořenové certifikáty a intermediate jim musíte poskytnout vy.
To, že není ve výchozím stavu zapnuto TLS v roli SMTP serveru, chápu. Bez individuálně nastaveného certifikátu a klíčů to nejde. Ale to, že to není zapnuto pro roli klienta, považuji za chybu. Vůbec nic tomu nebrání – tedy pokud nemáte strach z OpenSSL.
Jak poznat použití šifrování
A jak poznáme, zda výměna e-mailu mezi SMTP klientem a serverem proběhla šifrovaně? Takto by měly vypadat záznamy v logu maillog na straně klienta (zkráceno a upraveno):
postfix/pickup: 4A65D2133: uid=500 from=<admin@example.com> postfix/cleanup: 4A65D2133: message-id=<20130825182147.4A65D2133@devel.example.com> postfix/qmgr: 4A65D2133: from=<admin@example.com>, size=2321, nrcpt=1 (queue active) postfix/smtp: setting up TLS connection to mail.example.cz[1.2.3.4]:25 postfix/smtp: Trusted TLS connection established to mail.example.cz[1.2.3.4]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) postfix/smtp: 4A65D2133: to=<petr@example.cz>, relay=mail.example.cz[1.2.3.4]:25, delay=0.19, delays=0.08/0/0.09/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6BF0A3F8C3) postfix/qmgr: 4A65D2133: removed
Informace Trusted TLS connection established nám říká, že TLS spojení bylo navázáno a certifikát serveru je platný a důvěryhodný.
Pokud by bylo navázáno TLS spojení, ale s nedůvěryhodným certifikátem (od nám neznámé certifikační autority), viděli bychom toto:
postfix/smtp: certificate verification failed for mail.example.cz[1.2.3.4]:25: untrusted issuer /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA postfix/smtp: Untrusted TLS connection established to mail.example.cz[1.2.3.4]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
To samé uvidíme i v případě, že sice důvěřujeme oné certifikační autoritě, ale server nám neposkytne potřebný intermediate certifikát (kterým je podepsán certifikát serveru a který je podepsán kořenovým certifikátem autority), tudíž nejsme schopni zkontrolovat celý řetez důvěry.
Pokud klient kontroluje název hostitele vůči certifikátu a názvy neodpovídají (certifikát nepatří tomu serveru), skončí doručování touto chybou:
status=deferred (Server certificate not verified)
Ve zdrojovém kódu e-mailové zprávy odhalíme TLS spojení tím, že u příslušné hlavičky Received uvidíme ESMTPS či něco jako SMTP with TLS, např.:
Received: from server.example.com (server.example.com [2.3.4.5])
by server.example.cz (Postfix) with ESMTPS id 6BF0A3F8C3
for <petr@example.cz>; Sun, 25 Aug 2013 20:21:47 +0200 (CEST)
Jak jsou na tom známé služby a weby
Už tedy víme, jak TLS nastavit a jak poznat, zda e-mail putoval šifrovaně. Nyní se podívejme, jak jsou na tom s podporou TLS některé služby a poskytovatelé.
Seznam.cz na tom není vůbec nijak. MX servery pro příjem pošty TLS nenabízí, stejně tak když odesíláte poštu ze Seznamu kamkoliv jinam, není TLS použito. Na můj dotaz na podpoře Seznamu mi bylo řečeno, že to předají obchodnímu oddělení. Nevím co s tím budou dělat obchodníci, spíše by to měli dostat technici.
To, že SMTP server šifrování na portu 25 nepodporuje, zjistíme z počátku SMTP komunikace, kde by nám mělo být nabídnuto STARTTLS, ale není:
$ telnet mx1.seznam.cz 25 Trying 77.75.72.42... Connected to mx1.seznam.cz. Escape character is '^]'. 220 2.0.0 Seznam SMTP server waiting for your HELO/EHLO EHLO mail.stastny.eu 250-Email.Seznam.cz - Email zdarma na cely zivot ESMTP 250-8BITMIME 250-PIPELINING 250-SIZE 18000000 250-ENHANCEDSTATUSCODES 250 X-SZNEXTENSIONS
A v e-mailu, poslaném ze Seznamu, postrádáme zmínku o ESMTPS:
Received: from mxh1.seznam.cz (mxh1.seznam.cz [77.75.72.26])
by mail.stastny.eu (Postfix) with ESMTP id E6ED13F8C3
for <test@stastny.eu>; Sun, 25 Aug 2013 20:38:47 +0200 (CEST)
Takže všichni, kteří používají freemailovou službu Seznamu, si vyměňují zprávy s celým světem nešifrovaně.
Naopak Centrum.cz je na tom dobře. SMTP server nám šifrované spojení nabídne:
$ telnet xmx1.centrum.cz 25 Trying 46.255.224.55... Connected to xmx1.centrum.cz. Escape character is '^]'. 220 mx.centrum.cz ESMTP EHLO mail.stastny.eu 250-mx.centrum.cz 250-8BITMIME 250-SIZE 20971520 250 STARTTLS
A e-mail poslaný od nich ven také jde šifrovaně (vidíme zmínku o ESMTPS):
Received: from gmmr7.centrum.cz (gmmr7.centrum.cz [IPv6:2a00:da80:0:502::5])
by mail.stastny.eu (Postfix) with ESMTPS id 1820F3F8C3
for <test@stastny.eu>; Sun, 25 Aug 2013 20:43:48 +0200 (CEST)
V logu Postfixu také vidíme, že nám byla zpráva z Centrum předána šifrovaně (a dokonce přes IPv6, chválím):
postfix/smtpd[12143]: connect from gmmr7.centrum.cz[2a00:da80:0:502::5] postfix/smtpd[12143]: Anonymous TLS connection established from gmmr7.centrum.cz[2a00:da80:0:502::5]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Google samozřejmě TLS podporuje.
Trochu mě trápilo, že organizace CZ.NIC neměla zapnuté TLS na svých serverech, ze kterých se posílají autorizační hesla k doménám CZ. Ale po mém upozornění to bylo do druhého dne napraveno s vysvětlením, že to tak mělo být, ale zapomněli na to.
A tím se dostáváme k e-mailům, u kterých nešifrování nejvíce bolí – u zpráv z různých webových služeb s hesly. Když se někde registrujete, obvykle vám přijde heslo nebo nějaký ověřovací klíč e-mailem. Stejně tak když heslo zapomenete, posílají vám e-mailem nové heslo nebo odkaz pro jeho resetování. A zde to bude se šifrováním moc špatné, takže to heslo může někdo po cestě odchytit. Zkusme namátkově nějaké české weby – vybral jsem zcela náhodně, nechtěl jsem někoho úmyslně schválit nebo pomluvit.
CzechComputer vám pošle odkaz pro nastavení nového hesla nešifrovaně:
Received: from mailer.czc.cz ([82.99.173.228]) by mx.centrum.cz with ESMTP; 25 Aug 2013 20:55:59 +0200
E-shop Lékárna.cz vám při zapomenutí hesla pošle nově vygenerované nešifrovaně:
Received: from lcz-b2.farmacie.cz ([178.77.239.57]) by mx.centrum.cz with SMTP; 25 Aug 2013 20:57:37 +0200
Mall.cz pošle odkaz nešifrovaně:
Received: from smtp5.mall.cz ([92.43.56.178]) by mx.centrum.cz with ESMTP; 25 Aug 2013 21:00:09 +0200
Slevomat.cz posílá všechny e-maily šifrovaně, tak to má vypadat:
Received: from mailer20.slevomat-1.superhosting.cz (mailer20.slevomat-1.superhosting.cz [46.234.101.148])
by mail.stastny.eu (Postfix) with ESMTPS id B43033F8C3
for <test@stastny.eu>; Sun, 25 Aug 2013 20:52:08 +0200 (CEST)
Nyní jen krátce výčet některých zjištění. A nevypadá to dobře. Překvapivě to neřeší ani některé hodně velké a důležité weby. Všechny e-maily (a i ty s hesly) k vám jistě putují v otevřené formě.
E-maily odesílají šifrovaně:
- Alza.cz
- Booking.com
- Centrum.cz
- CZ.NIC
- Česká pošta
- Heureka.cz
- Mironet.cz
- Slevomat.cz
- Živě.cz (mf.cz)
E-maily neodesílají šifrovaně:
- 100mega.cz
- CzechComputer
- Datové schránky
- DealExtreme.com
- Evernote.com
- Fio banka
- GoPay.cz
- Lupa.cz, Root.cz
- Mall.cz
- mBank
- PayPal.com
- PayU.cz
- Seznam.cz
- Transifex
- Wikipedia.org
Admini, šifrujte!
Proč jsem napsal tento článek? Protože chci, aby se o tomto podceňovaném problému veřejnost dozvěděla, aby si to uvědomili správci serverů a aby uživatelé tlačili na poskytovatele služeb, na e-shopy atd. A nezapomeňte si zjistit, zda třeba váš registrátor domény či webhoster posílá veškeré věci e-mailem šifrovaně (třeba vám při zřízení služby posílá hesla k e-mailovým schránkám, k FTP účtům apod.). Stačí kouknout do zdrojového kódu zprávy ve vašem e-mailovém programu (tedy pokud i váš e-mailový server TLS podporuje, a tak je schopen šifrované SMTP spojení přijmout).
Jsem rád, že se třeba organizace CZ.NIC tolik snaží a má tolik aktivit na téma bezpečnost na internetu (velmi dobře a úspěšně propagují DNSSEC, podílejí se na vývoji protokolu DANE, zajišťující provoz českého CSIRTu aj.), ale dle mého názoru velký problém s nešifrovanou e-mailovou komunikací pozornosti odborníků i veřejnosti nějak uniká. Přitom je zavedení šifrování u e-mailové komunikace tak snadné.
Takže prosím správce serverů – zapněte podporu TLS u SMTP. Nic tím nezkazíte. Sice to nezajistí dokonalé utajení, ale lepší než nic. Výrazně snížíte pravděpodobnost odposlechu.
ČLÁNKY DO MAILU