Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Nacx 29. 05. 2018, 04:09:15
-
Ahoj vsem, muze mi nekdo rict jaky je rozdil mezi SSL/TLS/STARTTLS?
Co ctu tak STARTTLS je novejsi ale presto mene bezpecne.
https://image.ibb.co/hBxOhd/obrazek.png
-
SSL je starý protokol, poměrně nebezpečný, a v tom popisku je to ze setrvačnosti. Thunderbird už ho pár let nepodporuje.
TLS znamená, že se hned při navázání spojení naváže TLS.
STARTTLS znamená, že se spojení naváže nešifrovaně a někdy v průběhu komunikace (typicky co nejdřív) se pošle příkaz STARTTLS a hned po něm se již sestaveným TCP spojením najednou začne navazovat TLS.
Co je lepší je spíš otázka filozofická a bezpečnost má oboje stejnou.
-
STARTTLS je nebezpečné v tom, že když může útočník manipulovat se spojením, může obě strany komunikace přesvědčit o tom, že druhá strana žádné STARTTLS nepodporuje. Záleží pak na klientovi, zda vás bude nějak varovat, nebo zda bude pokračovat nešifrovaným spojením. Podstatné je to hlavně u automatického zasílání (když si mezi sebou předávají zprávy různé servery), protože tam není člověk, který by mohl rozhodnout, zda se může použít i nešifrované spojení, a server zpravidla neví, zda protistrana má nebo nemá STARTTLS podporovat – takže obvykle akceptuje i nešifrované spojení a uvedený útok je tedy proveditelný.
V případě SSL/TLS nešifrované spojení nepřipadá v úvahu, útočník ho může rozbít, může zkusit útočit na to, aby se použil starší/slabší protokol, ale nemůže docílit toho, aby spojení bylo úplně nešifrované.
Rozdíl je dále v tom, že že POP3/IMAP/SMTP přes TLS se považuje za jiný protokol a má jiné číslo portu, zatímco to samé s použitím STARTTLS je považováno stále za ty původní protokoly a běží na původních portech, pouze rozšířené o možnost přepnout do šifrovaného spojení.
-
STARTTLS znamená, že se spojení naváže nešifrovaně a někdy v průběhu komunikace (typicky co nejdřív) se pošle příkaz STARTTLS a hned po něm se již sestaveným TCP spojením najednou začne navazovat TLS.
Ovšem server může na STARTTLS odpovědět "neumím" a spojení pak pokračuje nešifrovaně (možná jde někde vynutit ukončení, tak dalece jsem to nezkoumal). Celý ten začátek běží nešifrovaně (se vším co s tím souvisí - někdo se do toho může nabourat, ochytit, pokusit se přesměrovat). Zkrátka a přibližně:
K: volám SERVER.
S: SERVER, příjem.
K: STARTTLS
S: Šifrujeme.
K: Šifrujeme.
K: volám SERVER.
S: SERVER, příjem.
K: STARTTLS
S: Neumím
K: Co se dá dělat, pojedeme nešifrovaně.
Co je lepší je spíš otázka filozofická a bezpečnost má oboje stejnou.
Kanál navázaný ihned jako šifrovaný má bezpečnost rozhodně lepší než kanál, který není.
Pokud server podporuje TLS, použil bych TLS, port a způsob autentizace ti řekne nějaký návod na tom kterém serveru.
Edit: slovosled
-
Ovšem server může na STARTTLS odpovědět "neumím" a spojení pak pokračuje nešifrovaně
Na to samozřejmě vývojáři mysleli a pokud se tohle stane, klient v komunikaci nepokračuje.
Kanál navázaný ihned jako šifrovaný má bezpečnost rozhodně lepší než kanál, který není.
Pokud se STARTTLS pošle třeba hned jako první příkaz, můžeš si to představit jako součást handshaku.
-
Na to samozřejmě vývojáři mysleli a pokud se tohle stane, klient v komunikaci nepokračuje.
Tohle platí pro Thunderbird? Protože obecně to samozřejmě neplatí, protože klient obecně neví, zda protistrana má podporovat STARTTLS.
-
protože klient obecně neví, zda protistrana má podporovat STARTTLS.
No, klient to obecně ví, a jinak to ani nezkouší...
220-mail.example.com ESMTP Tue, 29 May 2018 15:34:31 +0200
EHLO client.example.com
250-mail.example.com Hello mail.example.com [2001:db8::dead:beef], pleased to meet you
250-ETRN
250-AUTH LOGIN PLAIN
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-STARTTLS
250 SIZE 40960000
-
No, klient to obecně ví, a jinak to ani nezkouší...
Schválně jsem napsal co protistrana má podporovat. Protože kontrolu, zda vám útočník z odpovědi serveru nevymazal STARTTLS, těžko provedete tak, že se podíváte, jestli v odpovědi serveru je STARTTLS.
-
Tohle platí pro Thunderbird?
Ano. Proto jsou tam na výběr 4 možnosti: žádná - jasné, automaticky - pokud server STARTTLS podporuje, použije se, pokud ne (vč. MITM, který ten flag smazal), pošle se nešifrovaně, STARTTLS - pokusí se udělat STARTTLS, pokud ho server nepodporuje/selže, skončí, TLS/SSL - pokusí se udělat TLS, pokud ho server nepodporuje/selže, skončí.
Protože obecně to samozřejmě neplatí, protože klient obecně neví, zda protistrana má podporovat STARTTLS.
Ale to nesouvisí s tím, jestli TLS spojení vytváříte už na začátku TCP streamu nebo až po poslání "STARTTLS\n". Stejně byste mohl argumentovat, že nějaký klient může mít fallback, že když se nepodaří navázat TLS na :993, zkusí to v plaintextu tam nebo na :143. Prostě máte v konfiguraci "STARTTLS" nebo "TLS", tak se bude používat to.
-
Ale v principu má pravdu v klientu máte nastaveno STARTTLS a on se prostě nešifrovaně nepustí.
(Teoreticky může, ale nikdy jsem to neviděl)
Takže i pokud někdo má úplnou kontrolu nad přenosem se nikam dál nedostane.
Otázka je SMTP, tam už to je řešitelné... systémy se neznají a neví, jestli mají či nemají použít crypto.
No, klient to obecně ví, a jinak to ani nezkouší...
Schválně jsem napsal co protistrana má podporovat. Protože kontrolu, zda vám útočník z odpovědi serveru nevymazal STARTTLS, těžko provedete tak, že se podíváte, jestli v odpovědi serveru je STARTTLS.