Szyfrowanie STARTTLS – czy połączenie z Twoim serwerem pocztowym na pewno jest bezpieczne?

O konieczności szyfrowania połączenia pomiędzy klientem a serwerem pocztowym teoretycznie każdy wie. Niestety ta wiedza teoretyczna nie zawsze przekłada się na praktykę. Prawie w każdym audycie bezpieczeństwa, który zdarza mi się wykonywać trafiam na latające po sieciach firmowych hasła w formie niezaszyfrowanej. A to ktoś zapomniał o jakiejś starej maszynie wirtualnej, gdzie skonfigurowany był klient bez szyfrowanego połączenia, a to jakiś skrypt od backupu uwierzytelnia się do serwera SMTP, a to znowu firma przeszła na Office365 ale pracownicy zostawili sobie dostęp do archiwalnych skrzynek na serwerze, który szyfrowania nie wspierał…

Od pewnego czasu pocztowe aplikacje klienckie zaczęły, podobnie jak przeglądarki, ostrzegać przed nieszyfrowanymi połączeniami z serwerem. Np. Mozilla Thunderbird robi to tak:

Tak sugestywne ostrzeżenie powinno dać nam do myślenia. Niestety w przypadku mniej ostrożnych i niecierpliwych użytkowników niejednokrotnie skończy się na zaznaczeniu checkboxa o zrozumieniu ryzyka i pójściu dalej. „W końcu nie ja tu jestem od bezpieczeństwa w tej firmie„. I po części jest to racja, bo świadomy zagrożeń administrator powinien całkowicie wyłączyć usługi nieszyfrowane na serwerze pocztowym i wyciąć na firewallu możliwość łączenia się z takowymi u zewnętrznych dostawców.

Jak szyfrować komunikację z serwerem?

Podobnie jak w przypadku protokołu http, tak i protokoły pocztowe smtp, pop3, imap da się zabezpieczyć za pomocą szyfrowania z użyciem SSL/TLS. I tak, jak dla http szyfrowanym odpowiednikiem jest https, tak dla protokołów pocztowych będą to kolejno: pop3s (port 995), imaps (port 993) oraz smtps (port 465). Oczywiście domyślne numery portów nie są obligatoryjne i każdą usługę da się uruchomić również na innych portach.

Myląca, podobnie jak w przypadku usług www, może być nazwa SSL/TLS. Pamiętajcie, że SSL jest protokołem przestarzałym, którego bezpieczeństwo pozostawia wiele do życzenia i jeśli zależy nam na tym aby szyfrowanie było skuteczne powinniśmy korzystać z najnowszej dostępnej wersji TLS. Nadal jednak mówi się o certyfikatach SSL i szyfrowaniu SSL/TLS.

Częsty problem – certyfikat

Częstym niedopatrzeniem pojawiającym się przy konfiguracji usług szyfrowanych są nazwy serwerów wykorzystywane w certyfikatach. Tutaj podobnie jak w przypadku certyfikatów używanych na serwerach www można wygenerować certyfikat typu self-signed, którego zaufanie będzie kwestionowane przez programy klienckie. Od czasu spopularyzowania się usługi darmowych certyfikatów Let’s Encrypt ten problem występuje jednak stosunkowo rzadko.

Nadal jednak często pojawiającym się problemem jest niezgodność domen w certyfikatach. Dotyczy to zwłaszcza usług pocztowych utrzymywanych u hostingodawców. Problem ten wynika z tego, że hostingodawca rejestruje certyfikaty, których nazwy odpowiadają nazwom jego serwerów – np. mail.serwer-hostingowy.pl. Klienci z kolei konfigurując swoje programy korzystają (i to często zgodnie z instrukcją od hostingodawcy) z nazw domen, które u danego dostawy zarejestrowali – np. mail.moja-firma.pl.

