Většina z nás již delší dobu minimálně tuší, že použití protokolu HTTPS rozhodně automaticky neznamená, že je komunikace neprolomitelně zabezpečena. Svět se vyvíjí čím dál rychleji ve všech představitelných oblastech a oblast bezpečnosti není žádnou výjimkou, a to, co bylo před pár lety či měsíci považováno za bezpečné, dnes již bezpečné být nemusí. Pro protokol HTTPS, resp. SSL/TLS toto platí zcela určitě a v nedávné minulosti bylo odhaleno hned několik slabých míst a publikována řada možných útoků na této slabá místa. Protože od Exchange Serveru 2013 je převážná část komunikace klient/server závislá na protokolech HTTPS nebo SMTP a služby běžně publikujeme do Internetu, je téma zvýšení zabezpečení SSL/TLS na Exchange Serverech velmi důležité.
Hlavní oblasti pro zesílení bezpečnosti SSL/TLS
Verze protokolu
V rámci vyjednávání o ustavení HTTPS relace mezi klientem a serverem dochází k dohodě o nejvyšší použitelné verzi protokolu SSL/TLS, kterých v čase vznikla hned celá řada. SSL standard pochází z hloubky minulého století a jeho původním autorem je společnost Netscape. Do praxe se prosadila verze SSL 2.0, SSL 3.0 a později byl protokol přejmenován na TLS, které máme ve verzích TLS 1.0, TLS 1.1, TLS 1.2 a TLS 1.3 je otázkou blízké budoucnosti.
Doporučení nepoužívat SSL 2.0 existuje již poměrně dlouhou dobu, ale ani SSL 3.0 již není považováno posledních pár let za bezpečné. Pomyslný hřebíček do rakve této verze protokolu přineslo odhalení zranitelnosti v roce 2014, kterou je možné zneužít pomocí útoku typu man-in-the-middle známého pod názvem Poodle.
Aktuálně bychom tedy měli používat výhradně jen TLS 1.0 a vyšší a optimálně přejít na TLS 1.2. Je potřeba si ale uvědomit, že například všechny naše instalace operačního systému Windows Server až do verze Windows Server 2012 R2 včetně mají ve výchozí instalaci SSL 3.0 povolené. Tedy většina instalací zabezpečená není, pokud jsme zabezpečení ručně nevynutili.
Obrázek 1 Windows: výchozí konfigurace podpory SSL klient/server
Kryptografie
Při použití HTTPS zjednodušeně říkáme, že komunikace je šifrovaná. To v nás většinou automaticky vyvolává dojem, že co je šifrované, to je přece bezpečné. Nicméně pokud něco zašifrujete dávno prolomeným kryptografickým algoritmem, který útočník umí dešifrovat třeba i v reálném čase, tento pocit bezpečí může být velmi falešný. V oblasti HTTPS se používá kryptografie velmi intenzivně a používá se vždy hned celý kryptografický mix algoritmů pro symetrické i asymetrické šifrování, hashovací algoritmy i algoritmy pro výměnu klíčů. A jak známo, celková bezpečnost je tak silná, jak silný je nejslabší článek. Stačí tak používat jeden ze slabých či rovnou prolomených algoritmů a celá bezpečnost HTTPS je více přáním a domněnkou než reálným stavem.
Součástí zabezpečení by tak mělo zakázání všech kryptografických kombinací (správný termín je „cipher suite“), které obsahují například RC2, RC4 atp. Naopak bychom měli preferovat prokazatelně bezpečné (optikou aktuální znalosti) algoritmy jako je AES, SHA-2, RSA, Diffie-Hellman a zapnout Forward Secrecy pro pravidelnou obměnu klíčů relace.
Certifikát
Použití SSL/TLS vyžaduje na straně serveru, a volitelně na straně klienta, důvěryhodný certifikát, který se využívá k ověření identity a také je nositelem veřejného klíče využívaného pro kryptografické operace. Minimální úroveň použité kryptografie by měla být SHA256 a RSA2048. Zde naštěstí tlak ze strany komerčních certifikačních autorit, a ještě více výrobců internetových prohlížečů a další softwarových domů, pomohl k tomu, že v roce 2017 již pouze 21 % webových serverů používá digitální certifikáty s SHA1 podpisem. Přestože se jedná vlastně také o téma kryptografie jako v předchozím odstavci, v praxi řešíme získávání a obnovu certifikátů obvykle jako izolovanou aktivitu, a proto je i v tomto článku věnován této problematice celý zvláštní odstavec.
Od teorie k praxi
Analýza stávajícího stavu
Aniž bychom nutně museli studovat hlubší detail výše nastíněné problematiky, můžeme naše servery vhodně zabezpečit použitím doporučených praktik. Užitečný nástroj, který nám v tom může pomoci je webová služba zdarma SSLLabs.
Zadáme zde do připraveného formuláře adresu našeho webového serveru (ano, i Exchange Server je z tohoto pohledu webový server) a po několika desítkách sekund se dozvíme, jak na tom náš server se zabezpečením SSL/TLS je, jaká rizika nám hrozí a jak je napravit. Výsledkem je také udělení výsledného ratingu.
Obvyklý výsledek Exchange Serveru 2013/2016 na Windows Serveru 2012 R2 vypadá poměrně katastroficky jako na obrázku níže.
Obrázek 2 SSLlabs rating v obvyklé výchozí konfiguraci Exchange Server 2013/2016
Po provedení níže doporučeného nastavení by výsledek měl odpovídat ratingu A podobně jako na obrázku.
Obrázek 3 SSLlabs rating po doporučeném zabezpečení SSL/TLS na Exchange Serveru 2013/2016
Doporučené zabezpečení SSL/TLS pro Exchange Server 2013/2016
Při zesílení zabezpečení se obvykle silně obáváme případné nekompatibility a funkčních problémů. Pokud ale používáme podporované operační systémy, klienty, prohlížeče a Exchange servery, je zcela praxí ověřené následující nastavení dle doporučení produktového týmu pro Microsoft Exchange Server.
- Vypněte SSL 2.0 i SSL 3.0 na klientech i serverech
- Prioritizujte TLS 1.2 a kryptografii s AES/3DES
- Zakažte použití RC4
- Používejte RSA-2048 bitů jako délku klíče digitálního certifikátu
- Nepoužívejte MD5/MD2 kdekoliv v certifikačním řetězci
- Při obnově certifikátu, přejděte na SHA2
- Nevypínejte zatím TLS 1.0. Podpora na straně Exchange Serveru přijde později v čase včetně doporučení pro nasazení v produkčním prostředí
Osobně pro rychlou konfiguraci dle těchto doporučení používám následující skript Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2 Skript můžete bez jakýchkoliv úprav spustit přímo na Exchange Serveru a ten za Vás provede všechna potřebná nastavení včetně reportu o provedených změnách. Tento skript není oficiálním nástrojem společnosti Microsoft a použití je samozřejmě na vlastní nebezpečí.
Obrázek 4 Skript pro zabezpečení SSL/TLS na Exchange Serveru
Několik poznámek na závěr
- Ve skutečnosti bezpečnost SSL/TLS není záležitostí pouze HTTPS protokolu, ale na Exchange Serveru je také významnou součástí bezpečného přenosu zpráv pomocí SMTP
- V budoucnu budou vydány kumulativní balíčky pro Exchange Server 2013/2016, které umožní kompletní přechod pouze na TLS 1.2. V tuto chvíli ale na Exchange Serverech nevypínejte podporu TLS 1.0.
- Pokud před Exchange serverem používáte jakoukoliv formu reverzní proxy, která využívá funkce SSL bridging, výsledky testů SSLLabs budou ukazovat hodnocení bezpečnosti reverzní proxy namísto Exchange serveru. Reverzní proxy by ale měla být zabezpečena z pohledu SSL/TLS dle uvedených doporučení úplně stejně jako samotné Exchange Servery.
Miroslav Knotek, KPCS CZ, knotek@kpcs.cz
KPCS CZ, s.r.o. je přední českou firmou specializující se na nasazení, správu a podporu informačních technologií, primárně zaměřenou na produkty společnosti Microsoft. Jako systémový integrátor poskytuje kvalitní podniková řešení na této platformě, která jsou v pravidelných intervalech hodnocena prvními příčkami v soutěžích Microsoft Awards. KPCS CZ disponuje předními odborníky na problematiku veřejného cloudu, tedy služeb Office 365 a Azure, ale i technologií privátního cloudu Windows Server, Hyper-V a produktů rodiny System Center.
