Postfix/TLS - Heinlein Support · 2005-05-31 · Lutz Jänicke: Postfix: SSL/TLS im Detail. 2....

Lutz Jänicke: Postfix: SSL/TLS im Detail. 2. MailserverKonferenz, 19./20. Mai 2005, Magdeburg

Postfix/TLS

... oder warum einfach, wenn es auch kompliziert geht?!


Postfix/TLS: Übersicht

● Motivation: Warum SMTP mit TLS?● TLS: Das Protokoll● Einbindung in Postfix und Konfiguration● Zukunft!?


Kurzer Hintergrund über den Autor

● Name: Lutz Jänicke– 19891994 wissenschaftlicher Mitarbeiter am Institut

für Elektrische Maschinen der TU Berlin

– 19952001 Oberingenieur am Lehrstuhl Allgemeine Elektrotechnik der BTU Cottbus

– Arbeitsgruppen (Personal) zwischen beiden Insituten verbunden

– Jeweils Admin mit vielen Dienstreisen

● Seit 2002 Innominate Security Technologies AG


Warum verschlüsseln?

● Authentifizierung zumeist mit Paßwörtern● Abhören ist trivial● Kryptographisch verstärkte Verbindungen

– schützen gegen das Ausspähen von Paßwörtern

– schützen gegen ManintheMiddleAngriffe

– gestatten den Einsatz von Public Key Authentifizierung


Verschlüsselungslösungen

● TLS Transportation Layer Security (vorm. SSL)– TCPorientierte Lösung an der Verbindungsschicht

● SSH Secure Shell– Loginorientierte Lösung mit zusätzlichen Tunneln

● IPsec VPN– Netzwerkorientierte Lösung für NetzzuNetz

Verkehr


TLS: Historische Entwicklung

● Erste verbreitete Version SSLv2, noch mit Sicherheitsproblemen (Autor: Netscape)

● Erheblich überarbeitetes Protokoll SSLv3 (Netscape)

● IETF Standard RFC2246 als TLSv1 (entsprechend „SSLv3.1“) Januar 1999

● Ergänzungen (z.B. AES in RFC3268) zugefügt● TLSv1.1 in Arbeit... immer noch


TLS: Grundeigenschaften

● TLS ist verbindungsorientiert (anders als IPsec/VPN)

● TLS setzt auf einer bestehenden Verbindung auf● TLS verlangt eine zuverlässige Verbindung

(Vollständigkeit und Reihenfolge der Datenpakete müssen garantiert sein)

● TLS stellt genau einen Kanal in der Verbindung bereit, es gibt also kein Multiplexing oder zusätzliche Tunnel (anders als SSH)


TLS: „API“ bleibt erhalten...

● read()● write()● connect()● accept()

● SSL_read(), BIO_read()

● SSL_write(), BIO_write()

● SSL_connect(), BIO_connect()

● SSL_accept(), BIO_accept()


TLS: Separate Ports

● Die ersten Protokolle, die mit SSL ergänzt wurden, erhielten separate Ports:– https (port 443) statt http (port 80)

– pop3s (port 995) statt pop (port 110)

– imaps (port 993) statt imap4 (port 143)

– smtps (port 465) statt smtp (port 25)!?


TLS: Separate Vorschaltprozesse

● DirektClient Process

socket--------------

|--------------

socketServer Process

● Mit TLSClient Process

socket--------------

socket„stunnel“socket

--------------|

--------------socket

„stunnel“socket

--------------socket

Server Process


TLS: Separate Ports (2)

● Separate Ports gestatten es, TLS/SSL ProtokollHandling in separate Prozesse auszulagern

● Separate Prozesse erlauben ein höheres Sicherheitsniveau

● Separate Prozesse erschweren es dem Serverprozeß, Informationen über den Client zu sammeln

● Separate Ports verschlingen zuviele „Well Known“ Ports


TLS: Protokollintegration

● Neuere Definitionen integrieren einen STARTTLSBefehl in die Protokolle:– RFC2487/3207: STARTTLS für ESMTP

– RFC2817: „Upgrade: TLS/1.0“ for HTTP/1.1

– RFC2595: STARTTLS for IMAP4

– RFC2595: STLS for POP3


TLS: Alogrithmen

● TLS definiert einen Satz von Algorithmen (1)DHEDSSAES256SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1

