SMTP con STARTTLS non è una vulnerabilità, sebbene offra un superficie di attacco data la complessità della tipica implementazione TLS. Se non ti serve, disattivalo (NIST SP800-123 §4.2.1 PDF).
Se ti affidi confidenzialmente a SMTP + STARTTLS per le comunicazioni, è facile sbagliare.
Protocolli STARTTLS ( LDAP , FTP più o meno, POP3 e IMAP , anche HTTP che supporta Apache , anche se non ha mai preso piede) sono intrinsecamente più difficili da gestire dalla politica di sicurezza e dalle prospettive del firewall. Ad esempio, se hai una regola che consente HTTPS a un server web configurato correttamente, tutto ciò che un firewall deve fare è verificare / applicare i record SSL / TLS.
Con i protocolli STARTTLS, per garantire la crittografia con un livello di affidabilità simile è necessario disporre di una maggiore ispezione del protocollo (potrebbe non essere disponibile sul firewall, potrebbe richiedere un proxy); o una fiducia molto maggiore nelle implementazioni client e server (ad es. per impedire l'invio o l'accettazione di credenziali di testo semplice).
Il punto precedente è più o meno l'argomento dell'avvertimento: con un protocollo TLS rigoroso come HTTPS puoi essere più sicuro (cifratura NULL a parte) nella crittografia della connessione rispetto a STARTTLS e alla negoziazione facoltativa della crittografia. È un rischio che deve essere valutato, non una vulnerabilità .
La tipica configurazione SMTP + STARTTLS (non client) (dalla mia esperienza) è:
- STARTTLS opportunistici
- ricomincia a cancellare il testo in caso di errore o quando STARTTLS manca
- ha impostazioni predefinite scadenti (selezione del codice, convalida del certificato)
Per utilizzare correttamente STARTTLS per aumentare la sicurezza delle comunicazioni devi considerare il DNS, l'elfante nella stanza , backup MX e override MX ("mailertable").
Un server client-auth ( SMTPAUTH ) con STARTTLS è più facile da proteggere se è solo per consentire al client roaming di autenticarsi in modo sicuro (tramite certificato client, nome utente / password o entrambi) per scopi di inoltro.
Un'implementazione di canale sicura ideale offre (almeno) tre cose:
- riservatezza / privacy (crittografia)
- autenticità (prova dell'identità di una o entrambe le parti)
- integrità (a prova di manomissione o di manomissione)
SMTP + STARTTLS devia da questo:
- dal momento che la comunicazione ricomincia e si basa su un canale di testo in chiaro non corredato e corruttibile, vi è spazio per l'interferenza MITM. Se STARTTLS è opportunistico, ciò significa che potrebbe essere banalmente sovvertito (se hai mai visto un Cisco PIX o ASA che esegue il suo protocollo SMTP "fixups " avrai visto qualcosa di simile in azione). Problema simile se la convalida del certificato è lassista.
- SMTP è un protocollo store-and-forward, la capacità TLS è solo punto a punto, non esiste una funzionalità "CONNECT" simile al proxy HTTP. cioè questa non è una crittografia end-to-end. Riservatezza, autenticazione e integrità sono limitate alle connessioni, non al messaggio, che potrebbe non essere quello che un utente si aspetta o richiede. Vedi anche Come può un utente non tecnico verificare che un messaggio sia stato inviato" in sicurezza "? ... o su TLS?