Czy STARTTLS jest mniej bezpieczny niż TLS / SSL?

W Thunderbird (i zakładam również w wielu innych klientach) mam opcję wyboru między „SSL / TLS” a „STARTTLS”.

O ile rozumiem, „STARTTLS” oznacza prostymi słowami „szyfruj, jeśli oba końce obsługują TLS, w przeciwnym razie nie szyfruj transferu” . „SSL / TLS” oznacza w prostych słowach „zawsze szyfruj lub nie łącz w ogóle” . Czy to jest poprawne?

Lub innymi słowy:

Czy STARTTLS jest mniej bezpieczny niż SSL / TLS, ponieważ może wrócić do zwykłego tekstu bez powiadamiania mnie?

Odpowiedź oparta na STARTTLS RFC dla SMTP ( RFC 3207 ) to:

STARTTLS jest mniej bezpieczny niż TLS.

Zamiast mówić sam, pozwolę RFC mówić za siebie, z czterema istotnymi bitami zaznaczonymi BOLD :

Atak typu man-in-the-middle można uruchomić, usuwając odpowiedź „250 STARTTLS” z serwera. Spowodowałoby to, że klient nie próbowałby rozpocząć sesji TLS. Innym atakiem typu man-in-the-middle jest umożliwienie serwerowi ogłosić swoją zdolność STARTTLS, ale zmiana żądania klienta dotyczącego uruchomienia TLS i odpowiedzi serwera. Aby bronić się przed takimi atakami, zarówno klienci, jak i serwery MUSZĄ być skonfigurowane tak, aby wymagały pomyślnej negocjacji TLS odpowiedniego pakietu szyfrów dla wybranych hostów, zanim będzie można pomyślnie przesłać wiadomości. Należy również zapewnić dodatkową opcję korzystania z TLS, jeśli to możliwe. Wdrożenie MAJ zapewniają możliwość rejestrowania, że ​​TLS był używany do komunikacji z danym urządzeniem równorzędnym i generowania ostrzeżenia, jeśli nie zostanie on użyty w późniejszej sesji.

Jeśli negocjacja TLS nie powiedzie się lub klient otrzyma odpowiedź 454, klient musi zdecydować, co dalej. Istnieją trzy główne opcje: kontynuuj resztę sesji SMTP , [...]

Jak widać, sam RFC stwierdza (niezbyt wyraźnie, ale wystarczająco jasno), że NIC nie wymaga od klientów nawiązywania bezpiecznego połączenia i informowania użytkowników, jeśli bezpieczne połączenie nie powiedzie się. Daje to wyraźnie klientom możliwość cichego nawiązywania połączeń zwykłego tekstu .

Nie ma różnicy w bezpieczeństwie między dwiema opcjami.

• SSL / TLS najpierw otwiera połączenie SSL / TLS, a następnie rozpoczyna transakcję SMTP. Musi to nastąpić na porcie, który nie ma już uruchomionego serwera SMTP innego niż SSL / TLS; ze względu na charakter protokołów nie można skonfigurować pojedynczego portu do obsługi zarówno zwykłego tekstu, jak i szyfrowanych połączeń.

• STARTTLS rozpoczyna transakcję SMTP i szuka wsparcia z drugiego końca dla TLS w odpowiedzi na EHLO. Jeśli klient zobaczy STARTTLS na liście obsługiwanych poleceń, wysyła STARTTLS i rozpoczyna negocjacje dotyczące szyfrowania. Wszystko to może (i zwykle ma miejsce) na standardowym porcie SMTP 25, częściowo w celu zapewnienia kompatybilności wstecznej, ale także w celu umożliwienia szyfrowania oportunistycznego między punktami końcowymi, które oba obsługują go, ale niekoniecznie wymagają tego.

Zasadniczo protokół SSL / TLS jest używany tylko między klientami końcowymi a serwerami. STARTTLS jest częściej używany między MTA w celu zabezpieczenia transportu między serwerami.

