SMTP over TLS šifrování na MS Exchange a Cisco Email Security

Test aktuálního stavu šifrování

Online služba

Na otestování, zda nám funguje šifrování pro příjem a odesílání pošty, můžeme použít web https://www.checktls.com/.

Na stránce https://www.checktls.com/TestReceiver otestujeme příjem pošty. Stačí zadat naši doménu nebo emailovou adresu a zobrazí se log navazování SMTP over TLS i s komentáři. Žádný mail se neodešle, protože spojení je ukončeno po ověření adresy odesílatele.

Na stránce https://www.checktls.com/TestSender můžeme testovat odeslání pošty. Je dobré vybrat položky v Select Extra Items to Show, abychom dostali více informací. Pak spustíme listener a zobrazí se nám adresa, na kterou odešleme email a kód do předmětu a případně parametry do těla mailu. Podle těchto pokynů odešleme email a během chvilky dostaneme odpověď, kde jsou informace, zda proběhlo šifrované odeslání mailu.

Aplikace OpenSSL

Pro otestování TLS na SMTP serveru můžeme také použít nástroj OpenSSL.

openssl s_client -connect mail.firma.cz:25 -starttls smtp

Poštovní klient

V poštovním klientovi MS Outlook si můžeme otevřít doručenou zprávu a podívat se na hlavičky (Internet Headers). Zde vidíme, jak byla zpráva přijímána jednotlivými poštovními servery (Mail Transport Agent - MTA) a pokud byl přenos šifrovaný, tak i údaje o použité šifře.

Received: from mail.firma.cz (mail.firma.cz [1.1.1.1])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by mail.firma2.cz (Postfix) with ESMTPS id 47M1Zz28nDz8saa
        for <nekdo@mail2.cz>; Mon, 25 Nov 2019 10:15:07 +0100 (CET)

Princip SMTP over TLS

Aby se dalo použít šifrování SMTP komunikace, tak byl původní SMTP protokol doplněn o STARTTLS rozšíření (Secure SMTP over TLS dle RFC 3207).

Po připojení k serveru pomocí SMTP, můžeme zadat příkaz přivítání EHLO (místo staršího HELO), načež server odpoví podporovanými vlastnostmi. Pokud podporuje šifrování, tak vrací vlastnost STARTTLS.

S: 220 mail.firma.cz ESMTP
C: EHLO test.cz
S: 250-mail.firma.cz
S: 250-SIZE 51380224
S: 250-8BITMIME
S: 250-STARTTLS

Klient pak může použít příkaz STARTTLS a následně se vymění certifikáty a vyjedná TLS (domluvení verze SSL/TLS a šifry).

C: STARTTLS    
S: 220 Go ahead with TLS
  " CN=mail.firma.cz, OU=IT ...
  " CN=mx1.seznam.cz CN=Let's Encrypt Authority ...
"TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits
 MAC hash algorithm CALG_SHA_384 with strength 0 bits and key exchange algorithm CALG_ECDH_EPHEM with strength 256 bits"
C: EHLO test.cz
S: 250-mail.firma.cz
S: 250-SIZE 51380224
S: 250-8BITMIME

Z pohledu šifrování se používají tři různé varianty:

• bez šifrování - na příchozí spojení není povoleno šifrování (server nenabízí STARTTLS)
• šifrování preferováno - šifrování je povoleno a nabízí se, připojující se strana jej může, ale nemusí použít, obecně se označuje jako Opportunistic TLS
• vyžadováno - šifrování je povinné, nabízí se a pokud druhá strana nepoužije STARTTLS, tak jsou ostatní příkazy odmítnuty (dle RFC 3207)

Pozn.: Není mi jasné, v kterých případech stačí serverový certifikát a kdy se použije i klientský (tedy certifikát připojujícího se serveru), což by vedlo k jeho ověření.

Pokud se používá nejčastější metoda, kdy je šifrování preferováno, a útočník se dostane do komunikace (Man in the Middle), tak může z provozu odstranit příkaz STARTTLS a obě strany komunikují nešifrovaně. Útoků existuje více, protože často se nekontroluje validita certifikátů. Při běžném nasazení je tedy SMTP over TLS vylepšení bezpečnosti, ale nelze na něj spoléhat. Jedna z metod na zlepšení bezpečnosti je DNS-based Authentication of Named Entities (DANE), který využívá Domain Name System Security Extensions (DNSSEC).

Cisco Email Security

ESA nám standardně filtruje příchozí poštu, případně ji můžeme použít i pro zpracování a kontrolu odchozí pošty. Zde se podíváme na nastavení TLS šifrování pro příjem pošty. Vše je dobře popsáno v oficiální dokumentaci Encrypting Communication with Other MTAs.

Certifikát pro šifrování

• Network - Certificates

