In Thunderbird (e presumo anche in molti altri client) ho la possibilità di scegliere tra "SSL / TLS" e "STARTTLS".
Per quanto ho capito, "STARTTLS" significa in parole semplici "crittografare se entrambe le estremità supportano TLS, altrimenti non crittografare il trasferimento" . E "SSL / TLS" significa in parole semplici "crittografare sempre o non connettersi affatto" . È corretto?
O in altre parole:
STARTTLS è meno sicuro di SSL / TLS, perché può ricorrere al testo normale senza avvisarmi?
Risposte:
La risposta, basata su STARTTLS RFC per SMTP ( RFC 3207 ) è:
Invece di parlare io stesso, permetterò all'RFC di parlare da solo, con i quattro bit rilevanti evidenziati in GRASSO :
Un attacco man-in-the-middle può essere lanciato eliminando la risposta "250 STARTTLS" dal server. Ciò impedirebbe al client di provare ad avviare una sessione TLS. Un altro attacco man-in-the-middle è quello di consentire al server di annunciare la sua funzionalità STARTTLS, ma di modificare la richiesta del client di avviare TLS e la risposta del server. Per difendersi da tali attacchi, sia i client che i server DEVONO poter essere configurati per richiedere una negoziazione TLS corretta di una suite di crittografia appropriata per host selezionati prima che i messaggi possano essere trasferiti correttamente. L' opzione aggiuntiva di utilizzare TLS quando possibile DOVREBBE essere fornita. Un'implementazione MAGGIO fornire la possibilità di registrare che TLS è stato utilizzato per comunicare con un determinato peer e generare un avviso se non viene utilizzato in una sessione successiva.
Se la negoziazione TLS fallisce o se il client riceve una risposta 454, il cliente deve decidere cosa fare dopo. Esistono tre scelte principali: andare avanti con il resto della sessione SMTP , [...]
Come puoi vedere, lo stesso RFC afferma (non molto chiaramente, ma abbastanza chiaramente) che NULLA non richiede ai clienti di stabilire una connessione sicura e informare gli utenti se una connessione sicura non è riuscita. Offre esplicitamente ai clienti la possibilità di stabilire silenziosamente connessioni in chiaro .
Non c'è differenza nella sicurezza tra le due opzioni.
SSL / TLS apre prima una connessione SSL / TLS, quindi inizia la transazione SMTP. Questo deve avvenire su una porta che non ha già un server SMTP non SSL / TLS già in esecuzione; è impossibile configurare una singola porta per gestire sia il testo normale sia le connessioni crittografate a causa della natura dei protocolli.
STARTTLS avvia la transazione SMTP e cerca supporto dall'altra estremità per TLS nella risposta a EHLO. Se il client vede STARTTLS nell'elenco dei comandi supportati, invia STARTTLS e inizia la negoziazione per la crittografia. Tutto ciò può (e di solito accade) sulla porta SMTP standard di 25, in parte per compatibilità con le versioni precedenti, ma anche per consentire la crittografia opportunistica tra endpoint che lo supportano entrambi ma non necessariamente lo richiedono.
In generale, SSL / TLS viene utilizzato solo tra client e server. STARTTLS è più comunemente usato tra gli MTA per proteggere il trasporto tra server.
Date queste due implementazioni, STARTTLS potrebbe essere interpretato come insicuro se l'utente o l'amministratore suppongono che la connessione sia crittografata ma non l'abbia effettivamente configurata per richiedere la crittografia. Tuttavia, la crittografia utilizzata è esattamente la stessa di SSL / TLS e quindi non più o meno vulnerabile a un attacco Man-in-the-Middle oltre questo tipo di errore di configurazione.
In particolare per la posta elettronica, a gennaio 2018 è stato rilasciato RFC 8314 , che raccomanda esplicitamente di utilizzare "TLS implicito" in preferenza del meccanismo STARTTLS per gli invii IMAP, POP3 e SMTP.
In breve, questo memo ora raccomanda che:
- TLS versione 1.2 o successiva può essere utilizzata per tutto il traffico tra MUA e server di invio posta e anche tra MUA e server di accesso alla posta.
- MUA e fornitori di servizi di posta (MSP) (a) scoraggiano l'uso di protocolli in chiaro per l'accesso e l'invio della posta e (b) deprecano l'uso di protocolli in chiaro per questi scopi non appena possibile.
- Le connessioni ai server di invio della posta e ai server di accesso alla posta devono essere effettuate utilizzando "Implicito TLS" (come definito di seguito), preferibilmente alla connessione alla porta "cleartext" e alla negoziazione di TLS utilizzando il comando STARTTLS o un comando simile.
(enfasi aggiunta)
La risposta dipende in una certa misura da cosa intendi per "sicuro".
In primo luogo, il tuo riepilogo non cattura completamente la differenza tra SSL / TLS e STARTTLS.
Se il client è configurato per richiedere TLS, i due approcci sono più o meno ugualmente sicuri. Ma ci sono alcune sottigliezze su come STARTTLS deve essere usato per renderlo sicuro, ed è un po 'più difficile per l'implementazione di STARTTLS ottenere quei dettagli giusti.
D'altra parte, se il client è configurato per utilizzare TLS solo quando TLS è disponibile e utilizzare il testo in chiaro quando TLS non è disponibile, ciò che il client potrebbe fare è provare prima a connettersi alla porta SSL utilizzata dal protocollo, e se quello fallisce, quindi connettiti alla porta cleartext e prova a utilizzare STARTTLS, e infine torna a cleartext se TLS non è disponibile in entrambi i casi. È abbastanza facile per un attaccante far fallire la connessione alla porta SSL (bastano alcuni pacchetti TCP RST tempestivi o il blocco della porta SSL). È un po 'più difficile - ma solo un po' - per un attaccante sconfiggere la negoziazione STARTTLS e far sì che il traffico rimanga in chiaro. E poi l'attaccante non solo riesce a leggere la tua e-mail, ma acquisisce anche il tuo nome utente / password per un uso futuro.
Quindi la semplice risposta è se ti stai connettendo a un server che già conosci supporta TLS (come dovrebbe essere il caso quando invii o leggi e-mail), dovresti usare SSL / TLS. Se la connessione viene attaccata, il tentativo di connessione fallirà, ma la password e l'e-mail non verranno compromesse.
D'altra parte, se ti stai connettendo ad un servizio che non sai se supporta TLS, STARTTLS potrebbe essere leggermente migliore.
Quando è stato inventato STARTTLS, gli attacchi "passivi" di solo ascolto erano molto comuni, gli attacchi "attivi" in cui l'attaccante avrebbe iniettato il traffico per cercare di ridurre la sicurezza erano meno comuni. Negli ultimi 20 anni, gli attacchi attivi sono diventati più fattibili e più comuni.
Ad esempio, se stai cercando di utilizzare un laptop in un aeroporto o in qualche altro luogo pubblico e cerchi di leggere la tua posta tramite il wifi fornito lì, non hai idea di cosa stia facendo quella rete wifi con il tuo traffico. È molto comune per le reti wifi indirizzare determinati tipi di traffico verso "proxy" che si interpongono tra le applicazioni client e i server con cui stanno cercando di parlare. È banale per quei proxy disabilitare sia STARTTLS sia "provare una porta poi un'altra" nel tentativo di far tornare il client in chiaro. Sì, questo accade ed è solo un esempio di come il tuo traffico può essere spiato da una rete. E tali attacchi non si limitano alle agenzie di tre lettere supportate dallo stato,
Sì, hai le basi giuste. E sì, STARTTLS è sicuramente meno sicuro. Non solo può eseguire il failback in testo normale senza notifica, ma perché è soggetto ad attacchi man-in-the-middle. Poiché la connessione inizia in chiaro, un MitM può eliminare il comando STARTTLS e impedire che si verifichi mai la crittografia. Tuttavia, credo che i server di posta possano specificare che i trasferimenti avvengono solo dopo aver configurato un tunnel crittografato. Quindi puoi aggirare questo.
Allora perché esiste una cosa del genere? Per motivi di compatibilità. Se entrambe le parti non supportano la crittografia, potresti comunque voler completare correttamente la connessione.
Accetto con @Greg. Questi attacchi sono possibili. Tuttavia, gli MTA possono essere configurati (a seconda dell'MTA) per utilizzare "TLS obbligatorio", non "TLS opportunistico". Ciò significa che TLS e solo TLS vengono utilizzati (questo include anche STARTTLS) per le transazioni e-mail. Se l'MTA remoto non supporta STARTTLS, l'e-mail viene rimbalzata.
No, è non è meno sicuro, quando l'applicazione gestisce correttamente.
Esistono quattro modi per gestire TLS e molti programmi consentono di scegliere:
starttls, utilizza una connessione non crittografata quando fallisce)starttlse non funziona se non funziona)Il vantaggio di TLS su una porta dedicata è che puoi essere sicuro che non ci sia fallback quando usi un programma che non conosci ancora o che non espone le impostazioni di dettaglio per la gestione degli errori nella sua procedura guidata al primo avvio.
Ma in generale la sicurezza dipende dalla gestione degli errori di sicurezza. Un programma potrebbe decidere di passare alla porta in chiaro quando anche TLS sulla porta TLS fallisce. Devi sapere cosa farà e scegliere impostazioni sicure. E i programmi dovrebbero usare valori di default sicuri.