Biorąc pod uwagę te dwie implementacje, STARTTLS może być interpretowany jako niepewny, jeśli użytkownik lub administrator zakładają, że połączenie jest szyfrowane, ale tak naprawdę nie skonfigurowali go tak, aby wymagał szyfrowania. Jednak zastosowane szyfrowanie jest dokładnie takie samo jak SSL / TLS i dlatego nie jest mniej lub bardziej narażone na atak Man-in-the-Middle poza tego rodzaju błędem konfiguracji.

W szczególności w przypadku wiadomości e-mail w styczniu 2018 r. Wydano dokument RFC 8314 , który wyraźnie zaleca stosowanie „Implicit TLS” zamiast mechanizmu STARTTLS w przypadku przesyłania IMAP, POP3 i SMTP.

W skrócie, ta notatka zaleca teraz, aby:

• Protokół TLS w wersji 1.2 lub nowszej może być używany do całego ruchu między MUA a serwerami przesyłania poczty, a także między MUA a serwerami dostępu do poczty.
• MUA i dostawcy usług pocztowych (MSP) (a) zniechęcają do korzystania z protokołów jawnego tekstu w celu dostępu do poczty i przesyłania poczty oraz (b) przestają używać protokołów czystego tekstu do tych celów tak szybko, jak to możliwe.
• Połączenia z serwerami przesyłania poczty i serwerami dostępu do poczty można nawiązywać za pomocą „Implicit TLS” (jak zdefiniowano poniżej), zamiast łączenia się z portem „czystego tekstu” i negocjowania TLS za pomocą polecenia STARTTLS lub podobnego polecenia.

(podkreślenie dodane)

Odpowiedź zależy w pewnym stopniu od tego, co rozumiesz przez „bezpieczny”.

Po pierwsze, twoje podsumowanie nie do końca oddaje różnicę między SSL / TLS a STARTTLS.

• Dzięki SSL / TLS klient otwiera połączenie TCP z „portem SSL” przypisanym do protokołu aplikacji, którego chce używać, i natychmiast zaczyna mówić TLS.
• Dzięki STARTTLS klient otwiera połączenie TCP z „portem czystego tekstu” powiązanym z protokołem aplikacji, którego chce użyć, a następnie pyta serwer „jakie rozszerzenia protokołu obsługujecie?”. Serwer następnie odpowiada listą rozszerzeń. Jeśli jednym z tych rozszerzeń jest „STARTTLS”, klient może powiedzieć „OK, użyjmy TLS” i oba zaczną mówić TLS.

Jeśli klient jest skonfigurowany tak, aby wymagać TLS, oba podejścia są mniej więcej tak samo bezpieczne. Ale są pewne subtelności na temat tego, w jaki sposób należy używać STARTTLS, aby było bezpieczne, a implementacja STARTTLS jest nieco trudniejsza, aby uzyskać prawidłowe dane.

Z drugiej strony, jeśli klient jest skonfigurowany do korzystania z TLS tylko wtedy, gdy TLS jest dostępny, i korzystania z tekstu jawnego, gdy TLS nie jest dostępny, klient może najpierw spróbować połączyć się z portem SSL używanym przez protokół, a jeśli to kończy się niepowodzeniem, a następnie połącz się z portem czystego tekstu i spróbuj użyć STARTTLS, a na koniec wróć do zwykłego tekstu, jeśli TLS nie jest dostępny w obu przypadkach. Atakujący może dość łatwo spowodować awarię połączenia z portem SSL (wystarczy kilka pakietów TCP RST w odpowiednim czasie lub zablokowanie portu SSL). Atakującemu jest nieco trudniej - ale tylko trochę - pokonanie negocjacji STARTTLS i sprawienie, że ruch pozostanie czysty. A wtedy atakujący nie tylko przeczyta Twój e-mail, ale także przechwyci Twoją nazwę użytkownika / hasło do wykorzystania w przyszłości.

Tak więc prosta odpowiedź brzmi: jeśli łączysz się z serwerem, o którym wiesz, że obsługuje TLS (tak jak powinno być w przypadku wysyłania lub czytania wiadomości e-mail), powinieneś użyć SSL / TLS. Jeśli połączenie zostanie zaatakowane, próba połączenia nie powiedzie się, ale hasło i adres e-mail nie zostaną naruszone.

