Czy wymuszanie szyfrowania SMTP to dobry pomysł (jeszcze)?


36

Korzystam z serwera e-mail, który jest skonfigurowany do korzystania z TLS, jeśli to możliwe, podczas wysyłania i odbierania wiadomości e-mail.

Kiedy czytasz w dokumentacji na ten temat, istnieje również możliwość wymuszenia TLS i nieakceptowania transmisji wiadomości e-mail w postaci zwykłego tekstu. Ostrzega również, że niektóre serwery pocztowe mogą jeszcze nie obsługiwać szyfrowania, a wymuszenie szyfrowania może zablokować te serwery.

Ale czy to wciąż kwestia, o której należy pomyśleć, czy też można śmiało powiedzieć, że wymuszanie szyfrowania nie będzie już problemem?

Czy jest może jakiś duży dostawca, który już to robi lub jakie są obecnie najlepsze praktyki?

Odpowiedzi:


34

Praktyczny problem polega na tym, że nie każdy serwer zgodny z SMTP (RFC jest dość stary) może przesyłać TLS do twojego serwera, więc możesz przegapić otrzymywanie niektórych wiadomości e-mail.

Problem filozoficzny polega na tym, że nie można powiedzieć, w jaki sposób wiadomość e-mail jest przekazywana po (lub wcześniej) po dostarczeniu na serwer.

Oznacza to, że wiadomość e-mail mogła już zostać przesłana w postaci zwykłego tekstu za pośrednictwem przekaźnika.

Każdy, kto poważnie myśli o ochronie treści swoich wiadomości e-mail, powinien zaszyfrować ciało. Dzięki szyfrowaniu w drodze jest zawsze możliwe, że został już przesłany w postaci zwykłego tekstu.

Tak więc odpowiedź na pytanie wymuszanie szyfrowania w warstwie SMTP jest prawdopodobnie bezcelowe, zwiększa szansę na brak wiadomości e-mail i nie ma żadnej gwarantowanej korzystnej korzyści.

Edycja: Odnosi się do wymuszania SMTP w celu przekazywania, a nie przesyłania wiadomości e-mail. W przesyłanych wiadomościach należy wymusić szyfrowanie, ponieważ rozmowa SMTP (nie rzeczywista wiadomość e-mail) może zawierać dane uwierzytelniające.


7
Nie sądzę, że to najlepsza odpowiedź. Dochodzi do właściwego wniosku, ale z niewłaściwych powodów. To „pozwalanie, aby doskonały był wrogiem dobrego” rozumowania. Myślę, że lepszą odpowiedzią jest to, że jeśli potrzebujesz szyfrowania, uniemożliwisz dostęp do niektórych wiarygodnych wiadomości e-mail (ponieważ niektóre serwery SMTP nie mogą szyfrować). Gdyby nie ten czynnik, wymuszenie szyfrowania byłoby korzystne, mimo że z wszystkich wymienionych powodów nie jest idealne - byłoby lepsze niż nic, nawet jeśli nie jest idealne.
DW

Nie zgadzam się co do doskonałości przez zwykłe dodanie subfekcji; wciąż przesłałem edycję odpowiedzi, aby podkreślić możliwą techniczną niezgodność serwerów zgodnych z RFC, ale nie obsługujących TLS.
Alex Mazzariol,

Dzięki za odpowiedź! Na początku nie myślałem o tym, co stanie się po tym, jak mój serwer wysłał pocztę na następny serwer lub, jak powiedziałeś, gdzie wiadomość „już była”, zanim do mnie dotarła. Oczywiście nie ma sensu wymuszanie szyfrowania, jeśli strona odbierająca wysyła go w postaci zwykłego tekstu (może do podserwera tej samej firmy, ale nadal przez Internet).
comfreak

Wybrałem tę odpowiedź jako zaakceptowaną, ponieważ wyjaśnia ona najlepiej, że wymuszanie szyfrowania na moim serwerze nie gwarantuje bezpiecznego / zaszyfrowanego transferu wiadomości od nadawcy do odbiorcy, ale tylko z mojego serwera do następnego.
comfreak

Myślę, że ta odpowiedź jest dobra, ale nie wspomina, że ​​szyfrowanie jest nadal pożądane, biorąc pod uwagę, że tylko w ograniczonej liczbie przypadków ktoś dołożył wszelkich starań, aby przechwycić czystą wiadomość tekstową nadawcy, aby cię oszukać. Jeśli ukrywasz się przed CIA / NSA, na pewno może ci to nie pomóc. Ale co byłoby lepszego, wymuszając szyfrowanie, aby nikt z wyraźnym zainteresowaniem nie przeczytał / nie przechwycił wiadomości nadawcy i ukrył ją, dopóki osoba trzecia nie zdecyduje się na próbę włamania się na ciebie lub przechowywanie wszystkich wiadomości na serwerach NSA, aby pewnego dnia mogą nie tylko zacząć ...
momomo

20

Nie