Pro využití TLS potřebujeme X.509 certifikát. Na ESA je nahraný testovací certifikát Cisco ESA Certificate, ale ten není doporučeno použít pro ostrý provoz. Ideální je certifikát od nějaké důvěryhodné autority, i když mnoho poštovních serverů je nastaveno, že akceptují libovolný certifikát (například od interní autority firmy).

Ideálně tedy provedeme nahrání podepsaného certifikátu ve formátu PKCS#12 (často přípona .pfx, tedy kombinace certifikátu a privátního klíče).

Nastavení certifikátu na Listener

• Network - Listeners

Na Listener do internetu (Public), a případně i do vnitřní sítě (Private), musíme přiřadit certifikát, který se má používat. Jde o položku Certificate, kde vybereme ze seznamu dostupných certifikátů.

Nastavení TLS na Mail Flow Policy (Listeners HAT) - příjem pošty

• Mail Policies - Mail Flow Policies

Defaultně je TLS vypnuté. Nastavuje se pomocí politik Mail Flow Policy, které jsou přiřazeny na Host Access Table (HAT) pro určitý Listener. Díky tomu můžeme vytvořit HAT s určitými zdrojovými IP adresami a řídit různé nastavení TLS pro různé odesílatele. Pokud chceme zapnout na všechny přijímané zprávy, tak buď editujeme všechny Mail Flow Policies nebo nastavíme do Default Policy Parameters.

V sekci Security Features nastavujeme Encryption and Authentication, položku TLS. Volby jsou vypnuto (Off), preferováno (Preferred) nebo vyžadováno (Required). Pokud zvolíme preferováno TLS, tak můžeme také nastavit seznam domén a emailových adres, pro které je TLS povinné (TLS is Mandatory for Address List). Standardně se nekontroluje certifikát druhé strany, pokud je nějaký k dispozici a dohodne se šifra, tak se komunikace šifruje. Můžeme zvolit Verify Client Certificate, pak se standardně kontroluje certifikát (vydávající autorita, jméno, platnost). Pokud máme variantu Preferované TLS a druhá strana nenabídne certifikát, tak se zpráva doručí nešifrovaně, ale pokud neprojde validace, tak je odmítnuto spojení.

Nastavení TLS v Destination Controls - odesílání (doručování) pošty

• Mail Policies - Destination Controls

Stejně jako pro příjem pošty, je i pro odesílání TLS defaultně vypnuté. Odesílání se týká nejen odchozí pošty ze společnosti, ale také doručování na interní poštovní servery. Použitý certifikát se volí v Edit Global Settings.

Zapnutí TLS se provádí v profilu podle domény (cíle), můžeme využít Default pro všechny. V položce TLS Support volíme podobné možnosti, jako u HAT. U jednotlivých variant je možnost s Verify, kdy se ověřuje doménový certifikát.

Monitorování SMTP over TLS

• Monitor - TLS Connections

V sekci Monitor je pěkný report, kde vidíme kolik spojení proběhlo přes TLS a kolik nešifrovaně, také jestli sjednání TLS selhalo. Praxe ukazuje, že více než polovina spojení je šifrovaná. U některých domén vidím, že TLS selhalo, ale následně je stejný počet zpráv poslán nešifrovaně, takže patrně se server vždy pokusí poslat zprávu znovu.

• Monitor - Message Tracking

Můžeme také najít určitou zprávu logu sledování zpráv a v detailu vidíme na počátku, pokud je spojení šifrované a jaká se domluvila šifra.

Incoming connection (ICID 724949) successfully accepted TLS protocol TLSv1.2 cipher ECDHE-RSA-AES128-GCM-SHA256.

Microsoft Exchange Server 2016

Pro Exchange se podíváme na šifrování při odesílání pošty, tedy využití Send Connector. Situace je podobná pro příjem pošty, Receive Connectors. Nějakou dobu jsem se snažil najít informace, jak se nastavuje možnost, aby Exchange při odesílání pošty využil TLS, pokud to podporuje druhá strana. Ani v oficiální dokumentaci, ani jinde, jsem nic nenalezl (možná jsem přehlédl něco základního). Prohlédnutím logů a praktickými testy jsem zjistil, že ono je to defaultní chování.

Pozn.: Články na internetu řeší jedinou věc, a to pro některé domény odesílat zprávy vždy pomocí TLS, tedy vytvořit nový Send Connector (dobré je nezapomenout nastavit logování) a na něj nastavit Require TLS.

V popisu Send connectors toho moc nenajdeme. Konfigurace vlastností TLS se moc nedá nastavit v EAC (Exchange Admin Center), ale musí se provádět v příkazové řádce EMS (Exchange Management Shell). Pouze při vytváření Send Connector můžeme vybrat typ (Custom, Internal, Internet, Partner). Každý typ určuje různé parametry, které se na konektor nastaví.

V EMS máme cmdlet Set-SendConnector. Popis parametrů okolo TLS mi nepřijde úplně jasný, takže níže je můj dohad.