AES256SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1

EDHRSADESCBC3SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1

EDHDSSDESCBC3SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1

DESCBC3SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1

DESCBC3MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5

DHERSAAES128SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1

DHEDSSAES128SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1

AES128SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

IDEACBCSHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1

IDEACBCMD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5

RC2CBCMD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5

DHEDSSRC4SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1

RC4SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1

RC4MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5



...


TLS: Algorithmen

● TLS definiert einen Satz von Algorithmen (2)...

EXP1024DHEDSSDESCBCSHA SSLv3 Kx=DH(1024) Au=DSS Enc=DES(56) Mac=SHA1 export

EXP1024DESCBCSHA SSLv3 Kx=RSA(1024) Au=RSA Enc=DES(56) Mac=SHA1 export

EXP1024RC2CBCMD5 SSLv3 Kx=RSA(1024) Au=RSA Enc=RC2(56) Mac=MD5 export

EDHRSADESCBCSHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1

EDHDSSDESCBCSHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1

DESCBCSHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1

DESCBCMD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5

EXP1024DHEDSSRC4SHA SSLv3 Kx=DH(1024) Au=DSS Enc=RC4(56) Mac=SHA1 export

EXP1024RC4SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export

EXP1024RC4MD5 SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=MD5 export

EXPEDHRSADESCBCSHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export

EXPEDHDSSDESCBCSHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export

EXPDESCBCSHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export

EXPRC2CBCMD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export

EXPRC2CBCMD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export

EXPRC4MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

EXPRC4MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export


TLS: Auswahl der Algorithmen

● Der Client sendet eine Liste der von ihm unterstützten Algorithmen, sortiert nach seinen Präferenzen

● Der Server wählt aus dieser Liste einen Algorithmus aus.– OpenSSL folgt dabei den Präferenzen des Clients

– OpenSSL 0.9.7API würde auch ermöglichen, Präferenzen des Servers zu verwenden.


TLS: Symmetrische Verschlüsselung

● Symmetrische Verfahren (DES, AES, RC4) sind schnell

● Beide Seiten haben den gleichen geheimen Schlüssel, im Wesentlichen eine Zufallszahl

● Der Schlüssel wird aus dem „Premaster Secret“ gewonnen, das der Client während des Handshakes generiert und zum Server schickt– Der Client muß über einen guten Zufallsgenerator

verfügen


TLS: Handshake ohne DHE

● Client sendet „Hello“ mit Liste der Algorithmen● Server sendet Antwort mit seinem Zertifikat

– Zertifikat enthält Identifikation

– Zertifikat enthält öffentlichen RSASchlüsselteil

● Client sendet „Premaster Secret“ verschlüsselt mit dem öffentlichen Schlüssel des Servers– Server entschlüsselt das Secret mit seinem privaten RSASchlüssel. Wenn

er dies kann, hat er sich authentifiziert

– Jeder andere, der den privaten RSASchlüssel hat, kann das Secret auch entschlüsseln und mitlesen


TLS: Handshake mit DHE

● Client sendet „Hello“ mit Liste der Algorithmen● Server sendet Antwort mit seinem Zertifikat

– Zertifikat enthält Identifikation (und öffentlichen RSASchlüssel)

– Antwort enthält außerdem öffentlichen DHSchlüssel unterschrieben mit dem privaten RSASchlüssel

– DHSchlüssel wird vom Server jeweils frisch generiert

● Client sendet „Premaster Secret“ verschlüsselt mit dem öffentlichen DHSchlüssel des Servers– Server entschlüsselt das Secret mit seinem privaten DHSchlüssel.

– Ein anderer, der den privaten RSASchlüssel hat, kann das Secret nicht entschlüsseln, da ihm der DHSchlüssel unbekannt bleibt


TLS: Vor/Nachteile von DHE

● DiffieHellman Exchange– Erfordert gute Zufallszahlen auch beim Server

– Erfordert zusätzliche Rechenzeit durch Schlüsselgenerierung und zusätzliche private Schlüsseloperationen am Server

– Bietet „Forward Secrecy“ da auch beim Bekanntwerden des privaten RSASchlüssels des Servers keine Entschlüsselung möglich ist

– Erlaubt nur das Entschlüsseln je einer Sitzung, deren Schlüssel bekannt geworden ist


