...
logo di web hosting

Configurazione del server di posta TLS e selezione del cifrario: Guida definitiva

Vi mostrerò come Server di posta TLS in Postfix e selezionare suite di cifratura forti in modo che le connessioni SMTP siano costantemente protette. Sulla base di parametri collaudati per TLS 1.2/1.3, DANE, MTA-STS e coppie di chiavi moderne, vi guiderò passo dopo passo attraverso la configurazione, il test e la messa a punto, in modo che le vostre connessioni SMTP siano sempre protette. sicurezza della posta presa pulita.

Punti centrali

  • Postfix Configurazione sicura: Attivare TLS, limitare i protocolli, impostare la registrazione.
  • Cifra priorità: ECDHE + GCM/CHACHA20, applicare PFS, bloccare i dati legacy.
  • Certificati mantenere pulito: RSA+ECDSA, catena completa, curve forti.
  • DANE/MTA-STS utilizzare: Linee guida di ancoraggio e riduzione del rischio di downgrade.
  • Test e monitoraggio: controllare regolarmente OpenSSL, lo scanner TLS e i log dell'MTA.

SMTP via TLS: cosa è realmente protetto

Proteggo SMTP con STARTTLS, in modo che il trasporto delle e-mail non avvenga in chiaro. TLS opportunistico via smtpd_tls_security_level = may assicura che le connessioni in entrata utilizzino la crittografia non appena la stazione remota la offre. Per le consegne in uscita, uso smtp_tls_security_level = dane Controlli dei criteri supportati da DNSSEC per rendere più difficili gli attacchi di downgrade. Senza TLS, le e-mail potrebbero essere lette e manipolate in transito, il che è particolarmente pericoloso per i moduli, gli ordini o i dati dei conti. Con TLS sempre attivo, riduco significativamente il rischio di intercettazioni e MITM e ottengo tassi di consegna migliori perché i grandi provider valutano positivamente le connessioni sicure.

Chiavi, certificati e protocolli in Postfix

Ho due certificati pronti: uno RSA-e un certificato ECDSA, in modo che i vecchi e i nuovi MTA siano collegati in modo ottimale. Ho impostato chiaramente i percorsi in Postfix, ad esempio smtpd_tls_cert_file per RSA e smtpd_tls_eccert_file per ECDSA, ciascuno con una chiave corrispondente. Per un'autenticazione pulita, faccio attenzione alla catena completa, a un CN/SAN che corrisponda esattamente all'host e a una curva del tipo secp384r1 per la chiave ECDSA. Disattivo rigorosamente i protocolli più vecchi, cioè SSLv2 e SSLv3, per evitare downgrade forzati. Se state valutando il tipo di certificato, date una rapida occhiata a DV, OV o EV, in modo da scegliere il giusto livello di fiducia.

Selezione dei cifrari: Priorità per TLS 1.2/1.3

Do priorità alle suite di cifratura con PFS, cioè ECDHE prima di DHE e utilizzare GCM o CHACHA20-POLY1305. Con TLS 1.3, lo stack vi solleva da molti problemi legati al passato, mentre TLS 1.2 richiede ancora un elenco chiaro. Suite insicure o deboli come RC4, Elimino 3DES, CAMELLIA, aNULL, eNULL. Per Postfix uso smtpd_tls_ciphers = high e un'impostazione restrittiva tls_high_cipherlist, in modo che non sfuggano algoritmi obsoleti. Se si va più a fondo, il Guida alle suite di cifratura una categorizzazione facile da capire e senza zavorre.

Versione TLS Suite di cifratura preferite Stato Suggerimento
TLS 1.3 TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 attivo Selezione saldamente inserita nel protocollo, senza più problemi di legacy.
TLS 1.2 ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 attivo Privilegiare PFS, preferire GCM/CHACHA.
Obsoleto RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL bloccato Disattivare completamente per motivi di sicurezza.

Postfix: parametri concreti per main.cf

Ho impostato una configurazione chiara in modo che l'MTA parli in modo sicuro sia in entrata che in uscita. Per ECDH effimero, uso smtpd_tls_eecdh_grade Ho impostato la qualità della curva e disabilitato la compressione per evitare attacchi di tipo CRIME. Un file DH forte con 4096 bit impedisce le negoziazioni DHE deboli. Pongo restrizioni rigide sui protocolli e impongo un'elevata qualità dei cifrari, privilegiando TLS 1.3. All'inizio, un livello di log moderato mi aiuta a controllare le strette di mano senza ingolfare il giornale.

# Attivazione e politica
smtpd_tls_security_level = may
smtp_tls_security_level = dane

