Czy STARTTLS jest mniej bezpieczny niż TLS / SSL?

45

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?

Bar Foo
źródło

Odpowiedzi:

46

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 .

Greg
źródło
5
Twój punkt jest z pewnością prawidłowy, ale z powodu braku jakiejkolwiek specyfikacji RFC lub oficjalnej specyfikacji dotyczącej SMTPS (tj. SMTP + „domyślny SSL / TLS”, w którym najpierw ustanowiono SSL / TLS), klienci SMTP / SMTPS mogą również zdecydować się na powrót do zwykłego połączenia jeśli nie są w stanie zainicjować połączenia SSL / TLS na porcie 465. Nadal jest to wyłącznie wybór implementacji.
Bruno,
2
Istnieje wiele specyfikacji RFC do nawiązywania połączeń TLS. Nigdzie nie ma opcji „zezwalaj na połączenie tekstowe” jako opcji na zgodność z RFC (przynajmniej byłoby to nowością dla wielu osób). Tak więc SMTPS nie wymaga oddzielnego RFC, aby był bardziej bezpieczny niż STARTTLS.
Greg
1
Istnieją RFC dotyczące TLS (RFC 5246 i poprzedników), PKI (RFC 5280), weryfikacji nazwy (RFC 6125), ale nie ma nic, co mogłoby opisać interakcję między SMTP i SSL / TLS w SMTPS oficjalnie AFAIK, nie w ten sam sposób, w jaki otrzymujesz specyfikacja dla HTTPS: RFC 2818. Można powiedzieć: „to oczywiste, wystarczy najpierw nawiązać połączenie SSL / TLS”, ale nie wszystko w tym jest oczywiste (w szczególności aspekt weryfikacji tożsamości, sformalizowany całkiem niedawno w RFC 6125).
Bruno,
23

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.

długa szyja
źródło
2
Jeśli połączenie jest szyfrowane, zarówno SSL / TLS, jak i STARTTLS są takie same, tak. Ale nie o to prosiłem. Miałem na myśli: jeśli korzystam z STARTTLS, to skąd (jako użytkownik) mogę wiedzieć, czy moje połączenie jest naprawdę bezpieczne? Jeśli spróbuję użyć protokołu SSL / TLS, nie mogę się połączyć, jeśli serwer go nie obsługuje, ale przynajmniej nic nie jest wysyłane jako zwykły tekst. Ale jeśli STARTTLS powróci do zwykłego tekstu, wtedy moja poczta zostanie wysłana w postaci zwykłego tekstu, bez mojej wiedzy, że została wysłana w postaci zwykłego tekstu (co sprawia, że ​​myślę, że jestem bezpieczny, gdy tak naprawdę nie jestem).
Foo Bar,
6
Nie wiem, dlaczego ta odpowiedź została wybrana jako poprawna. To jest źle. Jak podkreśla Christopher, STARTTLS jest mniej bezpieczny niż TLS, ponieważ daje fałszywe poczucie bezpieczeństwa klientom.
Greg
4
@greg nie ma nic złego w protokole. Wadą są klienci, którzy nie postępują zgodnie z RFC i nie ostrzegają użytkownika, gdy połączenie nie jest szyfrowane.
longneck
1
@longneck, więc ... może jest to kwestia semantyki, ale klienci nie mogą „nie przestrzegać” protokołu TLS i wysłać e-maila, kropka. to znacząca różnica.
Greg
2
@Bruno „To jest tylko mniej bezpieczne, jeśli klient jest źle zaimplementowany” <= po prostu robisz mój punkt za mnie. Jeśli klient może coś zrobić, aby połączenie było niepewne podczas nawiązywania działającego połączenia, wówczas STARTTLS jest mniej bezpieczny niż jawny TLS (jeśli nie jest to możliwe).
Greg
8

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)

janneb
źródło
4

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,

Keith Moore
źródło
1

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.

Christopher Karel
źródło
Tak więc serwer obsługujący STARTTLS zawsze będzie również mógł obsługiwać SSL / TLS, prawda? Więc zawsze lepiej najpierw wypróbować SSL / TLS i sprawdzić, czy to działa?
Foo Bar
2
@ FooBar nie, jeden nie oznacza, że ​​drugi jest dostępny. w rzeczywistości mogą być skonfigurowane z zupełnie innymi domenami uwierzytelniania.
longneck
3
STARTTLS nie jest wrażliwy na MitM, chyba że nie zweryfikujesz certyfikatów lub nie użyjesz słabych. Certyfikat jest nadal prezentowany tak samo jak zawsze, a klient może wymagać pomyślnego uaktualnienia TLS przed kontynuowaniem. Warto zauważyć, że jest to dokładnie ta sama sytuacja, co SSL / TLS.
Falcon Momot,
1
Nie wiem, dlaczego ludzie cię głosują, to poprawna odpowiedź, STARTTLS jest mniej bezpieczny niż TLS i daje fałszywe poczucie bezpieczeństwa. Dostawcy usług internetowych mogą to zrobić: arstechnica.com/tech-policy/2014/11/…
Greg
1
Jeśli chodzi o sam protokół, STARTTLS jest mniej bezpieczny niż TLS, ponieważ wyraźnie pozwala na komunikację tekstową bez ostrzeżenia dla użytkownika: serverfault.com/a/648282/207987
Greg
1

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.

gixxer
źródło
0

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.

allo
źródło