X.509 Zertifikate

● X.509 Zertifikate enthalten– Informationen über ein Objekt (Server, Person)

– Ggf. zusätzliche Information, z.B. Rechte

– Den öffentlichen Schlüssel (zumeist RSA) des Objekts

● Eine Bestätigung („Zertifikat“), daß alle Angaben zusammengehören und passen

● Eine Information über den Aussteller


X.509 Zertifikate: Modell

● Personalausweis enthält– Bild

– Name, Geburtstag, Wohnort

● Stempel bzw. Unterschrift zur Bestätigung der Zusammengehörigkeit dieser Informationen

● Eine Information über den Aussteller (z.B. Landeseinwohneramt)


X.509 Zertifikate: Beispiel

● openssl x509 text in serv01_cert.pemCertificate: Data: Version: 3 (0x2) Serial Number: 8426 (0x20ea) Signature Algorithm: md5WithRSAEncryption Issuer: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet Cottbus,

OU=Rechenzentrum, CN=BTUCA (20042008)/emailAddress=cabtu@tucottbus.de Validity Not Before: May 4 14:31:03 2004 GMT Not After : Jun 4 14:31:03 2006 GMT Subject: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische TechnischeUniversitaet Cottbus, OU=Lehrstuhl

Allgemeine Elektrotechnik und Num. Feldberechnung, CN=serv01.aet.tucottbus.de/[email protected]cottbus.de

Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:97:c1:f8:aa:d8:50:52:67:36:2a:48:d0:27:53:... 91:4f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment... X509v3 Subject Alternative Name: email:[email protected]cottbus.de X509v3 CRL Distribution Points: URI:http://WWW.RZ.TUCottbus.De/CA/20042008/btuca.crl

Netscape Cert Type: SSL Server...



● DN Distinguished Name des Objekts– Subject: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet Cottbus, OU=Lehrstuhl Allgemeine Elektrotechnik und Num. Feldberechnung, CN=serv01.aet.tucottbus.de/[email protected]cottbus.de

Darstellung (,/= usw) durch Programm, nicht im Zertifikat kodiert!



● DN Distinguished Name des Ausstellers– Issuer: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet Cottbus, OU=Rechenzentrum, CN=BTUCA (20042008)/emailAddress=cabtu@tucottbus.de



● Extensions– X509v3 Basic Constraints:

● CA:FALSE

– X509v3 Key Usage:● Digital Signature, Key Encipherment

– X509v3 Subject Alternative Name:● email:[email protected]cottbus.de

– X509v3 CRL Distribution Points:● URI:http://WWW.RZ.TUCottbus.De/CA/20042008/btuca.crl


X.509 Zertifikate: Probleme

● Es gibt nur einen CN CommonName– Lösung: Verwendung des Subject Alternative Names

– Hier sind mehrere dNSNameEinträge möglich

● Zertifikatsaussteller (CA) sind nicht unumstritten– Verwendung einer eigenen CA hat Vor und

Nachteile


TLS: Durchsatz/Performance

● Durchsatz wird durch symmetrischen Algorithmus bestimmt und sollte immer gut genug sein

● Der Handshake ist sehr aufwendig, da Operationen mit den privaten Schlüsseln notwendig sind (Signieren, Entschlüsseln)

● Problem von HTTPS bekannt, da dort viele Verbindungen aufgebaut werden müssen

● Lösung: TLS Session Caching


TLS: Session Caching

● Nach erfolgreichem Handshake werden gespeichert:

– Authentifizierungsdaten und status der Gegenstelle

– Ausgehandelte kryptographische Algorithmen

– PremasterSecret● Damit kann eine neue Verbindung unter Verwendung

der alten „Session“ ohne teuren Handshake aufgebaut werden (nacheinander oder parallel)

● Aufwand immer noch hoch, vgl. SMTP Session Caching


STARTTLS Protokoll

● ESMTP (Enhanced SMTP) wird um STARTTLS Option und Befehl erweitert (RFC2487/3207)

● STARTTLS wird in der EHLOAntwort aufgelistet

● STARTTLS wird vom Client geschickt● Server antwortet (mit 220 Go on...)● TLSHandshake wird ausgeführt● SMTPVerbindung wird fortgesetzt mit EHLO


STARTTLS: Sicherheit