RFC 821 ma 33 lata. Ci będzie znaleźć e-maile przekazywane przez programy notsupporting STARTTLS. Czasami będą to pośrednicy wysyłający wiadomości e-mail (np. Wewnętrzne skrypty), czasem pełne systemy, które są stare, mają wyłączony / nieskompilowany TLS, systemy bez wystarczającej entropii…

Nie tak dawno temu widziałem, że wychodzące wiadomości e-mail zawodzą, ponieważ odbiorca skonfigurował go tak, aby zezwalał tylko na SMTP przez TLS. Był to problem ze strony nadawcy (nie powinien był używać tej konfiguracji), ale pokazuje, że tak się dzieje.

Ograniczałbym tylko wiadomości przychodzące z ręcznie skonfigurowanych adresów IP. Jeśli procesor karty kredytowej nie uruchomi STARTTLS, prawdopodobnie wolisz przerwać połączenie (i wezwać lokalnego administratora, aby mógł ich ostrzec!), Niż odbierać (potencjalnie wrażliwe) dane niezaszyfrowane. W przypadku wiadomości wychodzących, jeśli wcześniej łączyłeś się z tym hostem za pomocą STARTTLS, możesz nie chcieć robić tego niepewnie, traktując to jako potencjalny kompromis. Możesz także mieć listę hostów STARTTLS, o których zawsze wiadomo, że są w użyciu, takich jak Gmail lub Yahoo.

Istnieje https://www.eff.org/starttls-everywhere projekt zapewniający listę serwerów smtp, dla których możesz (powinieneś?) Z pewnością egzekwować użycie starttls.


3
Dziękujemy za odpowiedź i opublikowanie tego linku! To wydaje się być dobrym podejściem do rozwiązania problemu ataku typu man-in-the-middle obniżającego połączenie do niezaszyfrowanej rozmowy.
comfreak

11

Odrzucanie wiadomości e-mail od rówieśników niezdolnych do szyfrowania jest całkowicie bezcelowe i prawdopodobnie czynnie szkodliwe.

Tak długo, jak twój serwer jest skonfigurowany do szyfrowania oportunistycznego z każdym równorzędnym, który go oferuje, masz to, co najlepsze z obu światów: szyfrowanie, gdy jest dostępne, i wysyłanie wiadomości e-mail przez zwykły tekst, gdy nie jest.

Tak długo, jak istnieją serwery, które nie obsługują szyfrowania, nakazanie go po prostu oznacza, że ​​nie mogą z tobą rozmawiać; to źle. Gdy wszyscy go poprą, nie będzie już różnicy między szyfrowaniem oportunistycznym a obowiązkowym.

I, jak zauważyli inni, szyfrowanie bezpośrednie i szyfrowanie od końca do końca to dwie zupełnie różne rzeczy, odnoszące się do różnych modeli zagrożeń. Nie pomyl tych dwóch.


Twierdziłbym, że najlepsze z obu światów pozwoliłyby również zobaczyć różnicę, podobną do „blokady” strony SSL w sieci, więc wiesz, które e-maile * zostałyby zablokowane, gdybyś wymusił TLS
2813274

@ user2813274 Zgadzam się i zgadza się. Sprawdź swoje nagłówki; pokażą Ci, czy dany etap łańcucha transmisji został wykonany z szyfrowaniem, czy bez.
MadHatter obsługuje Monikę

@MadHatter, chyba że te nagłówki zostały całkowicie wykute przez chmiel przed twoim.
thrig

8
Jest to różnica między szyfrowaniem oportunistyczne i obowiązkowy. Często aktywny MITM może zakłócać szyfrowanie oportunistyczne, powodując, że punkty końcowe cofają się do braku szyfrowania, które można monitorować. W przypadku obowiązkowego szyfrowania połączenie zostanie zerwane, co spowoduje odmowę usługi, ale nie naruszenie prywatności.
cjm

4
@cjm stąd mój punkt widzenia na temat modeli zagrożeń. Jeśli poważnie próbujesz się bronić przed atakami MITM, pomocne może być tylko szyfrowanie kompleksowe. Poleganie na samym szyfrowaniu SMTP jest bezcelowe; wyrafinowany MITM po prostu podszywa się pod twój serwer, a następnie po przeczytaniu przekazuje ci pocztę. Jasne, twój serwer może mieć poprawnie podpisany certyfikat (co jest zaskakująco rzadkie), ale nie możesz kontrolować, czy system wysyła do ciebie tego wymaga , więc taki atak MITM zakończy się sukcesem, pomimo spełnienia jakichkolwiek wymagań dotyczących szyfrowanego połączenia .
MadHatter obsługuje Monikę

10

To kwestia polityki.

Zasadniczo, gdy TLS jest wymuszane dla ruchu przychodzącego i wychodzącego, dzieje się tak w przypadku ograniczonego zestawu domen, które są uzgadniane przez strony w celu spełnienia potrzeby (na przykład partnerzy biznesowi mogą mieć umowę na szyfrowanie całej poczty między swoimi firmami).

Jeśli taka umowa nie obowiązuje, nie włączaj trybu egzekwowania.


2

Nie, to bardzo zły pomysł.

