Che cosa succede se STARTTLS viene rilasciato in SMTP?

Question

Che cosa succede se STARTTLS viene rilasciato in SMTP?

#1 da (4 voti)
#2 da (2 voti)

4

SMTP utilizza l'estensione STARTTLS per aggiornare SMTP a SMTP Secure (STMPS). Secondo la RFC , il client e il server avvia TLS come segue:

S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

Nello stesso documento, le specifiche menzionano la possibilità del MITM:

A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server.

Quello che non capisco dalle specifiche è: cosa cancella significa esattamente? sta cancellando il contenuto del messaggio ma inviandolo vuoto? (cioè corrompendolo) o rilasciandolo in modo che il client non lo riceva?

Se vuol dire lasciar cadere il messaggio in modo che il client non lo riceve, il server invierà 250 DSN ? non mi è chiaro se 250-STARTTLS abbia abbandonato quale sarà il prossimo messaggio? come il cliente viene a sapere che deve inviare EHLO mail.example.com e che non c'è 250-STARTTLS ?

smtp tls man-in-the-middle starttls tls-downgrade

posta user6875880 07.09.2017 - 20:23

fonte

2 risposte

2

Il man-in-the-middle si trova tra te e il server SMTP e nasconde la capacità di trasmissione del server di 250-STARTTLS (questo è ciò che elimina la risposta "250 STARTTLS" dal server significa).

Pertanto, il cliente non saprà che TLS è possibile; non tenterà TLS; e se il cliente non ha ricevuto istruzioni per richiederlo , la conversazione seguirà in chiaro e il MitM sarà in grado di leggerlo a suo piacimento.

Di solito, i client di posta possono essere configurati come "STARTTLS se disponibili", "STARTTLS", "plain" e così via. Nell'interesse dell'esperienza utente, il primo è spesso l'impostazione predefinita ("mantieni la posta che scorre a prescindere da cosa"). Nell'interesse della sicurezza, la seconda opzione è chiaramente migliore.

risposta data 07.09.2017 - 20:35

fonte

Leggi altre domande sui tag smtp tls man-in-the-middle starttls tls-downgrade

OWASP Secure Headers per i servizi Web Qual è la differenza tra un carico utile e uno shellcode?

score 4 · Accepted Answer

SMTP con STARTTLS funziona creando innanzitutto una connessione semplice al server e quindi aggiornandolo a TLS se il server lo supporta . Il server mostra il supporto per STARTTLS all'interno della risposta al comando EHLO. Un uomo nel mezzo potrebbe semplicemente modificare la risposta dal server e rimuovere le informazioni che supporta STARTTLS. In questo caso, il client ritiene che STARTTLS non sia supportato e non aggiornerà TLS.

Ad esempio la finestra di dialogo SMTP originale potrebbe essere simile a questa:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 STARTTLS

Da questo il cliente saprà che STARTTLS è il supporto. Un uomo nel mezzo o un firewall come Cisco ASA (ma anche altri) potrebbe modificare la risposta per far credere al cliente che TLS non sia supportato per ispezionare il traffico in chiaro:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 XXXXXXXX

A causa di questa modifica (in questo caso la sostituzione di STARTTLS con XXXXXXXX) il client non è a conoscenza del fatto che il server supporta TLS e quindi non lo proverà. Anche se il client lo prova ancora, l'uomo nel mezzo potrebbe riscrivere il comando STARTTLS del client in un altro comando (forse non valido) in modo che il server sembri rifiutare STARTTLS.

Si noti che il comportamento esatto in questo caso dipende dalla configurazione del client. Mentre le applicazioni per gli utenti finali (ad esempio MUA - mail user agent) sono spesso configurate per applicare TLS con il singolo server di posta configurato che usano, questo è diverso con MTA (mail server - mail transfer agent) per la comunicazione MTA. Di solito, gli MTA non sanno in anticipo che il prossimo hop nella distribuzione supporterà TLS in modo che controllino solo se TLS è possibile ma continuano in chiaro se non sembra che TLS sia possibile.

In sintesi: la crittografia opportunistica come questa è una cattiva idea dato che un uomo nel mezzo può semplicemente far credere a entrambe le parti che l'altra parte non supporta la crittografia.