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

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?

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.

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.

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.

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.

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ść.

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.

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).