Jakiś czas temu pisałem na blogu o metodach zabezpieczania poczty, takich jak DKIM oraz DMARC. Tylko część firm z nich korzysta, ale ponieważ spamerzy i różnego rodzaju włamywacze wymyślają nowe rodzaje ataków i metody podszycia się pod zaprzyjaźnionego nadawcę, więc dostawcy usług pocztowych próbują wprowadzić nowe metody zabezpieczeń. Tym razem chciałem przyjrzeć się dwóm takim pomysłom - SMTP STS (Strict Transport Security) oraz DANE (The DNS-based Authentication of Named Entities).
Obie te metody próbują zaadresować jedną z ułomności SMTP, związaną z szyfrowaniem transmisji poprzez TLS. W trakcie zestawiania sesji SMTP serwery mogą włączyć szyfrowanie TLS, poprzez użycie komendy STARTTLS.
Niestety w żaden sposób nie jest weryfikowana tożsamość serwera - jeżeli ktoś podmieni w DNS adres IP serwera i przedstawi się on odpowiednią nazwą, to sesja TLS będzie zestawiona i taki fałszywy serwer może następnie zestawić w analogiczny sposób połączenie z naszym rzeczywistym serwerem, przeglądając wszystkie wiadomości, pomimo tego, że transmisja jest szyfrowana (tzw. atak man in the middle).
Jak temu zapobiec? DKIM (przypomnę, że jest to metoda na podpisywanie maili wychodzących certyfikatem, którego klucz publiczny publikowany jest w rekordzie tekstowym naszej domeny) wykorzystuje DNS do potwierdzenia poprawności używanego przez nasz serwer certyfikatu. Podobnie działa DANE - to metoda na weryfikację poprawności certyfikatu, użytego do zaszyfrowania połączenia TLS poprzez publikację w DNS. Metoda ta zadziała poprawnie zarówno dla certyfikatów z urzędów komercyjnych, naszych wewnętrznych urzędów CA jak i dla certyfikatów typu SelfSign. Niestety w tej metodzie jest jeden problem - chociaż DANE jest już opisana w dokumentach RFC, to wymaga nowego typu rekordu DNS - TLSA (Transport Layer Security Authentication). Jeżeli spojrzymy na platformę Windows, to jest on dostępny tylko w Windows Server 2016. Ponadto strefa DNS musi być zabezpieczona (DNSSEC). Mając certyfikat, który chcemy wykorzystać do zabezpieczenia poprzez DANE, musimy wygenerować odpowiedni rekord TLSA, zawierający hash naszego certyfikatu. Możemy to zrobić z narzędzia powiązanego z naszym DNS:
Możemy również użyć narzędzia webowego, żeby sobi pomóc przy składni - https://www.huque.com/bin/gen_tlsa Pojawiło się również sporo stron, które pozwalają nam zweryfikować czy nasz rekord jest poprawnie opublikowany - np. https://check.sidnlabs.nl/dane/ lub http://tlsa.info. Często popełniane przy konfiguracji błędy można znaleźć na tej stronie - https://dane.sys4.de/common_mistakes. Polecam również prezentację na temat DANE - https://www.menandmice.com/resources/webinar-dnssec-and-dane-e-mail-security/.
Exchange nie potrafi korzystać z takiego mechanizmu (choć są dostępne narzędzia, które na to pozwalają - np. CryptoFilter for Exchange), nie ma go jeszcze również większość bramek antyspamowych, ale duzi dostawcy usług pocztowych już wprowadzają tego typu mechanizmy. Oczywiście mechanizm DANE, lub jak niektórzy piszą TLSA, może być również dodatkową weryfikacją serwera webowego zabezpieczonego TLS. Co ciekawe, na rynku niemieckim ponad połowa dostawców usług pocztowych używa już DANE, a w Danii jest to wymóg do komunikacji dla agencji rządowych. W Polsce na razie jeszcze nie jest on tak popularny.
Inną metodą na wyeliminowanie zagrożeń przy TLS może być SMTP STS (Strict Transport Security), który jest jak na razie na etapie draftu, ale wszystko wskazuje na to, że niebawem szerzej wejdzie do użytku. STS omija cześć niedogodności jakie niesie DANE (użycie nowego typu rekordu DNS), a rekord DNS typu TXT z standardową nazwą _mta-sts jest uzupełniony przez dokument JSON, publikowany przez zabezpieczony TLS-em serwer webowy. Czyli zabezpieczenia naszej domeny opisane są przez rekord DNS:
_mta-sts.pepug.org 900 IN TXT "v=STSv1; id=20170523"
gdzie STSv1 oznacza wersję (oczywiście jest wersja 1) oraz numer polisy zabezpieczeń. Plik json z kolei publikowany będzie poprzez url
https://mta-sts.pepug.org/.well-known/mta-sts.json
W nazwie hosta nie może być znaku _, więc mamy tu drobną różnicę (oczywiście rekord A lub C z nazwą mta-sts wskazującą na serwer webowy publikujący JSON-a musi znaleźć się w strefie naszej domeny). Dodatkowym wymogiem jest zabezpieczenie serwera webowego certyfikatem wydanym przez publiczny urząd certyfikacyjny.
Zasada działania jest prosta - normalnie wysyłając pocztę, nasz serwer pocztowy, czy mówiąc bardziej technicznie MTA, odpytuje DNS o serwer pocztowy wymieniony w rekordzie MX domeny adresata. W przypadku STS nasz MTA odpytuje DNS o rekord TXT, na podstawie którego pobiera kanałem szyfrowanym plik JSON z informacją o polisie i rekordzie MX. Dopiero po uzyskaniu tej informacji mail wysyłany jest do zweryfikowanego serwera pocztowego adresata poprzez kanał TLS.
Exchange nie potrafi korzystać z takiego mechanizmu (choć są dostępne narzędzia, które na to pozwalają - np. CryptoFilter for Exchange), nie ma go jeszcze również większość bramek antyspamowych, ale duzi dostawcy usług pocztowych już wprowadzają tego typu mechanizmy. Oczywiście mechanizm DANE, lub jak niektórzy piszą TLSA, może być również dodatkową weryfikacją serwera webowego zabezpieczonego TLS. Co ciekawe, na rynku niemieckim ponad połowa dostawców usług pocztowych używa już DANE, a w Danii jest to wymóg do komunikacji dla agencji rządowych. W Polsce na razie jeszcze nie jest on tak popularny.
Inną metodą na wyeliminowanie zagrożeń przy TLS może być SMTP STS (Strict Transport Security), który jest jak na razie na etapie draftu, ale wszystko wskazuje na to, że niebawem szerzej wejdzie do użytku. STS omija cześć niedogodności jakie niesie DANE (użycie nowego typu rekordu DNS), a rekord DNS typu TXT z standardową nazwą _mta-sts jest uzupełniony przez dokument JSON, publikowany przez zabezpieczony TLS-em serwer webowy. Czyli zabezpieczenia naszej domeny opisane są przez rekord DNS:
_mta-sts.pepug.org 900 IN TXT "v=STSv1; id=20170523"
gdzie STSv1 oznacza wersję (oczywiście jest wersja 1) oraz numer polisy zabezpieczeń. Plik json z kolei publikowany będzie poprzez url
https://mta-sts.pepug.org/.well-known/mta-sts.json
W nazwie hosta nie może być znaku _, więc mamy tu drobną różnicę (oczywiście rekord A lub C z nazwą mta-sts wskazującą na serwer webowy publikujący JSON-a musi znaleźć się w strefie naszej domeny). Dodatkowym wymogiem jest zabezpieczenie serwera webowego certyfikatem wydanym przez publiczny urząd certyfikacyjny.
Zasada działania jest prosta - normalnie wysyłając pocztę, nasz serwer pocztowy, czy mówiąc bardziej technicznie MTA, odpytuje DNS o serwer pocztowy wymieniony w rekordzie MX domeny adresata. W przypadku STS nasz MTA odpytuje DNS o rekord TXT, na podstawie którego pobiera kanałem szyfrowanym plik JSON z informacją o polisie i rekordzie MX. Dopiero po uzyskaniu tej informacji mail wysyłany jest do zweryfikowanego serwera pocztowego adresata poprzez kanał TLS.
Brak komentarzy:
Prześlij komentarz