Jeg viser dig, hvordan du Mailserver TLS i Postfix og vælge stærke cipher suites, så SMTP-forbindelser er konsekvent beskyttet. Baseret på afprøvede og testede parametre for TLS 1.2/1.3, DANE, MTA-STS og moderne nøglepar, vil jeg guide dig trin for trin gennem konfiguration, test og indstilling, så din Mail-sikkerhed griber rent.
Centrale punkter
- Postfix Konfigurer sikkert: Aktiver TLS, begræns protokoller, indstil logning.
- Chiffre prioritere: ECDHE + GCM/CHACHA20, håndhævelse af PFS, blokering af ældre data.
- Certifikater Hold dig ren: RSA+ECDSA, komplet kæde, stærke kurver.
- DANE/MTA-STS udnytte: Forankring af retningslinjer og reduktion af nedgraderingsrisici.
- Test og overvågning: Tjek OpenSSL, TLS-scanner, MTA-logfiler regelmæssigt.
SMTP via TLS: Hvad er egentlig sikret?
Jeg sikrer SMTP med STARTTLS, så e-mailtransporten ikke foregår i ren tekst. Opportunistisk TLS via smtpd_tls_security_level = may sikrer, at indgående forbindelser bruger kryptering, så snart fjernstationen tilbyder det. Til udgående leverancer bruger jeg smtp_tls_security_level = dane DNSSEC-understøttede politiktjek for at gøre nedgraderingsangreb sværere. Uden TLS kan e-mails læses og manipuleres undervejs, hvilket er særligt farligt for formularer, ordrer eller kontodata. Med TLS aktiv hele vejen igennem reducerer jeg risikoen for aflytning og MITM betydeligt, og jeg opnår bedre leveringshastigheder, fordi store udbydere vurderer sikre forbindelser positivt.
Nøgler, certifikater og protokoller i Postfix
Jeg har to certifikater klar: et RSA-certifikat og et ECDSA-certifikat, så gamle og nye MTA'er er optimalt forbundet. Jeg indstiller stierne i Postfix tydeligt, for eksempel smtpd_tls_cert_file for RSA og smtpd_tls_eccert_file til ECDSA, hver med en matchende nøgle. Til ren autentificering er jeg opmærksom på den komplette kæde, en CN/SAN, der matcher værten nøjagtigt, og en kurve som secp384r1 til ECDSA-nøglen. Jeg deaktiverer strengt taget ældre protokoller, dvs. SSLv2 og SSLv3, for at forhindre tvungne nedgraderinger. Hvis du overvejer typen af certifikat, kan et hurtigt kig på DV, OV eller EV, så du vælger det rigtige niveau af tillid.
Valg af chiffer: Prioriteter for TLS 1.2/1.3
Jeg prioriterer cipher-suiter med PFS, dvs. ECDHE før DHE, og brug GCM eller CHACHA20-POLY1305. Under TLS 1.3 fritager stakken dig for mange gamle problemer, mens TLS 1.2 stadig kræver en klar liste. Usikre eller svage suiter som f.eks. RC4, Jeg sletter 3DES, CAMELLIA, aNULL, eNULL. Til Postfix bruger jeg smtpd_tls_ciphers = høj og en restriktiv tls_high_cipherlist, så ingen forældede algoritmer slipper igennem. Hvis du går dybere, er Cipher Suites-guide en letforståelig kategorisering uden ballast.
| TLS-version | Favorit cipher suites | Status | Hint |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | aktiv | Udvælgelsen er fast forankret i protokollen, ikke flere gamle problemer. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | aktiv | Prioriterer PFS, foretrækker GCM/CHACHA. |
| Forældet | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | låst | Deaktiver helt af sikkerhedsmæssige årsager. |
Postfix: konkrete parametre til main.cf
Jeg indstiller en klar konfiguration, så MTA'en taler sikkert både indgående og udgående. Til ephemeral ECDH bruger jeg smtpd_tls_eecdh_grade Jeg indstiller kurvekvaliteten og deaktiverer komprimering for at undgå CRIME-lignende angreb. En stærk DH-fil med 4096 bits forhindrer svage DHE-forhandlinger. Jeg lægger hårde begrænsninger på protokoller og håndhæver høj cipher-kvalitet og foretrækker TLS 1.3. I starten hjælper et moderat logniveau mig med at tjekke håndtryk uden at oversvømme journalen.
#-aktivering og -politik
smtpd_tls_security_level = may
smtp_tls_security_level = dane
#-certifikater (eksempler på stier)
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
#-protokoller og cifre
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = høj
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
# DH-parametre
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (hvis tilgængelig)
smtp_dns_support_level = dnssec
# Logning
smtpd_tls_loglevel = 1
Jeg holder certifikatkæden komplet, er opmærksom på korrekte rettigheder for privat nøglefiler og tjekker logfilerne efter genindlæsningen. Hvis TLS 1.2 er påkrævet for ældre partnere, holder jeg mig strengt til GCM/CHACHA og blokerer alt andet. For TLS 1.3 stoler jeg på stakkens standarder og undgår særlige stier, der gør vedligeholdelse vanskeligere. OCSP-hæftning spiller kun en rolle med SMTP, hvis en upstream-proxy leverer det, så jeg tjekker det kun for tilsvarende opsætninger. Efter hver ændring validerer jeg med OpenSSL for at genkende bivirkninger tidligt og for at sikre, at Kryptering af e-mail konsekvent.
Transportautenticitet med DANE, MTA-STS, SPF, DKIM og DMARC
Jeg kombinerer TLS med DANE, ved at udgive signerede TLSA-poster under DNSSEC. Derudover indstiller jeg MTA-STS, så eksterne peers ved, at min vært kræver TLS, og hvilken MX de skal overholde. Til identitetsbinding signerer jeg udgående mails med DKIM og sikker domænelevering via SPF-regler. Endelig definerer DMARC, hvordan modtagere skal håndtere afvigelser, hvilket gør spoofing meget sværere. Disse komponenter arbejder sammen: TLS beskytter transporten, mens autentificering styrker afsenderen og øger leveringshastigheden mærkbart.
Hvis ydeevnen er en flaskehals, optimerer jeg genoptagelse af sessioner, hardwarefunktioner og selve håndtrykket. Du kan komme i gang med praktiske tricks med TLS-håndtryk hurtigere, for at reducere ventetiden ved etablering af en forbindelse. Vigtigt: Jeg holder valg af kryptering og genoptagelse i balance, fordi svage kompromiser ikke betaler sig med hensyn til sikkerhed. Hurtig TLS-forhandling giver betydelige besparelser, især med store postmængder. På denne måde Gennemstrømning og sikkerhed i balance.
Test, overvågning og revision
Jeg tjekker håndtryk lokalt med openssl og tjekke protokolversion, cipher og certifikatkæde. Kommandoen openssl s_client -connect mail.example.de:25 -starttls smtp viser mig live, hvad fjernserveren forhandler om. Efter konfigurationsændringer bruger jeg postfix-kontrol og se specifikt på smtpd_tls_loglevel, til at isolere fejlmønstre. Eksterne TLS-scannere hjælper med at kategorisere offentlig synlighed, især efter certifikatændringer. En regelmæssig revisionscyklus beskytter mod snigende forringelser, f.eks. hvis en biblioteksændring påvirker krypteringsprioriteterne.
Hyppige fejlkonfigurationer og hurtige løsninger
Jeg ser ofte forældede koder som AES128-SHA, som stadig er aktive og forhindrer PFS. En streng krypteringsstreng og den klare blokering af LOW/MD5/RC4/3DES hjælper her. Andet mønster: manglende mellemliggende certifikater, som forhindrer fjernstationer i at verificere kæden; jeg tilføjer bundtfilen og tester igen. På apparater som en Synology indstiller jeg TLS-profilen til moderne og fjerner ældre indstillinger, så SMTP-serveren taler moderne. Med Microsoft Exchange kontrollerer jeg specifikt TLS 1.2/1.3-politikker, certifikattildeling pr. connector og eventuelle cipher-overrides i værtskonfigurationen, så Håndtryk-udvælgelsen er rigtig.
Forhåndsvisning: TLS 1.3, 0-RTT og Post-Quantum
Jeg foretrækker TLS 1.3, fordi håndtrykket er kortere, og gamle indstillinger er udeladt, hvilket reducerer angrebsfladerne. Valget af chiffer er klart begrænset der, og moderne stakke giver gode standardindstillinger. Jeg bruger ikke 0-RTT i SMTP-sammenhæng, da replay-angreb medfører unødvendige risici her. I fremtiden holder jeg øje med hybride post-kvante-procedurer, som kan finde vej ind i mailmiljøet, så snart standardisering og support er modnet. Det er fortsat vigtigt, at jeg opsætter politikker og overvågning på en sådan måde, at nye procedurer kan integreres senere uden forstyrrelser.
Overblik over ydeevne og leveringshastighed
Jeg måler på Forsinkelse af TLS-håndtrykket og optimerer cachen, så den kan genbruges. Genoptagelse af sessioner (billetter/ID'er) reducerer computerbelastningen og fremskynder tilbagevendende forbindelser mellem MTA'er. Ved tilbagekaldelse af certifikater bruger jeg stabelbare oplysninger på upstream-proxyen, hvis de er tilgængelige, for at spare yderligere adgang. Store modtagere vurderer sikker transport positivt, hvilket øger leveringshastigheden, mens usikre stier øger risikoen for spam og afvisning. Med en klar TLS-politik, solide DNS-poster og en ren signaturkæde skaber jeg et pålideligt grundlag for Leveringsevne.
Min opsætningsplan
Jeg starter med at få certifikatet fra en troværdig CA, genererer ECDSA og RSA og gemmer begge dele på værten. Derefter tilpasser jeg main.cf med TLS-parametrene, indstil stærke cifre og deaktiver gamle protokoller. En ny DH-fil med 4096 bits tilføjes, efterfulgt af en genindlæsning og de første OpenSSL-tjek. Derefter opsætter jeg DANE, tilføjer MTA-STS og kontrollerer SPF/DKIM/DMARC for gyldighed. Endelig kører jeg tests mod eksterne mål, tjekker logfiler under drift og planlægger regelmæssige revisioner, så Konfiguration forbliver sikker på lang sigt.
Manglende moduler: Submission, SMTPS og SNI
Jeg sikrer ikke kun port 25, men også submission (587) og eventuelt SMTPS (465). Ved indsendelse håndhæver jeg kryptering og godkendelse, så brugernes adgangskoder aldrig sendes i klartekst. I master.cf Jeg aktiverer tjenesterne og indstiller specifikke overstyringer:
#-indsendelse (port 587) med STARTTLS og auth-forpligtelse
indsendelse 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 (port 465) som wrapper-tilstand, hvis det er nødvendigt
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
Hvis jeg betjener flere mail-domæner på en host med mine egne certifikater, bruger jeg SNI. Jeg bruger et SNI-kort til at tildele den rette certifikatsti til hver målhost og sikre, at MUA-klienter også ser det korrekte certifikat. Det er sådan, jeg sikrer klientseparation med ensartet TLS-identitet.
Politikker pr. domæne: finkornet kontrol
Ud over den globale politik administrerer jeg også smtp_tls_policy_maps Undtagelser og stramninger pr. modtagerdomæne. Det giver mig mulighed for gradvist at migrere ældre partnere eller håndhæve særligt strenge krav til følsomme mål.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (eksempler på poster)
example.org kun dansk
legacy.example.net may
secure.example.com sikker
Kun dansker håndhæver DANE-beskyttelse uden CA-afhængighed, sikker kræver en gyldig CA-kæde og afviser levering af ren tekst, kan forbliver opportunistisk. Efter ændringer bygger jeg kortet med postkort og genindlæs Postfix.
DANE og MTA-STS: konkret implementering
For DANE Jeg udgiver TLSA-poster under DNSSEC. Jeg foretrækker at bruge DANE-EE (3 1 1), fordi den tillader pinning til den offentlige nøgle og gør det lettere at ændre certifikater med den samme nøgle. Et eksempel på en TLSA-post under _25._tcp.mail.example.de ser sådan her ud:
_25._tcp.mail.example.de. IN TLSA 3 1 1 .
Jeg genererer hashen fra ECDSA- eller RSA-certifikatet og sørger for at rotere det, før det udløber. Det er vigtigt, at DNS-zonen er signeret, og at delegeringskæden er valideret uden huller.
For MTA-STS Jeg hoster politikfilen via HTTPS og tilføjer TXT DNS-indgangen. På den måde specificerer jeg, at eksterne peers taler TLS og kun accepteres med en defineret MX. En minimalistisk politikfil:
version: STSv1
tilstand: håndhæve
mx: mail.example.de
max_age: 604800
Der tilføjes en TXT-post i DNS under _mta-sts.example.de med den aktuelle version. Eventuelt opsætter jeg TLS-RPT via TXT under _smtp._tls.example.de for at modtage rapporter om politikbrud. Denne telemetri hjælper mig med at genkende fejl, nedgraderinger og defekte certifikater på et tidligt tidspunkt.
Stram protokoller, specificer kryptering
Jeg strammer protokolgrænserne og håndhæver serverpræference. TLS 1.0/1.1 kan undværes i dag; jeg tillader kun TLS 1.2 og 1.3 i dybden og på udgående basis. For TLS 1.2 definerer jeg en eksplicit positivliste for at udelukke blandede lagre af gamle cifre:
# Yderligere hærdning (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
# Eksplicit TLS 1.2 cipher-liste (kun 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
# Brug serverpræference
tls_preempt_cipherlist = ja
Jeg sørger for, at ECDHE er foretrukket, og at DHE kun er en nødløsning. Jeg holder min DH-fil opdateret; under TLS 1.3 spiller den ikke nogen rolle, men den er stadig nyttig til sjældne DHE-handlinger.
Genoptagelse af sessioner og cacher
For at fremskynde tingene aktiverer jeg sessionscacher for klienten og serveren for at gøre genforbindelserne mere fordelagtige. CPU-belastning og ventetid reduceres mærkbart, især med høj mailgennemstrømning:
#-sessionscache (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 = ja
Jeg overvåger hitraten i logfilerne og sørger for, at ingen af dem er for korte. billet_levetid i TLS-biblioteket for at gøre genoptagelsen langsommere. Vigtigt: Genoptagelse må ikke svække politikken; jeg holder mig til de samme cipher-krav.
Certificeret virksomhed: Rotation og kædevedligeholdelse
Jeg automatiserer fornyelsen og genindlæsningen af MTA'en, så ingen udløbne certifikater ender med at være i drift. Efter hver fornyelse kontrollerer jeg, om blad- og mellemcertifikaterne er helt i bundtet. Ved dobbelt ECDSA/RSA-drift sørger jeg for, at begge par roterer, før en masseændring skaber problemer for klienterne. Jeg tester SNI-stien og indsendelsen separat, fordi MUA'er kan vise andre fejlmønstre end MTA'er.
Uddyb logning og diagnosticering
Jeg øger midlertidigt logdybden, når der opstår et problem, og bruger indbyggede værktøjer til krydstjek:
# målrettet logning (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = ja
Med posttls-finger target.example.com Jeg tjekker, hvilken politik en ekstern MTA forventer, og hvilke cifre/protokoller der forhandles om. Jeg bruger postconf -n | grep tls, for kun at se eksplicit indstillede TLS-parametre; jeg kan hurtigere finde afvigelser fra standardværdierne på denne måde. I logfilerne søger jeg efter udtryk som ingen delt kryptering, Certifikatverificering mislykkedes eller protokolversion, der direkte indikerer cipher-mismatch, kædeproblemer eller protokolgrænser, der er for strenge/for slappe.
Håndtering af kompatibilitet uden at gå på kompromis med sikkerheden
Jeg planlægger overgange bevidst: Jeg holder mig i dybden med kan, for at undgå at miste mails fra ældre servere over hele linjen, men logger leverancer i almindelig tekst. Udgående forbliver jeg streng (DANE/MTA-STS/secure) og bruger smtp_tls_policy_maps for individuelle tilfælde. Hvis enkelte partnere kun kan håndtere TLS 1.2 med AES-GCM, er det acceptabelt; jeg håndterer alt under dette via aftalte undtagelser med en begrænset køretid, dokumenterer dem og inkluderer dem i migrationsplanlægningen. Det holder det overordnede niveau højt uden at blokere for forretningsdriften.
Et overblik over systemets TLS-standardindstillinger
Bemærk, at Postfix bruger systemets TLS-bibliotek. Opdateringer til OpenSSL/LibreSSL kan ændre cipher-prioriteter og TLS 1.3-adfærd. Efter systemopdateringer tjekker jeg derfor tilfældigt handshakes og sammenligner output fra postconf -n med mine målværdier. Et sæt kompatibilitet_niveau i Postfix hjælper med at opretholde stabile standardindstillinger, men jeg stoler ikke blindt på den og dokumenterer eksplicitte afvigelser i main.cf/master.cf.
Kort oversigt for administratorer
Jeg vil gerne understrege, at stærke cifre med PFS, rene certifikater og klare politikker er afgørende for SMTP afgørende. Med TLS 1.3 slipper du for gamle problemer, mens TLS 1.2 kræver en disciplineret cipher-liste. DANE og MTA-STS hærder transportvejen, SPF/DKIM/DMARC sikrer identitet og rapportering. Regelmæssige tests og loganalyser viser tidligt, om en ændring har uønskede bivirkninger. Med denne vejledning kan du sætte din mailserver op til at være sikker, performant og fremtidssikret - uden unødvendige Risici.