Z drugiej strony, jeśli łączysz się z jakąś usługą, której nie wiesz, czy obsługuje ona TLS, STARTTLS może być nieznacznie lepszy.

Kiedy wynaleziono STARTTLS, ataki „pasywne” polegające na nasłuchiwaniu były bardzo powszechne, rzadziej występowały „aktywne” ataki, w których atakujący wprowadzał ruch w celu obniżenia bezpieczeństwa. W ciągu około 20 lat od tego czasu aktywne ataki stały się bardziej wykonalne i powszechne.

Na przykład, jeśli próbujesz użyć laptopa na lotnisku lub w innym miejscu publicznym i próbujesz czytać pocztę za pośrednictwem dostępnego tam Wi-Fi, nie masz pojęcia, co ta sieć Wi-Fi robi z twoim ruchem. Sieci Wi-Fi często kierują określone rodzaje ruchu do „serwerów proxy”, które pośredniczą między aplikacjami klienckimi a serwerami, z którymi próbują rozmawiać. Wyłączenie przez te serwery proxy zarówno STARTTLS, jak i „wypróbuj jeden port, a potem drugi” jest banalne, aby skłonić klienta do powrotu do tekstu jawnego. Tak, dzieje się tak i jest to tylko jeden przykład tego, jak sieć może szpiegować Twój ruch. I takie ataki nie ograniczają się do trzyliterowych agencji wspieranych przez państwo,

Tak, masz podstawy. I tak, STARTTLS jest zdecydowanie mniej bezpieczny. Może nie tylko wrócić do zwykłego tekstu bez powiadomienia, ale także dlatego, że podlega atakom typu man-in-the-middle. Ponieważ połączenie rozpoczyna się od razu, MitM może usunąć polecenie STARTTLS i zapobiec szyfrowaniu. Uważam jednak, że serwery pocztowe mogą określić, że transfery mają miejsce tylko po skonfigurowaniu szyfrowanego tunelu. Możesz więc obejść ten problem.

Dlaczego więc coś takiego istnieje? Ze względu na kompatybilność. Jeśli którakolwiek ze stron nie obsługuje szyfrowania, nadal możesz chcieć, aby połączenie zostało poprawnie wykonane.

Zgadzam się z @Greg. Te ataki są możliwe. Jednak MTA można skonfigurować (w zależności od MTA) do używania „obowiązkowego TLS”, a nie „oportunistycznego TLS”. Oznacza to, że TLS i tylko TLS są używane (dotyczy to również STARTTLS) do transakcji e-mail. Jeśli zdalne MTA nie obsługuje STARTTLS, wiadomość e-mail jest odsyłana.

Nie, to nie mniej bezpieczne, kiedy twoi Obsługuje aplikacje poprawnie.

Istnieją cztery sposoby obsługi TLS, a wiele programów pozwala wybrać:

• Brak TLS
• TLS na dedykowanym porcie (tylko próbuje TLS)
• Użyj TLS, jeśli jest dostępny (Próbuje starttls, używa połączenia niezaszyfrowanego, gdy się nie powiedzie)
• Zawsze używaj TLS (używa starttlsi kończy się niepowodzeniem, jeśli nie działa)

Zaletą TLS na dedykowanym porcie jest to, że możesz mieć pewność, że nie wystąpi awaria, gdy korzystasz z programu, którego jeszcze nie znasz lub który nie ujawnia szczegółowych ustawień obsługi błędów w swoim kreatorze przy pierwszym uruchomieniu.

Ale ogólnie bezpieczeństwo zależy od obsługi błędów bezpieczeństwa. Program może zdecydować o przełączeniu na port tekstu jawnego, gdy TLS na porcie TLS również zawiedzie. Musisz wiedzieć, co to zrobi, i wybrać bezpieczne ustawienia. I programy powinny używać bezpiecznych ustawień domyślnych.