● Die EHLOAntwort könnte verfälscht worden sein. Daher darf ein Client auch STARTTLS senden, wenn kein STARTTLS angeboten wurde

● Der Client muß prüfen, ob das Zertifikat der Gegenstelle den Erwartungen entspricht

– Was sind die Erwartungen?● Nach dem STARTTLS wird ein neues EHLO abgesetzt,

da

– die erste EHLOAntwort verfälscht sein könnte

– der Server mit TLS andere Optionen anbieten könnte


STARTTLS: Beispiel 1

● telnet serv01.aet.tucottbus.de 587220 serv01.aet.tu-cottbus.de ESMTP Postfix

EHLO lutzpc

250-serv01.aet.tu-cottbus.de

250-PIPELINING

250-SIZE 60000000

250-VRFY

250-ETRN

250-STARTTLS

250 8BITMIME

STARTTLS

220 Ready to start TLS

...


STARTTLS: Beispiel 2

● openssl s_client starttls smtp connect serv01.aet.tucottbus.de:587...

220 serv01.aet.tu-cottbus.de ESMTP Postfix

EHLO lutz

250-serv01.aet.tu-cottbus.de

250-PIPELINING

250-SIZE 60000000

250-VRFY

250-ETRN

250-AUTH LOGIN PLAIN

250 8BITMIME

...


STARTTLS: Authentifikation

● Bei TLS wird zwingend das Zertifikat des Servers übertragen

● Algorithmen ohne ServerZertifikat sind in OpenSSL per default abgeschaltet


STARTTLS: Authentifikation

● Der Client kann ein Zertifikat übersenden, wenn der Server ihn dazu auffordert– Der Server liefert eine Liste der ihm bekannten CAs mit

– OpenSSLClient ist nicht standardkonform und sendet „das“ konfigurierte Zertifikat, auch wenn keine passende CA gefunden wurde

– Automatische Auswahl eines „richtigen“ ClientZertifikats schwer zu implementieren, da die komplette Chain passen muß

● Authentifizierung mit ClientZertifikaten im STARTTLSStandard nicht durchdacht


Postfix und TLS

● Die Integration von TLS in Postfix beeinflußt 3 Hauptkomponenten:– smtpd (eingehende Verbindungen)

– smtp (ausgehende Verbindungen)

– tlsmgr (Hilfsfunktionen)


Postfix und TLS

● Struktur:

<---seed--- ---seed--->Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network <-session-> <-session->

/ | \ | / \

smtpd PRNG smtp session state session key cache file key cache

(Source: Wietse Venema: Postfix 2.2, TLS_README)


Postfix: smtpd

● smtpd wurde erweitert, um das STARTTLSProtokoll zu unterstützen

● Nach erfolgreichem STARTTLSHandshake wird SSL_accept() aufgerufen

● Bei erfolgreichem TLSHandshake wird Verbindung verschlüsselt weitergeführt

● Bei HandshakeFehler ist der Status der Gegenstelle unbekannt und die Verbindung muß abgebrochen werden


Postfix: smtpd Optionen

● smtpd_tls_cert_file, smtpd_tls_key_file– enthalten den öffentlichen und privaten Schlüssel

● smtpd_tls_CAfile, smtpd_tls_CApath– enthalten File bzw. Verzeichnis mit CAListe

● smtpd_use_tls, smtpd_enforce_tls– aktivieren bzw. erzwingen TLS global

● smtpd_tls_session_cache_database– Datenbank mit TLS session cache (per tlsmgr)


Postfix: smtpd Optionen

● smtpd_tls_ask_ccert, smtpd_tls_req_ccert– erfragen bzw. erfordern eines Client Zertifikats

● smtpd_tls_loglevel– Ausgaben im Level 14, empfohlen 1

● smtpd_tls_received_header– Ausgabe der TLSInformationen im Header

● relay_clientcerts, permit_tls_clientcerts, check_ccert_access– Datenbank/Tabelle mit Fingerprints


Postfix: smtp

● smtp wurde erweitert, um das STARTTLSProtokoll zu unterstützen

● Nach erfolgreichem STARTTLSHandshake wird SSL_connect() aufgerufen

● Bei erfolgreichem TLSHandshake wird Verbindung verschlüsselt weitergeführt

