Co musisz wiedzieć o używaniu SSL/TLS do szyfrowania połączeń wykonywanych przez twoje serwery pocztowe

Gdy zwrócono się do mnie
z tematem tego wpisu na blogu, chętnie się zgodziłem. Oto parafraza
tego, jak to się odbyło:

„Czy byłbyś w stanie
napisać post o znaczeniu TLS w serwerach poczty elektronicznej?” zapytał Patrick.

„Jasne,” odpowiedziałem.

Whew, to była szalona
rozmowa do ponownego przeżycia! Jak wicher!

Potem zacząłem myśleć o tym przez chwilę. Czy naprawdę są tam serwery pocztowe, które nie używają szyfrowania do tranzytu? Nie mówię tu o szyfrowaniu end-to-end, o którym pisaliśmy w przeszłości (S/MIME, PGP, itp.). Odnoszę się do szyfrowania od serwera do serwera lub wszystkiego pomiędzy, aby chronić dane wzdłuż trasy.

Zapewne, w tym dniu i wieku, nikt nie zostawiłby swojej przychodzącej/wychodzącej poczty w plaintext przemierzającej Bóg wie jaką trasę, aby być przechwyconym i wykorzystanym. Wiele osób korzysta z usług poczty elektronicznej i nie ma mowy, żeby wykluczały one szyfrowanie tranzytu ze swoich usług. Naruszenia danych kosztują ich miliony w
pozwach sądowych, utratę biznesu i wstyd……Hmmmm…..

Powróciłem do Patricka
z pytaniem.

„Czy mamy statystyki
lub informacje o serwerach pocztowych nie używających szyfrowania? Zgaduję, że byłyby one
niskie. Innymi słowy, co skłoniło Cię do zapytania mnie o ten artykuł?”

Patrick odpowiedział: „I
actually don’t. Pomyślałem, że byłby to dobry temat, biorąc pod uwagę znaczenie
poczty elektronicznej i wszystkich aspektów potrzebnych do zapewnienia bezpieczeństwa.”

OK. To ma sens. Tam prawdopodobnie są niektóre serwery pocztowe tam nie używając go w ogóle, choć niewątpliwie znacznie większy odsetek może być przy użyciu nieaktualnych protokołów lub wygasłych certs i może po prostu potrzebują odświeżenia.

Ten artykuł przejdzie
przez gdzie jesteśmy z email i szyfrowanie tranzytu, aby upewnić się, że jesteś
operujący na optymalnym poziomie bezpieczeństwa, który jest dostępny.

Szyfrowanie w serwerach email

W tym momencie, prawdopodobnie mamy ogólne zrozumienie jak działa TLS, ale podsumujmy na wypadek gdybyś był w tym nowy.

Osoba A chce wysłać
bezpieczną komunikację z człowiekiem B. Osoba A i człowiek B mają wcześniej ustalony
certyfikat. Osoba A używa certyfikatu do zaszyfrowania informacji i wysyła
zaszyfrowaną informację do człowieka B. Informacja jest nieczytelna, dopóki człowiek
B nie użyje certyfikatu do odszyfrowania zaszyfrowanej informacji.

Jeśli Człowiek B chce
odpowiedzieć Osobie A zaszyfrowaną informacją, wtedy Człowiek B użyłby
certyfikatu do zaszyfrowania danych, a Osoba A użyłaby certyfikatu do
odszyfrowania wiadomości.

To jest ogólnie jak
szyfrowanie/deszyfrowanie działa. Teraz zamień ludzi wymienionych w tym przykładzie na
serwery i inne tego typu połączenia. Ta sama koncepcja.

Now if Human B wants to respond back to Person A with encrypted information, then Human B uses the symmetric key that was just generated and they can now both encrypt and send, and receive and decrypt data to one another.

Tak generalnie działa szyfrowanie/deszyfrowanie za pomocą SSL/TLS. Teraz zamień osoby wymienione w tym przykładzie na serwery i inne tego typu połączenia. Same concept. To jest jak TLS działa z e-mail, który jest nieco inny niż jak ułatwia połączenie HTTPS ze względu na fakt, że e-mail używa innych protokołów. Ale, nadal istnieją pewne wyraźne podobieństwa:

• Handshake występuje
• Uwierzytelnianie występuje (choć obie strony uwierzytelniają w tym kontekście)
• Klucze sesji są używane do przekazywania przepływu e-maili.

Ebb i (Mail) Flow

Kolejnym krokiem do tego
„zrozumienie dlaczego do” artykuł jest „zrozumienie jak” część.

W skrócie, klient poczty e-mail wysyła wiadomość e-mail do serwera wychodzącego. Serwer wychodzący zrobi DNS look up, w oparciu o docelowej domeny e-mail, i że DNS w MX rekord określi, który serwer wysłać e-mail i, ewentualnie, że serwer określi, czy musi być przekazywane dalej, aż trafia do docelowej skrzynki odbiorczej Mail Delivery Agent (MDA).

Nie wystarczy
zaufać rekordom DNS MX, co jest zupełnie inną kwestią zaufania zupełnie, ale serwer SMTP
(poczta wychodząca, MTA, etc) i poczta przychodząca (przez POP3, IMAP,
Exchange) muszą być w stanie zidentyfikować siebie nawzajem i mieć właściwe klucze do
komunikacji ze sobą. I, w zależności od trasy, nie może być więcej
niż tylko jeden-ish hop komunikacji serwera poczty elektronicznej. Wymienniki poczty, proxy
serwery i inne mogą być w miejscu wzdłuż trasy. Każdy skok (powinien) wezwać do
szyfrowanego połączenia. Często tak się dzieje. Czasami, to nie robi. Użytkownicy
preferują, aby wrażliwe informacje były szyfrowane wzdłuż trasy. End-to-End encryption
helps assure that there is some sort of encryption the whole way through but
layers of security are always, uh, better.