Efekt jest taki, że klient pocztowy w chwili połączenia z serwerem ostrzega o niezgodności certyfikatu. Mniej rozgarnięty użytkownik nie będzie wiedział co to oznacza i może pomyśleć o błędnie przeprowadzonej konfiguracji. W najgorszym wypadku przełączy się na połączenie nieszyfrowane. A jeśli już miał do czynienia z podobną sytuacją, zaakceptuje nieprawidłowy certyfikat. To zachowanie również jest niepożądane gdyż uczy użytkowników złych nawyków. Jeśli ktoś zapamięta, że administrator kazał mu zaakceptować nieprawidłowy certyfikat do poczty, to być może innym razem zaakceptuje podobne ostrzeżenie logując się do serwisu www, co może skończyć się atakiem typu man in the middle.

Szyfrowanie STARTTLS – a co to za diabeł?

Wiemy już, że połączenie może być nieszyfrowane lub szyfrowane z użyciem SSL/TLS (w mniej lub bardziej elegancki sposób). Jednak w programach pocztowych pojawia się jeszcze opcja trzecia – STARTTLS:

Czym jest to tajemnicze STARTTLS? Nazwa mogłaby sugerować, że ma jakiś związek z szyfrowaniem TLS, czyli teoretycznie najbezpieczniejszą formą połączenia. W rzeczywistości jednak szyfrowanie STARTTLS to takie dwa w jednym, czyli możliwość nawiązania na danym porcie zarówno połączenia szyfrowanego, jak i nieszyfrowanego. To, która opcja zostanie zastosowana zależy od negocjacji pomiędzy klientem a serwerem pocztowym. W skrócie sprowadza się to do zasady „nawiąż komunikację szyfrowaną, chyba że się nie da – wówczas zezwól na nieszyfrowaną”.

Szyfrowanie STARTTLS – zagrożenia

I tutaj pojawia się bardzo poważne zagrożenie, ponieważ etap negocjacji pomiędzy klientem pocztowym a serwerem odbywa się w sposób jawny. Możemy to dokładnie prześledzić np. łącząc się telnetem z naszym serwerem pocztowym:

> telnet 192.168.55.66 25
Trying 192.168.55.66...
Connected to 192.168.55.66
Escape character is '^]'.
220 xxxx ESMTP Server
> EHLO test
250-Hello host.domena.local [192.168.55.6]
250-SIZE 146800640
250-8BITMIME
250-PIPELINING
250-X_PIPE_CONNECT
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
> STARTTLS
220 TLS go ahead
...

Zaznaczony powyżej fragment odpowiedzi serwera „250-STARTTLS” mówi klientowi pocztowemu, że serwer obsługuje szyfrowanie. Klient wysyła wówczas komendę „STARTTLS” i przechodzi do szyfrowanej komunikacji.

Co jednak w sytuacji gdy ktoś w sieci, do której się podłączyliśmy przeprowadzi atak typu man-in-the-middle i powyższy fragment odpowiedzi z serwera bądź klienta będzie usuwał, ewentualnie zastępował takim:

454 TLS not available due to temporary reason

Spowoduje tym samym, że nasz program pocztowy nawiąże z serwerem komunikację nieszyfrowaną. My natomiast nie będziemy nic podejrzewać – w programie mamy przecież ustawione bezpieczne połączenie STARTTLS.

O zagrożeniach tych mówi m.in. dokument RFC3207 SMTP Service Extension for Secure SMTP over TLS.

Sprawdźcie koniecznie konfigurację swoich skrzynek pocztowych i wszędzie, gdzie to możliwe wybierzcie komunikację SSL/TLS zarówno dla poczty przychodzącej (pop3, imap) jak i dla wychodzącej (smtp).

Warto też pamiętać, że szyfrowanie komunikacji z serwerem, to nie to samo co szyfrowanie wiadomości end-to-end pomiędzy nadawcą i odbiorcą. Nie gwarantuje nam ono pełnej poufności korespondencji. Ale tym tematem zajmiemy się już w jednym z kolejnych artykułów.

Obserwuj

Obserwuj