Certificati # (percorsi di esempio)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key

Protocolli e cifrari #
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra

Parametri DH #
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem

# DNSSEC/DANE (se disponibile)
smtp_dns_support_level = dnssec

# Registrazione
smtpd_tls_loglevel = 1

Mantenere la catena di certificati completa, prestare attenzione ai diritti corretti per privato e controllare i log dopo la ricarica. Se TLS 1.2 è richiesto per i partner legacy, mi attengo strettamente a GCM/CHACHA e blocco tutto il resto. Per TLS 1.3, mi affido agli standard dello stack ed evito percorsi speciali che rendono più difficile la manutenzione. La pinzatura OCSP ha un ruolo con SMTP solo se un proxy a monte la fornisce, quindi la controllo solo per le configurazioni corrispondenti. Dopo ogni modifica, eseguo una convalida con OpenSSL, per riconoscere tempestivamente gli effetti collaterali e per garantire che il crittografia delle e-mail coerentemente.

Autenticità del trasporto con DANE, MTA-STS, SPF, DKIM e DMARC

Combino TLS con DANE, pubblicando record TLSA firmati nell'ambito del protocollo DNSSEC. Inoltre, ho impostato MTA-STS in modo che i peer remoti sappiano che il mio host richiede TLS e a quale MX devono attenersi. Per il binding dell'identità, firmo i messaggi di posta in uscita con DKIM e la consegna sicura del dominio tramite le regole SPF. Infine, il DMARC definisce il modo in cui i destinatari devono gestire le deviazioni, rendendo molto più difficile lo spoofing. Questi componenti lavorano insieme: TLS protegge il trasporto, mentre l'autenticazione rafforza il mittente e aumenta sensibilmente il tasso di consegna.

Se le prestazioni sono un collo di bottiglia, ottimizzo la ripresa della sessione, le caratteristiche hardware e l'handshake stesso. È possibile iniziare con trucchi pratici con Handshake TLS più veloce, per ridurre la latenza quando si stabilisce una connessione. Importante: mantengo un equilibrio tra selezione del cifrario e ripresa, perché i compromessi deboli non ripagano in termini di sicurezza. La negoziazione rapida di TLS comporta un risparmio significativo, soprattutto con volumi di posta elevati. In questo modo Produttività e sicurezza in equilibrio.

Test, monitoraggio e audit

Controllo gli handshake localmente con openssl e controllare la versione del protocollo, il cifrario e la catena del certificato. Il comando openssl s_client -connect mail.example.de:25 -starttls smtp mi mostra in diretta ciò che il server remoto sta negoziando. Dopo le modifiche alla configurazione, utilizzo controllo postfix e guardare specificamente a smtpd_tls_loglevel, per isolare i modelli di errore. Gli scanner TLS esterni aiutano a classificare la visibilità pubblica, soprattutto dopo le modifiche dei certificati. Un ciclo di revisione regolare protegge da un deterioramento strisciante, ad esempio se una modifica della libreria influisce sulle priorità dei cifrari.

Frequenti configurazioni errate e soluzioni rapide

Vedo spesso cifrari obsoleti come AES128-SHA, che sono ancora attivi e impediscono il PFS. Una stringa di cifratura rigorosa e il chiaro blocco di LOW/MD5/RC4/3DES aiutano in questo caso. Secondo schema: certificati intermedi mancanti, che impediscono alle stazioni remote di verificare la catena; aggiungo il file di bundle e faccio un altro test. Su dispositivi come Synology, imposto il profilo TLS su moderno e rimuovo le opzioni legacy in modo che il server SMTP parli moderno. Per Microsoft Exchange, controllo specificamente i criteri TLS 1.2/1.3, l'assegnazione del certificato per connettore e qualsiasi override del cifrario nella configurazione dell'host, in modo che il server SMTP parli moderno. Stretta di mano-La selezione è giusta.

Anteprima: TLS 1.3, 0-RTT e Post-Quantum

Preferisco TLS 1.3 perché l'handshake è più breve e le vecchie opzioni vengono omesse, riducendo così le superfici di attacco. La selezione dell'opzione cifrario è chiaramente limitato e gli stack moderni forniscono buone impostazioni predefinite. Non uso 0-RTT nel contesto SMTP, poiché gli attacchi di replay comportano rischi inutili. Per il futuro, tengo d'occhio le procedure ibride post-quantistiche, che potrebbero trovare spazio nell'ambiente di posta non appena la standardizzazione e il supporto saranno maturi. Rimane importante impostare le politiche e il monitoraggio in modo tale da poter integrare le nuove procedure in un secondo momento senza interruzioni.

Prestazioni e tasso di consegna in sintesi

Misuro il Latenza dell'handshake TLS e ottimizzare le cache per consentirne il riutilizzo. La ripresa della sessione (ticket/ID) riduce il carico di calcolo e velocizza le connessioni ricorrenti tra gli MTA. Per la revoca dei certificati, mi affido alle informazioni impilabili presso il proxy a monte, se disponibili, per risparmiare accessi aggiuntivi. I grandi destinatari valutano positivamente i trasporti sicuri, il che aumenta il tasso di consegna, mentre i percorsi non sicuri aumentano il rischio di spam e di rifiuto. Con una politica TLS chiara, voci DNS solide e una catena di firme pulita, creo una base affidabile per Consegnabilità.

Il mio programma di configurazione

Inizio con l'ottenere il certificato da una CA affidabile, genero ECDSA e RSA e li memorizzo entrambi in modo pulito sull'host. Poi personalizzo il file main.cf con i parametri TLS, impostare cifrari forti e disattivare i vecchi protocolli. Viene aggiunto un nuovo file DH a 4096 bit, seguito da un reload e dai primi controlli OpenSSL. Configuro quindi DANE, aggiungo MTA-STS e verifico la validità di SPF/DKIM/DMARC. Infine, eseguo test su obiettivi esterni, controllo i registri durante il funzionamento e pianifico verifiche periodiche in modo che il sistema sia in grado di funzionare correttamente. Configurazione rimane sicuro nel lungo periodo.

Moduli mancanti: Submission, SMTPS e SNI

Non solo proteggo la porta 25, ma anche l'invio (587) e, facoltativamente, SMTPS (465). Per l'invio, impongo la crittografia e l'autenticazione in modo che le password degli utenti non vengano mai inviate in chiaro. In master.cf Attivo i servizi e imposto le specifiche sovrascritture:

invio # (porta 587) con STARTTLS e obbligo di autenticazione
invio inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_auth_only=yes
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING

# SMTPS (porta 465) come modalità wrapper, se necessario
smtps inet n - y - - smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING

Se servo diversi domini di posta su un unico host con i miei certificati, uso SNI. Uso una mappa SNI per assegnare il percorso del certificato appropriato per ogni host di destinazione e garantire che anche i client MUA vedano il certificato corretto. In questo modo garantisco la separazione dei client con un'identità TLS coerente.

Politiche per dominio: controllo a grana fine

Oltre alla politica globale, gestisco anche smtp_tls_policy_maps Eccezioni e restringimenti per dominio del destinatario. Questo mi permette di migrare gradualmente i partner legacy o di imporre requisiti particolarmente rigidi per gli obiettivi sensibili.

# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

# /etc/postfix/tls_policy (voci di esempio)
example.org solo per il danese
legacy.example.net può
secure.example.com sicuro

solo dane applica la protezione DANE senza dipendere dalla CA, sicuro richiede una catena CA valida e rifiuta la consegna di testo semplice, può rimane opportunistica. Dopo le modifiche, costruisco la mappa con postmap e ricaricare Postfix.

DANE e MTA-STS: implementazione concreta

Per DANE Pubblico i record TLSA sotto DNSSEC. Preferisco utilizzare DANE-EE (3 1 1) perché consente il pinning alla chiave pubblica e facilita la modifica del certificato con la stessa chiave. Un record TLSA esemplare sotto _25._tcp.mail.example.de sembra questo:

_25._tcp.mail.example.de. IN TLSA 3 1 1

Genero l'hash dal certificato ECDSA o RSA e mi assicuro di ruotarlo prima della scadenza. È importante che la zona DNS sia firmata e che la catena di deleghe sia convalidata senza lacune.

Per MTA-STS Ospito il file di criterio tramite HTTPS e aggiungo la voce DNS TXT. In questo modo, specifico che i peer remoti parlano TLS e sono accettati solo con un MX definito. Un file di criterio minimalista:

versione: STSv1
modalità: enforce
mx: mail.example.de
max_age: 604800

Nel DNS viene aggiunta una voce TXT alla voce _mta-sts.example.de con la versione corrente. Opzionalmente ho impostato TLS-RPT via TXT sotto _smtp._tls.example.de per ricevere rapporti sulle violazioni dei criteri. Questa telemetria mi aiuta a riconoscere tempestivamente guasti, declassamenti e certificati difettosi.

Rafforzare i protocolli, specificare il cifrario