Respect Thy Securi-Tie

Dla wiadomości,
Securi-Tie nie jest prawdziwym słowem. Wymyśliłem to słowo tylko dlatego, że się rymowało. To
zabawa słowem bezpieczeństwo.

Aby odskoczyć
od poprzedniej sekcji, powinniśmy porozmawiać o opcjach bezpieczeństwa, które, podczas gdy
byłyby ustawiane od strony klienta, w rzeczywistości dostarczałyby pewnych instrukcji
do strony serwera pocztowego dla celów związanych z bezpieczeństwem.

Podczas konfigurowania klienta
poczty elektronicznej (Outlook, Thunderbird, etc), domyślną konfiguracją jest konfiguracja bez szyfrowania
. Ale, jak jest punkt tego artykułu, zazwyczaj chcemy iść
do opcji szyfrowanej. W pewnym sensie, nie jest to całkowicie zależne od klienta: to
zależy od tego, co strona serwera jest w stanie obsłużyć. Zakładając, że Twoje serwery przychodzące
i wychodzące mogą obsługiwać szyfrowanie, dlaczego miałbyś tego nie robić? Jeśli zamawiasz
stek w restauracji i oferują Ci polędwicę do wyboru lub Kobe(wagyu) ribeye
w tej samej cenie, dlaczego nie zamówisz kawałka lepszej jakości?

Więc, jeśli chcesz użyć
TLS/SSL w swoim emailu (to jest dla części tranzytowej, a nie części end-to-end,
S/MIME, która jest omawiana w innych postach na blogu), włącz to. Użyj portów 465
lub 587 dla SMTP (’member, outbound mail) i 993 (IMAP) lub 995 (POP3) dla
inbound traffic.

Istnieje
ciekawy protokół szyfrowania, który jest nadal używany wśród serwerów poczty elektronicznej. It
has its good with bad as is such with most things. Ostatecznie powiedziałbym, że
jego intencje są dobre, ale zastosowanie w świecie rzeczywistym nie jest do końca idealne jak
mógłby. Panie i Panowie, tym protokołem jest STARTTLS.

STARTTLS jest protokołem bezpieczeństwa
, który w zasadzie jest SSL/TLS. Całkiem po prostu, STARTTLS weźmie
istniejący plaintext, a więc niezabezpieczone połączenie i spróbuje przekształcić
je w bezpieczne połączenie używając TLS (lub SSL). Tak więc, poziom bezpieczeństwa
STARTTLS vs SSL/TLS w rzeczywistości nie różni się. Jeśli wszystko jest ustawione prawidłowo, oba
będą szyfrować informacje używając TLS (lub SSL).

Główna różnica jest
oparta na stanie połączenia i/lub inicjacji komunikacji. STARTTLS
nie gwarantuje zaszyfrowanej komunikacji. To w zasadzie oznacza, 'jeśli połączenie jest nieszyfrowane i jesteś w stanie, zrób z tego bezpieczne połączenie’. Jeśli węzeł połączenia (prawdopodobnie serwer) nie jest w stanie przekształcić
połączenia w połączenie szyfrowane, może to zależeć od końca klienta, aby
zdecydować, jak sobie z tym poradzić.

Choć użyłem
kwalifikującego określenia STARTTLS jako „użyteczny”, może być uważany za mniej bezpieczny
niż wybór SSL/TLS. Standardowy wybór SSL/TLS to w zasadzie, „Use
encryption or bust.” STARTTLS mówi: „Um, jeśli mógłbyś, proszę, zrób to. Jeśli
nie, możemy kontynuować w oparciu o inne instrukcje.”

Here’s Some Conclusive Statements

Często zdarza się, że to co oczywiste musi być stwierdzone i może
przesadzone. Więc oto jest, ahem: Używaj szyfrowania. Szczególnie dla czegoś, co
jest tak ważne, tak kluczowe i zintegrowane z pozornie większość
każdej struktury organizacyjnej, która może nosić make or break informacji. Nie ma
wiele wysiłku, który trzeba w to włożyć. Używaj zarówno szyfrowania end-to-end, jak i in-transit
encryption. Dwa jest lepsze niż jeden.

Jeśli ktoś uważa, że dodatkowy wysiłek, aby skonfigurować serwer e-mail
do szyfrowania w porównaniu do nieszyfrowania nie jest tego wart, to ten ktoś jest
nie wart tego. To jest po prostu wyolbrzymianie oczywistości. Szyfrowanie end-to-end, takie jak S/MIME, wymaga
bardziej zaangażowanego podejścia, ale również jest tego warte przy dodawaniu warstw i warstw
bezpieczeństwa. Ale, nie ma wymówki, aby nie poświęcić czasu na konfigurację i utrzymanie
bezpiecznych połączeń.

Gdy widoczność pozwala, każda ścieżka e-mail, która może nie wydawać się bezpieczne lub zagrożone powinny być utrzymywane pod kontrolą. I z tym, bądź szczęśliwy w swoim badaniu dla bezpieczniejszego Internetu. Na zdrowie!

*** Jest to blog syndykowany przez Security Bloggers Network z Hashed Out by The SSL Store™, którego autorem jest Ross Thomas. Przeczytaj oryginalny post na: https://www.thesslstore.com/blog/encryption-and-email-servers/