Kto wysyła dziś wiadomość, może być dość pewny, że pojedzie ona zaszyfrowana. Między dużymi dostawcami praktycznie cały ruch idzie po TLS. Łatwo przy tym przeoczyć, że to szyfrowanie jest uprzejmością, a nie warunkiem. Da się je wyłączyć z zewnątrz, a w ustawieniach domyślnych nikt tego nie zauważa.
Dlaczego szyfrowanie SMTP może ustąpić
SMTP jest starszy niż szyfrowanie, z którego dziś korzysta. Dobudowano je później, poleceniem STARTTLS: przy pierwszym kontakcie serwer odbierający wymienia swoje możliwości, a wśród nich — być może — STARTTLS. Nadawca korzysta z oferty, jeśli ta jest.
Z tej kolejności wynikają dwie właściwości, które razem tworzą cały problem:
- Negocjacja odbywa się jawnym tekstem. Kto kontroluje połączenie, może po prostu wykreślić wiersz z ofertą. Nadawca widzi wtedy serwer, który nie umie TLS — i dostarcza jawnym tekstem, bo alternatywą byłoby niedostarczenie w ogóle.
- Certyfikaty nie są domyślnie weryfikowane. W sieci przeglądarka zatrzymuje się przy złym certyfikacie. W ruchu SMTP między serwerami przyjmuje się zwykle wszystko: wygasły, samopodpisany, wystawiony na zupełnie inną nazwę. Połączenie jest zaszyfrowane, tylko nikt nie sprawdził, z kim.
Ta ustępliwość była zamierzona. Gdy wprowadzano TLS, większość serwerów go nie umiała, a sztywna reguła rozłożyłaby doręczanie. Ceną jest to, że szyfrowanie znika dokładnie wtedy, gdy komuś aktywnie zależy, żeby zniknęło.
MTA-STS: polityka po HTTPS
MTA-STS zamyka lukę środkiem, który i tak jest wszędzie: serwerem WWW z ważnym certyfikatem. Domena publikuje dwie rzeczy.
Wpis DNS pod _mta-sts.firma.pl, mówiący tylko tyle, że polityka istnieje, i noszący oznaczenie wersji:
_mta-sts.firma.pl. TXT "v=STSv1; id=20260903120000"Samą politykę, dostępną pod stałym adresem https://mta-sts.firma.pl/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.firma.pl
mx: mail2.firma.pl
max_age: 604800Serwer wysyłający pobiera ten plik po HTTPS — czyli połączeniem z prawdziwą weryfikacją certyfikatu — i zapamiętuje go na podany czas. Odtąd obowiązuje: ten odbiorca umie TLS, jego certyfikat musi opiewać na jedną z wymienionych nazw, a jeśli któreś nie zachodzi, nic nie zostanie doręczone.
Napastnik z rysunku nadal może manipulować połączeniem SMTP. Po prostu nic już z tego nie ma, bo nadawca z góry wie, czego się spodziewać.
Rozstrzygający jest tryb. testing tylko zgłasza naruszenia, enforce odrzuca. Droga wiedzie przez testing, dopóki raporty nie są czyste — inaczej wyłączasz sobie własną pocztę przychodzącą.
DANE: polityka w DNS
DANE rozwiązuje ten sam problem inaczej. Zamiast pliku na serwerze WWW odcisk oczekiwanego certyfikatu leży wprost w DNS, jako wpis TLSA obok nazwy MX:
_25._tcp.mail.firma.pl. TLSA 3 1 1 <odcisk klucza>Wpis wiąże połączenie dokładnie z tym kluczem. Inny certyfikat, obojętne przez które centrum wystawiony, zostaje odrzucony.
Działa to jednak pod jednym warunkiem: strefa musi być podpisana DNSSEC. Bez tego wpis TLSA dałoby się podrobić tą samą drogą co wszystko inne w DNS i całe ćwiczenie byłoby bezskuteczne. DANE bez DNSSEC nie istnieje — to nie zalecenie, tylko warunek wstępny.
Porównanie
| MTA-STS | DANE | |
|---|---|---|
| Punkt zaufania | centra certyfikacji, jak w przeglądarce | DNSSEC |
| Pobranie przez | HTTPS plus jeden wpis DNS | wyłącznie DNS |
| Warunek | serwer WWW z ważnym certyfikatem | podpisana strefa |
| Pierwsze połączenie | niechronione, dopóki polityka nie zostanie pobrana | chronione od pierwszego połączenia |
| Zapamiętywanie | tak, do wygaśnięcia max_age | nie, obowiązuje czas życia wpisu DNS |
| Typowa awaria | wygasły certyfikat WWW, zapomniane id | wymiana klucza bez nowego wpisu TLSA |
Mechanizmy się nie wykluczają. Kto opublikuje oba, jest chroniony przez każdego nadawcę, który umie którykolwiek z nich — a razem jest ich wyraźnie więcej niż przy każdym z osobna.
Część nieefektowna: raporty
Oba mechanizmy zawodzą po cichu. Gdy połączenie zostaje przerwane, bo certyfikat wygasł, wiadomość zostaje w kolejce nadawcy — nie dowiesz się o tym, dopóki ktoś nie zapyta, dlaczego nie przychodzi poczta.
Odpowiedzią jest TLS-RPT, jeszcze jeden wpis DNS:
_smtp._tls.firma.pl. TXT "v=TLSRPTv1; rua=mailto:raporty-tls@firma.pl"Serwery wysyłające przysyłają wtedy codzienne podsumowanie: ile połączeń doszło do skutku, ile zawiodło i na czym. To ta część, którą najchętniej się pomija i której najprędzej potrzeba. Polityka bez kanału zwrotnego jest pułapką, która kiedyś się zamknie.
Czego to nie załatwia
Oba mechanizmy zabezpieczają transport między dwoma serwerami. Na miejscu wiadomość leży znów niezaszyfrowana, operator serwera docelowego może ją przeczytać, a o drugim i trzecim przeskoku nie mówią nic. Kto chce chronić treść przed dostawcą, potrzebuje szyfrowania obejmującego całą drogę — czym różnią się te mechanizmy i dlaczego poczta z natury nie jest szyfrowana od końca do końca, opisuje osobny artykuł.
MTA-STS i DANE rozwiązują węziej zakrojony problem i robią to dobrze: odbierają napastnikowi możliwość, by samym zakłócaniem sprawić, że szyfrowanie znika.