W rzeczywistości, jak się okazuje, większość serwerów / klientów STARTTLS nie implementuje żadnego algorytmu ponownej próby bez StartTLS w przypadku niepowodzenia negocjacji połączenia TLS.

Jako takie, nawet reklamowanie STARTTLS jako opcji już zmniejsza twoje szanse na otrzymywanie (i wysyłanie) e-maili!

Wystarczy wyszukać, a zobaczysz, że wiele osób nie może wysłać ŻADNEGO e-maila do domen Microsoft Outlook obsługiwanych przez klaster * .protection.outlook.com:

Wiadomości Sendmail odrzucone przez Microsoft podczas korzystania z TLS

powód: 403 4.7.0 Uzgadnianie TLS nie powiodło się

Podsumowując problemy przedstawione w dwóch powyższych postach:

  • może wysyłać dowolną pocztę do dowolnego hosta innego niż obsługiwany przez program Outlook, z STARTTLS lub bez,
  • może wysyłać pocztę bez certyfikatu klienta i bez STARTTLS do programu Outlook,
  • lub z certyfikatem klienta o zerowej długości,
  • ale nie z certyfikatem, którego Microsoft nie lubi, aw przypadku awarii klienci (cóż, serwery działające w trybie klienta) nie próbują ponownie wysłać wiadomości bez STARTTLS, jeśli serwer odbiorcy reklamuje STARTTLS!

Podobnie, gdy host działa jako serwer, podobna sytuacja może wystąpić poza twoją kontrolą, jeśli zdecydujesz się włączyć STARTTLS - gdy serwer klienta zobaczy, że twój serwer w trybie serwera oferuje STARTTLS, spróbuje negocjować TLS, ale jeśli negocjacja się nie powiedzie , po prostu czekają i ponawiają te same kroki, nie udaje się, dopóki wiadomość nie zostanie odesłana do nadawcy!

I zdarza się to dość często w przypadku różnych domen w krainie STARTTLS!

Niestety, o ile w przeszłości byłem zwolennikiem STARTTLS, teraz jestem bardzo pozbawiony praw wyborczych, że wprowadzono mnie w błąd, jeśli reklama pozbawiona ryzyka była moim zdaniem szyfrowaniem oportunistycznym.

Nie tylko nie powinieneś wymagać STARTTLS, ale nawet rozsądne może być całkowite wyłączenie go, jeśli chcesz zapewnić interoperacyjność.


2

Muszę zgodzić się na pomysł użycia oportunistycznego TLS. Chociaż mam też coś do dodania do pomysłu. Sugestie prawdopodobnie będą niepokojące dla niektórych, ponieważ moje sugestie nie zostały przedstawione lekko i bez należytego rozpatrzenia, przed wydaniem wyroku proszę o przeczytanie pełnej dyskusji z załączonego linku.

Korzystanie z oportunistycznego TLS jest zdecydowanie najlepszym rozwiązaniem. Kąt MITM jako argument przeciwko niemu jest czerwonym śledziem. W końcu, jak wspomniano w komentarzu MH, nawet „legalny” SMTP z połączeniem TLS może być MITM'd, a użytkownik końcowy jest mądrzejszy, ponieważ zdecydowana większość klientów pocztowych nie zawraca sobie głowy sprawdzaniem certyfikatów w połączeniu z ogromną większością MTA, które tam robią TLS, używają samopodpisanych certyfikatów (przynajmniej jeśli nie używasz DNSSEC i TLSA / DANE). W wyniku tego i być może innych czynników można nawet argumentować, że dopóki ty i reszta świata zaimplementował DANE / TLSA i DNSSEC, że przy korzystaniu z oportunistycznego TLS lepiej jest nie włączać również anonimowego diffie-hellman (przy użyciu PFS). Wynika to przynajmniej częściowo, jeśli nie głównie z faktu, że nadal będzie szyfrował ruch, chroniąc przed przypadkowym obserwatorem. W celu dalszego wsparcia tej konfiguracji (ze znacznie bardziej skomplikowanym wyjaśnieniem niż moje) zapoznaj się z komentarzami Viktora Dukhovniego w tym poście na forum postfiksowym:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Co do tego, dlaczego ktoś może przesuwać sugestie Viktora nad innymi, cóż, napisał kod TLS, a także kod DNSSEC, TLSA / DANE dla Postfix MTA, oprócz tego, że napisał wersje robocze IETF na obu DNSSEC i TLSA / DANE. Jako taki powiedziałbym, że jego słowa w tej sprawie mają spore znaczenie, prawdopodobnie więcej niż większość.

Mam nadzieję że to pomoże.


0

Z punktu widzenia marketingu e-mailowego stosowanie TLS jest dobrą praktyką i bezpieczne, gdy wiesz, że jest ono wdrażane przez cały łańcuch dostaw. Jeśli jednak bezpieczeństwo jest Twoim najwyższym wymaganiem, szyfrowanie wiadomości e-mail przed wysłaniem jest najbezpieczniejszą opcją (na przykład w PGP).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.