● Bei HandshakeFehler ist Status der Gegenstelle unbekannt und die Verbindung muß abgebrochen werden


Postfix: smtp Optionen

● smtp_tls_cert_file, smtp_tls_key_file– Öffentlicher bzw. privater Schlüssel

● smtp_tls_CAfile, smtp_tls_CApath– Datei bzw. Verzeichnis mit CAZertifikaten

● smtp_tls_use_tls, smtp_tls_enforce_tls– Benutze TLS wenn angeboten oder immer

● smtp_tls_per_site– Auswahl von TLSBenutzung nach Ziel


Postfix: smtp Optionen

● smtp_tls_session_cache_database– Datenbank mit SessionInformationen (via tlsmgr)

● smtp_tls_loglevel– Ausgabe mit Level 14, empfohlen 1

● smtp_tls_note_starttls_offer– Logge Informationen, welche Server STARTTLS

angeboten hätten


Postfix: tlsmgr

● tlsmgr verwaltet Session Cache Datenbanken– Datenbanken würde ohne Grenze wachsen

– tlsmgr läuft regelmäßig durch die Datenbanken und löscht alte Einträge

– Synchronisation erfolgt durch tlsmgr, welcher als einziger auf die Datenbanken zugreift

– smtp und smtpdProzesse kommunizieren über Socket mit tlsmgr

– Verwendete Datenbank muß Objekte größer 1kB zulassen. Empfohlen: btree


Postfix: tlsmgr

● tlsmgr koordiniert auch den Zugriff auf Zufallsgeneratoren– nur nötig bei EGD mit begrenztem Vorrat


Postfix/TLS: Implementierung

● Integration der TLSFunktionalität direkt in die smtp bzw. smtpdApplikationen

● Applikationen werden gegen OpenSSL gelinkt● Bei Aktivierung von TLS werden Postfix'

timed_read() und timed_write() Funktionen durch tls_timed_read() und tls_timed_write() ersetzt (VSTREAM over TLS)

● Implementierung erfolgt über OpenSSLs BIOpairFunktionen mit integrierten Puffern


Postfix/TLS: BIO Pairs

● The TLS layer is realized with a BIOpair: postfix | TLS-engine

| |

+--------> SSL_operations()

| /\ ||

| || \/

| BIO-pair (internal_bio)

+--------< BIO-pair (network_bio)

| |

socket |


Postfix/TLS: Geschichte

● Ursprünglich entwickelt für spezielles Problem– Postfix/TLS 0.1.0: März 1999

● Entwicklung zur „FullyFeatured“ Ergänzung– Wesentliche Entwicklungen: 19992002

– Pflege und Anpassung: 20032004

● Integration in Postfix „Main Stream“– Postfix 2.2: März 2005


Postfix/TLS: Zukunft(!?)

● Architektur:– Separierung von TLSFunktion in spezifische

Prozesse

– Dadurch Erhöhung der Sicherheit und Modularität

– Mögliche Integration in SMTPSession Caching durch Bündelung eines TLSProzesses an den offenen Socket


Postfix/TLS: Zukunft(!?)

● TLSErgänzungen– Unterstützung von Certificate Revocation Lists (CRL)

● Bricht Kompatibilität mit OpenSSL 0.9.6● OpenSSL 0.9.7 seit Dezember 2002 verfügbar● Erfordert unabhängigen Download der CRL

– Angepaßte Auswahl der Ciphern nach ServerPräferenz

● Weitere kleine Maßnahmen– Anpassung des Logging

– ...


Tools

● OpenSSL– http://www.openssl.org/

● SSLdump– http://www.rtfm.com/ssldump/

● Stunnel– http://www.stunnel.org/


Kontaktdaten

● OpenSource [email protected]Cottbus.DE

http://www.aet.TUCottbus.DE/personen/jaenicke/

● FirmenkontaktDr. Lutz Jänicke

Innominate Security Technologies AG

AlbertEinsteinStraße 14

12489 Berlin

[email protected]

http://www.innominate.com/

Postfix/TLS - Heinlein Support · 2005-05-31 · Lutz Jänicke: Postfix: SSL/TLS im Detail. 2....

Documents

Transcript of Postfix/TLS - Heinlein Support · 2005-05-31 · Lutz Jänicke: Postfix: SSL/TLS im Detail. 2....