• IgnoreSTARTTLS - pokud nastavíme na true, tak se nebude používat šifrování pro tento konektor
• RequireTLS - nastavení na true vyžaduje použití šifrování pro odeslání všech zpráv přes tento konektor
• TlsAuthLevel - můžeme nastavit
  • EncryptionOnly - pak se provádí pouze šifrování
  • CertificateValidation - provádí se také kontrola certifikátu (vydávající řetězec a odvolané certifikáty)
  • DomainValidation - navíc se v certifikátu kontroluje FQDN, zda odpovídá parametru TlsDomain nebo doméně příjemce
• TlsCertificateName - pokud chceme použít jiný než Default certifikát, tak zde specifikujeme (zvláštním) zápisem <I>X.500Issuer<S>X.500Subject
• TlsDomain - specifikujeme doménu, která se kontroluje při DomainValidation, pro Smart Host Send Connector

Výchozí hodnoty (pro typ Custom) jsou následující

[PS] C:\>Get-SendConnector -Identity Internet | FL *tls*
TlsDomain          :
TlsAuthLevel       :
IgnoreSTARTTLS     : False
TlsCertificateName :
RequireTLS         : False

Kombinace IgnoreSTARTTLS  a RequireTLS nastavena na false, tedy patrně určuje, že se používá Opportunistic TLS. Pouze odhaduji, že je také třeba, aby byl na Exchange nastaven certifikát a povolen pro SMTP službu. První certifikát, který přiřadíme na službu SMTP se stává Default certifikátem. Pokud přiřazujeme nový certifikát, tak jej můžeme nastavit jako default (ale není to nutné).

Monitorování SMTP over TLS

Exchange Server nemá žádné přehledy nebo statistiky o využít šifrování. Můžeme se jedině podívat do protokolového logu (Protocol Log). Pro doručované zprávy využijeme Front End Transport service SmtpReceive log. Pro odesílané zprávy nejčastěji Transport service (Hub) SmtpSend log. Zde uvidíme, jestli byl použit příkaz STARTTLS a jak se vyjednala šifra, případně, zda došlo k chybě.

Nastavení certifikátu na Send Connector a chyba UnknownCredentials

Pochopil jsem to tak, že pokud interně používám na Exchange serverech certifikáty od interní autority, tak bych mohl použít další certifikát od důvěryhodné autority a ten nastavit na Send Connector pro odesílání do internetu.

Import PKCS#12 certifikátu

• EAC - Exchange Admin Center
• Servers - Certificates
• Import Exchange certificate
• zadávám síťovou cestu (certifikát musím nahrát někam do sdílené složky) a heslo k privátnímu klíči
• určuji, na jaké servery se má importovat

Poté musím přiřadit certifikát ke službě SMTP

• EAC - Exchange Admin Center
• Servers - Certificates
• Edit nahraného certifikátu
• Services - vyberu SMTP a Save
• při dotazu, zda chceme přepsat Default SMTP certifikát (tedy nastavit tento jako defaultní), zvolíme No

Dále musíme pokračovat v EMS.

Zobrazíme si seznam certifikátu a poznamenáme Thumbprint nově importovaného.

[PS] C:\>Get-ExchangeCertificate
Thumbprint                                Services   Subject
----------                                --------   -------
AC445208321CCE5AA22588700D1264F0E8BCC052  .......    CN=mail.firma.cz ...

Z tohoto certifikátu získáme hodnoty Issuer a Subject a uložíme je do formátu, který je požadován.

$TLSCert = Get-ExchangeCertificate -Thumbprint AC445208321CCE5AA22588700D1264F0E8BCC052
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"

A poté nastavíme na zvolený Send Connector.

Set-SendConnector -Identity Internet -TlsCertificateName $TLSCertName

Pokud potřebujeme nastavení zrušit.

Set-SendConnector -Identity Internet -TlsCertificateName $none

Ale ukázalo se, že mi následně přestaly odcházet některé emaily (zůstaly ve frontě). Po prohlédnutí Protocol Logu Send Connectoru je vidět, že se použije nový certifikát, ale vrátí se chyba TLS negotiation failed with error UnknownCredentials.

>,STARTTLS,
<,220 2.0.0 Ready to start TLS,
*,"CN=mail.firma.cz ...",Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alter
*,,TLS negotiation failed with error UnknownCredentials
-,,Local

Našel jsem pár článků s touto chybou, ale primárně se mluví, že jde o bug při nastavení certifikátu na Send Connector pro odesílání na Office 365. Navíc již opravený v instalovaném CU. "TLS negotiation failed with error UnknownCredentials" error after you update TLSCertificateName on Office 365 send connector in Exchange Server hybrid environment. Další článek mluvil o oprávnění k certifikátu.

Vyzkoušel jsem vše možné, ale chybu se nedařilo odstranit. Pak jsem certifikát na Exchange serveru smazal a znovu nahrál. Najednou vše fungovalo. Vyzkoušel jsem všemožné úpravy, ale stále šifrování s tímto certifikátem funguje.