www.SAMURAJ-cz.com 

10.12.2019 Julie Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

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

Pondělí, 25.11.2019 15:56 | Samuraj - Petr Bouška |
Simple Mail Transfer Protocol (SMTP) protokol přenáší standardně poštovní zprávy v čistém textu. Pokud nějaký útočník zachytí komunikaci, tak může jednoduše číst obsah zpráv i zobrazovat přílohy. Řešením je využít klientské šifrování emailů (end-to-end encryption pomocí S/MIME, PGP, apod.), ale pak je třeba řešit správu a předávání šifrovacích klíčů / certifikátů. Druhá možnost je šifrování SMTP komunikace při přenosu (to ovšem nechrání zprávy na serveru) a to si zde popíšeme. Podíváme se na nastavení na Cisco Email Security (ESA) a Exchange Server 2016.

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)

  • 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í.

Cisco Email Security - Mail Flow Policies

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.

Cisco Email Security - Monitor - TLS Connections
  • 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í.

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.

zobrazeno: 368krát | Komentáře [0]

Autor:

Související články:

Microsoft Exchange

Jednou částí mé práce je administrace poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Články začínají u verze 2003 a jak jde čas, tak pokračují dále.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách