Adresy pocztowe przez dziesięciolecia składały się z wąskiego zestawu znaków: litery łacińskie, cyfry, garść znaków przestankowych. Kto nie zapisuje nazwiska alfabetem łacińskim, musiał je przepisywać — dla znacznej części świata drobna codzienna uciążliwość. Dwa rozszerzenia to naprawiły i oba niosą problem bezpieczeństwa, którego większość programów pocztowych do dziś nie rozwiązuje.
Dwa rozszerzenia, nie jedno
Adres ma dwie części i umiędzynarodowiono je osobno.
Część domenowa za znakiem @ może od początku lat dwutysięcznych nosić znaki spoza alfabetu łacińskiego. Technicznie odbywa się to przez przepisanie: zażółć.pl staje się wewnętrznie ciągiem zaczynającym się od xn--. To przepisanie nazywa się Punycode, jest jednoznacznie odwracalne, a DNS widzi wyłącznie postać ASCII. Dlatego takie domeny działają wszędzie.
Część lokalna przed znakiem @ to rozszerzenie nowsze i trudniejsze. Dla niej przepisania nie ma — w wiadomości stoją prawdziwe znaki UTF-8. Żeby to działało, każdy uczestniczący serwer musi obsługiwać rozszerzenie SMTP o nazwie SMTPUTF8. Gdy brakuje go w jednym miejscu łańcucha, wiadomość zostaje odrzucona.
Różnica ma praktyczne znaczenie: adres w rodzaju info@zażółć.pl jest bezpieczny. Adres w rodzaju zażółć@firma.pl już nie — może polec po drodze na serwerze, którego się ani nie zna, ani na niego nie wpływa.
Miejsce, w którym robi się nieprzyjemnie
Różne systemy pisma zawierają znaki, które wyglądają tak samo, a takie same nie są. Cyrylickie а (U+0430) i łacińskie a (U+0061) rysowane są identycznie w praktycznie każdym kroju pisma. Tak samo е i e, о i o, р i p, с i c.
Dlaczego przeglądarki rozwiązały to lepiej
W pasku adresu przeglądarki ten atak jest w dużej mierze załatwiony, i to regułą, która na pierwszy rzut oka wygląda topornie: jeśli nazwa domeny zawiera znaki z kilku systemów pisma albo system pisma nie pasuje do ustawionego języka, przeglądarka pokazuje postać w Punycode. Z łudząco prawdziwej domeny robi się wtedy widoczne xn--….
Programy pocztowe w większości tego nie robią. Pokazują adres nadawcy tak, jak jest zapisany — często nawet wyłącznie nazwę wyświetlaną, a adresu wcale. Ochrona, do której przywykliśmy w przeglądarce, tu po prostu nie istnieje.
Do czego to bywa wykorzystywane
- Nadawcy wyglądający na partnera handlowego. W połączeniu z toczącą się sprawą i zmienionym numerem konta to klasyczne przekierowanie faktury.
- Domeny zarejestrowane w pełni i wyposażone w SPF, DKIM oraz DMARC. Ważne, żeby to zrozumieć: taka wiadomość jest technicznie poprawnie uwierzytelniona. Przychodzi z domeny, którą deklaruje — tyle że jest to inna domena niż ta, o której myśli czytelnik. Żaden mechanizm weryfikacji tu nie zareaguje, bo żaden nie ma czego zakwestionować.
- Odnośniki w treści prowadzące do domeny bliźniaczej, gdzie czeka wierna kopia strony logowania.
Punkt drugi jest najważniejszy i regularnie się go przeocza. Zielony znaczek przy weryfikacji nadawcy nie mówi nic o tym, czy domena jest właściwa. Mówi jedynie, że zgadza się sama ze sobą.
Co pomaga
Przy czytaniu: nazwa wyświetlana jest bezwartościowa, adres niemal również — rozstrzyga to, jak się rozwiązuje. Kto ma wątpliwości przy wezwaniu do zapłaty, wkleja adres do pola tekstowego i sprawdza, czy wszystkie znaki są tym, za co się podają. Bardziej praktyczna na co dzień jest reguła, która i tak obowiązuje: zmienionego numeru konta nie potwierdza się pocztą, tylko pod numerem telefonu, który już się ma. Dalsze cechy, po których takie wiadomości da się rozpoznać, opisuje osobny artykuł.
Przy budowaniu formularzy: własnoręcznie pisane wyrażenia sprawdzające adres zawodzą tu w obie strony. Albo nie przepuszczają poprawnych adresów międzynarodowych — odcinając prawdziwych użytkowników — albo przyjmują wszystko. Sprawdzenie, które naprawdę się broni, jest i tak inne: wysłać na ten adres wiadomość potwierdzającą. Kto bada tylko ciąg znaków, bada nie to, co trzeba.
Przy prowadzeniu marki: nasuwająca się obrona — rejestrowanie wszystkich podobnych domen samemu — przy pomyłkach łacińskich jeszcze jako tako działa, przy Unicode już nie. Liczba zapisów nieodróżnialnych wzrokowo jest zbyt duża, żeby je wykupić. Pomaga natomiast obserwacja: istnieją publiczne rejestry wszystkich nowo wystawionych certyfikatów TLS, a domena naśladująca własną nazwę pojawia się tam, gdy tylko ktoś ją uruchomi.
A własny adres?
Jeśli prowadzisz domenę ze znakami specjalnymi, załóż zapis w ASCII jako drugą domenę i ustaw przekierowanie. Nie ze względu na technikę — ta działa — tylko ze względu na ludzi, którzy muszą podać adres przez telefon.
A co do części lokalnej przed @: dopóki nie wiesz, że wszyscy Twoi korespondenci obsługują SMTPUTF8, adres z liter łacińskich jest wyborem, który pewnie dociera. To nie jest zalecenie, z którego trzeba być zadowolonym — to stan wdrożenia.