STARTTLS fallback

Mechanizm awaryjny bez STARTTLS przesyła pocztę bez szyfrowania, gdy serwer docelowy nie wspiera tego rozszerzenia.

Jak działa przejście z SMTP do szyfrowanego połączenia

STARTTLS fallback oznacza awaryjne zachowanie klienta albo serwera pocztowego, który próbuje rozpocząć transmisję SMTP w trybie szyfrowanym, ale po nieudanej próbie wraca do zwykłego połączenia bez TLS. W typowej sesji SMTP urządzenia najpierw nawiązują połączenie TCP, a następnie serwer przedstawia dostępne rozszerzenia po komendzie EHLO. Jeżeli odpowiedź zawiera rozszerzenie STARTTLS, klient może wysłać komendę STARTTLS. Serwer powinien odpowiedzieć kodem 220, po czym obie strony wykonują negocjację TLS w ramach już otwartego połączenia.

Po pomyślnym zakończeniu negocjacji TLS klient powinien ponownie wysłać EHLO, ponieważ lista rozszerzeń SMTP obowiązująca przed szyfrowaniem nie musi być identyczna po jego uruchomieniu. Dopiero później wykonywane są komendy związane z nadawcą, odbiorcą i treścią wiadomości, takie jak MAIL FROM, RCPT TO oraz DATA. Jeżeli klient uzna brak rozszerzenia STARTTLS albo nieudaną negocjację za sytuację możliwą do obejścia, może kontynuować tę samą sesję bez ochrony kryptograficznej.

Różnica między trybem oportunistycznym a wymuszonym TLS

Fallback nie jest właściwością samego protokołu TLS, lecz decyzją podjętą przez konkretną konfigurację oprogramowania pocztowego. W trybie oportunistycznym STARTTLS jest używane, gdy druga strona je oferuje, ale brak rozszerzenia lub błąd negocjacji może zostać potraktowany jako powód do kontynuowania transmisji w postaci jawnej. Takie zachowanie bywa spotykane w komunikacji SMTP między różnymi systemami, ponieważ historycznie nie każdy serwer obsługiwał STARTTLS.

W trybie wymaganym połączenie bez TLS powinno zostać przerwane. Ma to znaczenie szczególnie wtedy, gdy wiadomość zawiera dane, które nie powinny być przesyłane przez sieć bez szyfrowania. Samo użycie komendy STARTTLS nie gwarantuje jednak bezpieczeństwa, jeżeli klient akceptuje późniejszy fallback. Atakujący znajdujący się na drodze między nadawcą a odbiorcą może próbować usunąć z odpowiedzi serwera informację o rozszerzeniu STARTTLS. Klient, który nie wymaga szyfrowania, może wtedy uznać zwykłe SMTP za prawidłowe połączenie.

Standard SMTP dla rozszerzenia STARTTLS opisuje RFC 3207. Dokument ten wskazuje, że przed rozpoczęciem TLS sesja SMTP nie powinna być traktowana jako uwierzytelniona ani chroniona, a po rozpoczęciu szyfrowania strony powinny ponownie wykonać etap rozpoznania rozszerzeń. Ochrona zależy więc nie tylko od obecności certyfikatu, lecz także od tego, czy klient sprawdza wynik negocjacji i czy jego polityka zabrania dalszej pracy po niepowodzeniu.

Port połączenia nie rozstrzyga o bezpieczeństwie

W praktyce diagnostycznej nie należy utożsamiać numeru portu z automatycznie zapewnionym szyfrowaniem. Port 25 jest tradycyjnie używany do przekazywania poczty między serwerami SMTP, a STARTTLS może być na nim oferowane jako rozszerzenie negocjowane po ustanowieniu połączenia. Port 587 jest przeznaczony do przesyłania poczty przez klienta do serwera pocztowego, zwykle z użyciem uwierzytelniania i STARTTLS. Port 465 jest natomiast używany do SMTP z TLS uruchamianym od początku połączenia, czyli bez przechodzenia z jawnego SMTP do TLS za pomocą komendy STARTTLS.

Nie oznacza to, że każda konfiguracja portu 587 ma identyczne wymagania ani że sam wybór portu 465 naprawia błędną konfigurację klienta. Program pocztowy może mieć osobne ustawienia typu zabezpieczenia, metody uwierzytelniania, nazwy hosta oraz weryfikacji certyfikatu. Jeżeli dla portu wymagającego STARTTLS ustawiono tryb „brak szyfrowania” albo „jeśli dostępne”, połączenie może zachowywać się inaczej niż zakłada użytkownik. Z kolei ustawienie TLS od początku na porcie przeznaczonym do takiej pracy nie jest tym samym mechanizmem co STARTTLS fallback.

Podczas sprawdzania logu sesji SMTP warto szukać kolejności zdarzeń: odpowiedzi na EHLO, obecności lub braku wpisu STARTTLS, wysłania komendy STARTTLS, odpowiedzi 220, komunikatów z biblioteki TLS oraz ponownego EHLO. Jeżeli po błędzie certyfikatu, odmowie komendy albo przekroczeniu czasu oczekiwania pojawiają się dalsze komendy MAIL FROM i RCPT TO, może to wskazywać na dopuszczony fallback. Jeżeli sesja kończy się komunikatem o niemożności ustanowienia bezpiecznego kanału, szyfrowanie jest prawdopodobnie wymagane.

Objawy konfiguracji wymagającej weryfikacji

Na komputerze użytkownika problem może ujawnić się jako niespójne zachowanie wysyłania poczty: jedna sieć pozwala wysłać wiadomość, a inna zwraca błąd połączenia, klient zgłasza zmianę poziomu zabezpieczeń albo log pokazuje próbę STARTTLS zakończoną powrotem do SMTP. Taki objaw nie dowodzi jeszcze, że wiadomość rzeczywiście została wysłana bez szyfrowania. Trzeba odróżnić odrzucenie sesji, błędny certyfikat, brak rozszerzenia, blokadę zapory, problem DNS oraz świadomie dopuszczony fallback.

W ustawieniach klienta należy sprawdzić osobno serwer poczty przychodzącej i wychodzącej, numer portu, rodzaj ochrony połączenia oraz opcję określającą, czy szyfrowanie jest wymagane. Pomocne są logi aplikacji i przechwycenie metadanych sesji, ale nie należy ujawniać haseł ani pełnej treści wiadomości. Weryfikacja certyfikatu powinna obejmować zgodność nazwy hosta, poprawność łańcucha zaufania i okres ważności. Wyłączenie sprawdzania certyfikatu usuwa sygnał ostrzegawczy, lecz nie rozwiązuje problemu z negocjacją TLS.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną diagnostykę laptopów i komputerów PC, gdy problemy z klientem pocztowym, siecią lub konfiguracją systemu utrudniają prawidłowe korzystanie z komputera. W przypadku STARTTLS fallback zakres diagnostyki na stanowisku użytkownika może obejmować analizę komunikatów programu, ustawień połączenia i logów dostępnych w systemie, bez utożsamiania lokalnego objawu z naprawą konfiguracji serwera pocztowego.