Restringo i limiti dei protocolli e impongo la preferenza dei server. TLS 1.0/1.1 sono oggi superflui; permetto TLS 1.2 e 1.3 solo in profondità e in uscita. Per TLS 1.2, definisco un elenco positivo esplicito per escludere stock misti di vecchi cifrari:

# Irrigidimento aggiuntivo (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Elenco esplicito dei cifrari TLS 1.2 (solo PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA

# Utilizzare la preferenza del server
tls_preempt_cipherlist = sì

Mi assicuro che ECDHE sia favorito e che DHE sia solo un ripiego. Tengo aggiornato il mio file DH; sotto TLS 1.3 non ha alcun ruolo, ma è ancora utile per le rare azioni DHE.

Ripresa della sessione e cache

Per accelerare le cose, attivo le cache di sessione per il client e il server per rendere più favorevoli le riconnessioni. Il carico della CPU e la latenza si riducono sensibilmente, soprattutto con un'elevata velocità di invio della posta:

# Cache di sessione (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = sì

Controllo il tasso di risposta nei log e mi assicuro che nessuno sia troppo corto. durata_biglietti nella libreria TLS per rallentare la ripresa. Importante: la ripresa non deve indebolire la politica; mi attengo agli stessi requisiti di cifratura.

Azienda certificata: Rotazione e manutenzione della catena

Automatizzo il rinnovo e la ricarica dell'MTA in modo che nessun certificato scaduto finisca in funzione. Dopo ogni rinnovo, controllo che i certificati leaf e intermedi siano completamente nel bundle. Per il funzionamento doppio ECDSA/RSA, mi assicuro che entrambe le coppie ruotino prima che una modifica di massa causi problemi ai clienti. Verifico il percorso SNI e l'invio separatamente, perché i MUA possono mostrare modelli di errore diversi rispetto agli MTA.

Approfondimento della registrazione e della diagnostica

Aumento temporaneamente la profondità del registro quando si verifica un problema e utilizzo gli strumenti di bordo per i controlli incrociati:

Registrazione mirata # (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = sì

Con posttls-finger target.example.com Controllo quale politica si aspetta un MTA remoto e quali cifrari/protocolli sono negoziati. Utilizzo postconf -n | grep tls, per vedere solo i parametri TLS esplicitamente impostati; in questo modo posso trovare più rapidamente le deviazioni dai valori predefiniti. Nei log, cerco termini come nessun cifrario condiviso, verifica del certificato fallita oppure versione del protocollo, che indicano direttamente una mancata corrispondenza del cifrario, problemi di catena o limiti di protocollo troppo rigidi/troppo permissivi.

Gestire la compatibilità senza sacrificare la sicurezza

Pianifico le transizioni in modo consapevole: rimango in profondità con può, per evitare di perdere i messaggi di posta elettronica dai server tradizionali, ma registro le consegne in testo semplice. In uscita rimango rigoroso (DANE/MTA-STS/sicuro) e uso smtp_tls_policy_maps per i singoli casi. Se i singoli partner possono gestire solo TLS 1.2 con AES-GCM, questo è accettabile; io gestisco tutto ciò che è al di sotto di questo valore tramite eccezioni concordate con un tempo di esecuzione limitato, le documento e le includo nella pianificazione della migrazione. In questo modo si mantiene un livello generale elevato senza bloccare le operazioni commerciali.

Panoramica delle impostazioni predefinite TLS del sistema

Si noti che Postfix utilizza la libreria TLS del sistema. Gli aggiornamenti di OpenSSL/LibreSSL possono modificare le priorità di cifratura e il comportamento di TLS 1.3. Pertanto, dopo gli aggiornamenti del sistema, controllo casualmente gli handshake e confronto l'output di postconf -n con i miei valori target. Un set livello_di_compatibilità in Postfix aiuta a mantenere stabili le impostazioni predefinite, ma non mi affido ciecamente ad esso e documento le deviazioni esplicite nel file main.cf/master.cf.

Breve riepilogo per gli amministratori

Vorrei sottolineare che i cifrari forti con PFS, i certificati puliti e le politiche chiare sono essenziali per SMTP cruciale. TLS 1.3 vi solleva dai problemi di legacy, mentre TLS 1.2 richiede un elenco di cifrari disciplinato. DANE e MTA-STS rafforzano il percorso di trasporto, SPF/DKIM/DMARC garantiscono l'identità e la segnalazione. Test regolari e analisi dei log mostrano tempestivamente se una modifica ha effetti collaterali indesiderati. Grazie a questa guida, potrete configurare il vostro server di posta in modo da renderlo sicuro, performante e a prova di futuro, senza inutili I rischi.

Articoli attuali