Dlaczego przelewy e-mail między serwerami pocztowymi często nie są szyfrowane?

Użytkownicy często decydują, czy chcą uzyskać dostęp do swojego dostawcy poczty e-mail (takiego jak Gmail) za pomocą bezpiecznego kanału (np. HTTPS).

Jednak, zgodnie z moją najlepszą wiedzą, jeśli chodzi o komunikację między serwerem pocztowym a serwerem pocztowym, większość wiadomości e-mail jest nadal przesyłana zwykłym tekstem i nie jest szyfrowana, co umożliwia każdemu w sieci odczytanie ich treści.

Czy są jakieś technologie, które dają użytkownikowi pewne gwarancje, że jego e-maile są wysyłane bezpiecznie od końca do końca? Dlaczego nie poinformować użytkownika, gdy szyfrowanie nie jest obsługiwane, i pozwolić mu wybrać, czy chce, aby jego poczta nadal była dostarczana?

Jednak, zgodnie z moją najlepszą wiedzą, jeśli chodzi o komunikację między serwerem pocztowym a serwerem pocztowym, większość wiadomości e-mail jest nadal przesyłana zwykłym tekstem i nie jest szyfrowana, co umożliwia każdemu w sieci odczytanie ich treści.

Poprawny. SMTP, podobnie jak HTTP, jest domyślnie zwykłym tekstem.

Obecnie wiele serwerów poczty obsługuje protokół TLS (wcześniej znany jako SSL) dla SMTP. (Dotyczy to Gmaila.) Jednakże, to ma takie same problemy jak w przypadku HTTP [S]: certyfikaty wydane przez znanego CA pieniędzy kosztów i te autopodpisywane są bezwartościowe ¹ do ochrony przed atakami MiTM . Jeśli Twój serwer pocztowy dokonuje ścisłej weryfikacji certyfikatu odbiorcy (podobnie jak przeglądarki internetowe), może nie dostarczyć wiadomości do serwerów, które używają certyfikatów z podpisem własnym lub wewnętrznych urzędów certyfikacji. Jeśli nie , to nie ma pewności, że rozmawia z właściwym serwerem, a nie z oszustem .

Ponadto TLS jest stosunkowo nowym dodatkiem do SMTP, więc nawet jeśli serwer poczty odbiorcy obsługuje TLS, nadawca może nie, lub może być domyślnie wyłączony.

¹ (O ile serwer wysyłający nie obsługuje DANE (TLSA), a administrator serwera odbierającego chce opublikować rekordy TLSA w DNS. Jest to rzadko wykonywane i nieco żmudne).

Czy są jakieś technologie, które dają użytkownikowi pewne gwarancje, że jego e-maile są wysyłane bezpiecznie od końca do końca?

Dwa najczęstsze standardy bezpieczeństwa poczty e-mail:

• OpenPGP , oparty na sieci zaufania i darmowy. Implementacja typu open source to GnuPG ( dla Windows , dla Thunderbirda ), a oryginalny PGP ewoluował w komercyjny pulpit PGP .

  Dla internetowych klientów poczty e-mail FireGPG jest możliwością - do cholery

• S / MIME , oparty na infrastrukturze X.509. Zaimplementowane przez większość klientów stacjonarnych (w tym Outlook, Thunderbird, Mail.app). Jednak stosunkowo mało popularny ze względu na tę samą strukturę opartą na uprawnieniach jak TLS / SSL: podpisane certyfikaty kosztują pieniądze, a samopodpisanych certyfikatów nie można wiarygodnie zweryfikować.

W obu przypadkach szyfrowanie wymaga, aby odbiorca już korzystał z systemu i wygenerował / uzyskał parę kluczy. (W przypadku podpisania tego, nadawcy jest używany parę kluczy. Normalną praktyką jest zarówno znakiem i szyfrowania wiadomości.)

Dlaczego nie poinformować użytkownika, gdy szyfrowanie nie jest obsługiwane, i pozwolić mu wybrać, czy chce, aby jego poczta nadal była dostarczana?

Zwykle przesłane wiadomości są umieszczane w kolejce i ani użytkownik, ani MTA nie mogą wiedzieć, czy następny przeskok obsługuje TLS, czy nie - do momentu wysłania komunikatu , w którym to momencie nie ma niezawodnego sposobu, aby poprosić użytkownika o potwierdzenie. (Mogą to być AFK, offline, śpiący lub skrypt / program. Jeśli wysłałem wiadomość, chcę, aby została dostarczona jak najszybciej.)

Poza tym dzięki SMTP nigdy nie wiadomo, czy następny przeskok jest końcowy, czy po prostu przekaże pocztę gdzie indziej. Często zdarza się, że zapasowy MX znajduje się w zupełnie innej sieci.

W związku z tym. kompleksowe bezpieczeństwo jest możliwe tylko wtedy, gdy obie strony korzystają z OpenPGP lub S / MIME.

Rzeczywisty ruch e-mail jest często szyfrowany (TLS), ale istnieje kilka innych problemów:

• Niektóre klienty poczty internetowej, które wyświetlają wiadomości HTML, mogą być niepewne, chociaż używają HTTPS, na przykład nie ma wyraźnej separacji między kodem a danymi w HTML (elementy wizualne i javascript -> ataki iniekcyjne)

  • webmail przechowuje również wiadomości e-mail na serwerze zamiast pobierać je i przechowywać na komputerze lokalnym

• Nie masz możliwości dowiedzenia się, czy TLS / SSL był używany między każdym krokiem, bardzo małe serwery NIE MAJĄ odpowiednich certyfikatów

  • nadawca powinien mieć przynajmniej możliwość określenia, czy przyjąć czy nie wysłać wiadomości e-mail za pomocą niezabezpieczonego kanału

• Wiadomości e-mail leżą na serwerach niezaszyfrowanych lub zaszyfrowanych przez serwer

  • będziesz musiał zaufać KAŻDEMU serwerowi między tobą a odbiorcą

• E-maile mogą być przesyłane dowolną trasą, nie możesz określić, którym serwerom ufasz (zakresy adresów IP, AS, kraje, domeny ...)

• Duże serwery e-mail nie używają wielu różnych certyfikatów i nie zmieniają ich wystarczająco często (?)

  • być może warto / można je brutalnie zmusić (jak próbowały to USA / Wielka Brytania?)

• śledząc ruch, wiedzą, kiedy wiadomość e-mail została wysłana, i coś o odbiorcy (które serwery komunikują się między sobą)

  • sieci ciemne ukrywają te korelacje

• Implementacja openssl była / jest bałaganem

  • mogą być błędy

• musisz zaufać urzędom certyfikacji podpisującym certyfikaty

Oni są. Lub bardzo często są.

Przez SSL lub TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Lub jeśli jesteś naprawdę paranoikiem, jest PGP lub GPG.