SSL/TLS im Detail - Heinlein
SSL/TLS im Detail - Heinlein
SSL/TLS im Detail - Heinlein
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong><br />
Eine Einführung in <strong>SSL</strong>/<strong>TLS</strong>, die Integration in<br />
(E)SMTP und die Nutzung mit Postfix<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix/<strong>TLS</strong>: Übersicht<br />
● Motivation: Warum SMTP mit <strong>TLS</strong>?<br />
● <strong>TLS</strong>: Das Protokoll<br />
● Einbindung in Postfix und Konfiguration<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Warum verschlüsseln?<br />
● Authentifizierung zumeist mit Paßwörtern<br />
● Abhören ist trivial<br />
● Kryptographisch geschützte Verbindungen<br />
– schützen gegen das Ausspähen von Paßwörtern<br />
– schützen gegen ManintheMiddleAngriffe<br />
– gestatten den Einsatz von Public Key Authentifizierung<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Und was ist mit DIGESTMD5?<br />
● DIGESTMD5 überträgt nur Hashwerte<br />
● Jede Übertragung hat Zufallskomponenten<br />
– Hierdurch werden ReplayAngriffe verhindert<br />
● Abgehörte Konversationen angreifbar<br />
– Ein DictionaryAngriff kann erfolgen<br />
● Risikopotential?<br />
– Angriff aufwendig... aber lohnend?<br />
– Gleiche Paßworte häufig für viele Dienste<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Verschlüsselungslösungen<br />
● <strong>TLS</strong> Transportation Layer Security (vorm. <strong>SSL</strong>)<br />
– TCPorientierte Lösung an der Verbindungsschicht<br />
● SSH Secure Shell<br />
– Loginorientierte Lösung mit zusätzlichen Tunneln<br />
● IPsec VPN<br />
– Netzwerkorientierte Lösung für NetzzuNetz Verkehr<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Historische Entwicklung<br />
● Erste verbreitete Version <strong>SSL</strong>v2, noch mit<br />
Sicherheitsproblemen (Autor: Netscape)<br />
● Erheblich überarbeitetes Protokoll <strong>SSL</strong>v3 (Netscape)<br />
● IETF Standard RFC2246 als <strong>TLS</strong>v1 (entsprechend<br />
„<strong>SSL</strong>v3.1“) Januar 1999<br />
● Ergänzungen (z. B. AES in RFC3268) zugefügt<br />
● <strong>TLS</strong>v1.1 als RFC4346 seit April 2006<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Grundeigenschaften<br />
● <strong>TLS</strong> ist verbindungsorientiert (anders als IPsec/VPN)<br />
● <strong>TLS</strong> setzt auf einer bestehenden Verbindung auf<br />
● <strong>TLS</strong> verlangt eine zuverlässige Verbindung<br />
(Vollständigkeit und Reihenfolge der Datenpakete<br />
müssen garantiert sein)<br />
● <strong>TLS</strong> stellt genau einen Kanal in der Verbindung bereit,<br />
es gibt also kein Multiplexing oder zusätzliche Tunnel<br />
(anders als SSH)<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Separate Ports<br />
● Die ersten Protokolle, die mit <strong>SSL</strong> ergänzt wurden,<br />
erhielten separate Ports:<br />
– https (port 443) statt http (port 80)<br />
– pop3s (port 995) statt pop (port 110)<br />
– <strong>im</strong>aps (port 993) statt <strong>im</strong>ap4 (port 143)<br />
– smtps (port 465) statt smtp (port 25)!?<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Separate Vorschaltprozesse<br />
● Direkt<br />
Client Process<br />
socket<br />
--------------<br />
|<br />
-------------socket<br />
Server Process<br />
● Mit <strong>TLS</strong><br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin<br />
Client Process<br />
socket<br />
-------------socket<br />
„stunnel“<br />
socket<br />
--------------<br />
|<br />
-------------socket<br />
„stunnel“<br />
socket<br />
-------------socket<br />
Server Process
<strong>TLS</strong>: Separate Ports/Prozesse<br />
● Separate Ports gestatten es, <strong>TLS</strong>/<strong>SSL</strong> ProtokollHandling<br />
in separate Prozesse auszulagern<br />
● Separate Prozesse erlauben ein höheres<br />
Sicherheitsniveau<br />
● Separate Prozesse erschweren es dem Serverprozeß,<br />
Informationen über den Client zu sammeln<br />
● Separate Ports verschlingen zu viele „Well Known“<br />
Ports<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Protokollintegration<br />
● Neuere Definitionen integrieren einen START<strong>TLS</strong><br />
Befehl in die Protokolle:<br />
– RFC2487/3207: START<strong>TLS</strong> for ESMTP<br />
– RFC2817: „Upgrade: <strong>TLS</strong>/1.0“ for HTTP/1.1<br />
– RFC2595: START<strong>TLS</strong> for IMAP4<br />
– RFC2595: S<strong>TLS</strong> for POP3<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Algorithmen<br />
● <strong>TLS</strong> definiert einen Satz von Algorithmen<br />
DHEDSSAES256SHA <strong>SSL</strong>v3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1<br />
AES256SHA <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
EDHRSADESCBC3SHA <strong>SSL</strong>v3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1<br />
EDHDSSDESCBC3SHA <strong>SSL</strong>v3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1<br />
DESCBC3SHA <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
DESCBC3MD5 <strong>SSL</strong>v2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5<br />
DHERSAAES128SHA <strong>SSL</strong>v3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1<br />
DHEDSSAES128SHA <strong>SSL</strong>v3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1<br />
AES128SHA <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
IDEACBCSHA <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1<br />
IDEACBCMD5 <strong>SSL</strong>v2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5<br />
RC2CBCMD5 <strong>SSL</strong>v2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5<br />
DHEDSSRC4SHA <strong>SSL</strong>v3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1<br />
RC4SHA <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1<br />
RC4MD5 <strong>SSL</strong>v3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5<br />
RC4MD5 <strong>SSL</strong>v2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5<br />
...<br />
...<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Auswahl der Algorithmen<br />
● Der Client sendet eine Liste der von ihm unterstützten<br />
Algorithmen, sortiert nach seinen Präferenzen<br />
● Der Server wählt aus dieser Liste einen Algorithmus aus<br />
– Open<strong>SSL</strong> folgt dabei den Präferenzen des Clients<br />
– Open<strong>SSL</strong> 0.9.7API würde auch ermöglichen, Präferenzen des<br />
Servers zu verwenden<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Symmetrische Verschlüsselung<br />
● Symmetrische Verfahren (DES, AES, RC4) sind schnell<br />
● Beide Seiten haben den gleichen gehe<strong>im</strong>en Schlüssel, <strong>im</strong><br />
Wesentlichen eine Zufallszahl<br />
● Der Schlüssel wird aus dem „Premaster Secret“<br />
gewonnen, das der Client während des Handshakes<br />
generiert und zum Server schickt<br />
– Der Client muß über einen guten Zufallsgenerator verfügen<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Handshake ohne DHE<br />
● Client sendet „Hello“ mit Liste der Algorithmen<br />
● Server sendet Antwort mit seinem Zertifikat<br />
– Zertifikat enthält Identifikation<br />
– Zertifikat enthält öffentlichen RSASchlüsselteil<br />
● Client sendet „Premaster Secret“ verschlüsselt mit dem<br />
öffentlichen Schlüssel des Servers<br />
– Server entschlüsselt das Secret mit seinem privaten RSA<br />
Schlüssel. Wenn er dies kann, hat er sich authentifiziert<br />
– Jeder andere, der den privaten RSASchlüssel hat, kann das<br />
Secret auch entschlüsseln und mitlesen (man ssldump :)<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Handshake mit DHE<br />
● Client sendet „Hello“ mit Liste der Algorithmen<br />
● Server sendet Antwort mit Zertifikat und DHSchlüssel<br />
– Zertifikat enthält Identifikation (und öffentlichen RSASchlüssel)<br />
– Öffentlicher DHSchlüssel signiert mit privatem RSASchlüssel<br />
– DHSchlüssel wird vom Server jeweils frisch generiert<br />
● Client sendet „Premaster Secret“ verschlüsselt mit dem<br />
öffentlichen DHSchlüssel des Servers<br />
– Server entschlüsselt das Secret mit seinem privaten DHSchlüssel<br />
– Ein anderer, der den privaten RSASchlüssel hat, kann das Secret<br />
nicht entschlüsseln, da ihm der DHSchlüssel unbekannt bleibt<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Vor/Nachteile von DHE<br />
● DiffieHellman Exchange<br />
– Erfordert gute Zufallszahlen auch be<strong>im</strong> Server<br />
– Erfordert zusätzliche Rechenzeit durch Schlüsselgenerierung<br />
und zusätzliche private Schlüsseloperationen am Server<br />
– Bietet „Forward Secrecy“ da auch be<strong>im</strong> Bekanntwerden des<br />
privaten RSASchlüssels des Servers keine Entschlüsselung<br />
möglich ist<br />
– Erlaubt nur das Entschlüsseln je einer Sitzung, deren Schlüssel<br />
bekannt geworden ist<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
● X.509 Zertifikate enthalten<br />
X.509 Zertifikate<br />
– Informationen über ein Objekt (Server, Person)<br />
– Ggf. zusätzliche Information, z. B. Rechte<br />
– Den öffentlichen Schlüssel (zumeist RSA) des Objekts<br />
● Eine Bestätigung („Zertifikat“), daß alle Angaben<br />
zusammengehören und passen<br />
● Eine Information über den Aussteller<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
X.509 Zertifikate: Modell<br />
● Personalausweis enthält<br />
– Bild<br />
– Name, Geburtstag, Wohnort<br />
● Stempel bzw. Unterschrift zur Bestätigung der<br />
Zusammengehörigkeit dieser Informationen<br />
● Eine Information über den Aussteller (z. B.<br />
Einwohnermeldeamt<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
X.509 Zertifikate: Beispiel<br />
● openssl x509 text in serv01_cert.pem<br />
Certificate:<br />
Data:<br />
Version: 3 (0x2)<br />
Serial Number: 8426 (0x20ea)<br />
Signature Algorithm: md5WithRSAEncryption<br />
Issuer: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet Cottbus, OU=Rechenzentrum, CN=BTU<br />
CA (20042008)/emailAddress=cabtu@tucottbus.de<br />
Validity<br />
Not Before: May 4 14:31:03 2004 GMT<br />
Not After : Jun 4 14:31:03 2006 GMT<br />
Subject: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet Cottbus, OU=Lehrstuhl Allgemeine<br />
Elektrotechnik und Num. Feldberechnung, CN=serv01.aet.tucottbus.de/emailAddress=postmaster@serv01.aet.tucottbus.de<br />
Subject Public Key Info:<br />
Public Key Algorithm: rsaEncryption<br />
RSA Public Key: (2048 bit)<br />
Modulus (2048 bit):<br />
00:97:c1:f8:aa:d8:50:52:67:36:2a:48:d0:27:53: ...<br />
Exponent: 65537 (0x10001)<br />
X509v3 extensions:<br />
X509v3 Basic Constraints:<br />
CA:FALSE<br />
X509v3 Key Usage:<br />
Digital Signature, Key Encipherment<br />
X509v3 Subject Alternative Name:<br />
email:postmaster@serv01.aet.tucottbus.de<br />
X509v3 CRL Distribution Points:<br />
URI:http://WWW.RZ.TUCottbus.De/CA/20042008/btuca.crl<br />
Netscape Cert Type:<br />
<strong>SSL</strong> Server<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
X.509 Zertifikate: Beispiel<br />
● DN Distinguished Name des Objekts<br />
– Subject: C=DE, ST=Brandenburg,<br />
L=Cottbus, O=Brandenburgische<br />
Technische Universitaet Cottbus,<br />
OU=Lehrstuhl Allgemeine<br />
Elektrotechnik und Num.<br />
Feldberechnung,<br />
CN=serv01.aet.tucottbus.de/emailAddress<br />
Darstellung (,/= usw) durch Programm, nicht <strong>im</strong> Zertifikat kodiert!<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
X.509 Zertifikate: Beispiel<br />
● DN Distinguished Name des Ausstellers<br />
– Issuer: C=DE, ST=Brandenburg,<br />
L=Cottbus, O=Brandenburgische<br />
Technische Universitaet Cottbus,<br />
OU=Rechenzentrum, CN=BTUCA (2004<br />
2008)/emailAddress=cabtu@tucottbus.de<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
● Extensions<br />
X.509 Zertifikate: Beispiel<br />
– X509v3 Basic Constraints:<br />
● CA:FALSE<br />
– X509v3 Key Usage:<br />
● Digital Signature, Key Encipherment<br />
– X509v3 Subject Alternative Name:<br />
● email:postmaster@serv01.aet.tucottbus.de<br />
– X509v3 CRL Distribution Points:<br />
● URI:http://WWW.RZ.TUCottbus.De/CA/2004<br />
2008/btuca.crl<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
X.509 Zertifikate: Probleme<br />
● Es gibt nur einen CN CommonName<br />
– Lösung: Verwendung des Subject Alternative Names<br />
– Hier sind mehrere dNSNameEinträge möglich<br />
● Es gibt mehr als einen CN CommonName<br />
– Die meisten Applikationen verwenden aber nur den Ersten...<br />
● Zertifizierungsstelle (CA) sind nicht unumstritten<br />
– Verwendung einer eigenen CA hat Vor und Nachteile<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Durchsatz/Performance<br />
● Durchsatz wird durch symmetrischen Algorithmus<br />
best<strong>im</strong>mt und sollte <strong>im</strong>mer gut genug sein<br />
● Der Handshake ist sehr aufwendig, da Operationen mit<br />
den privaten Schlüsseln notwendig sind (Signieren,<br />
Entschlüsseln)<br />
● Problem von HTTPS bekannt, da dort viele<br />
Verbindungen aufgebaut werden müssen<br />
● Lösung: <strong>TLS</strong> Session Caching<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
<strong>TLS</strong>: Session Caching<br />
● Nach erfolgreichem Handshake werden gespeichert:<br />
– Authentifizierungsdaten und status der Gegenstelle<br />
– Ausgehandelte kryptographische Algorithmen<br />
– PremasterSecret<br />
● Damit kann eine neue Verbindung unter Verwendung<br />
der alten „Session“ ohne teuren Handshake aufgebaut<br />
werden (nacheinander oder parallel)<br />
● Aufwand <strong>im</strong>mer noch hoch, vgl. SMTP Session Caching<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong> Protokoll<br />
● ESMTP (Enhanced SMTP) wird um START<strong>TLS</strong> Option<br />
und Befehl erweitert (RFC2487/3207)<br />
● START<strong>TLS</strong> wird in der EHLOAntwort aufgelistet<br />
● START<strong>TLS</strong> wird vom Client geschickt<br />
● Server antwortet (mit 220 Go on...)<br />
● <strong>TLS</strong>Handshake wird ausgeführt<br />
● SMTPVerbindung wird fortgesetzt mit EHLO<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong>: Sicherheit<br />
● Die EHLOAntwort könnte verfälscht worden sein.<br />
Daher darf ein Client auch START<strong>TLS</strong> senden, wenn<br />
kein START<strong>TLS</strong> angeboten wurde<br />
● Der Client muß prüfen, ob das Zertifikat der Gegenstelle<br />
den Erwartungen entspricht<br />
– Was sind die Erwartungen?<br />
● Nach dem START<strong>TLS</strong> wird ein neues EHLO abgesetzt,<br />
da<br />
– die erste EHLOAntwort verfälscht sein könnte<br />
– der Server mit <strong>TLS</strong> andere Optionen anbieten könnte<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong>: Beispiel 1<br />
● telnet serv01.aet.tucottbus.de 587<br />
220 serv01.aet.tu-cottbus.de ESMTP Postfix<br />
EHLO lutzpc<br />
250-serv01.aet.tu-cottbus.de<br />
250-PIPELINING<br />
250-SIZE 60000000<br />
250-VRFY<br />
250-ETRN<br />
250-START<strong>TLS</strong><br />
250 8BITMIME<br />
START<strong>TLS</strong><br />
220 Ready to start <strong>TLS</strong><br />
...<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong>: Beispiel 2<br />
● openssl s_client starttls smtp connect serv01.aet.tucottbus.de:587<br />
...<br />
220 serv01.aet.tu-cottbus.de ESMTP Postfix<br />
EHLO lutz<br />
250-serv01.aet.tu-cottbus.de<br />
250-PIPELINING<br />
250-SIZE 60000000<br />
250-VRFY<br />
250-ETRN<br />
250-AUTH LOGIN PLAIN<br />
250 8BITMIME<br />
...<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong>: Authentifizierung<br />
● Bei <strong>TLS</strong> wird zwingend das Zertifikat des Servers<br />
übertragen<br />
● Algorithmen ohne ServerZertifikat sind in Open<strong>SSL</strong> per<br />
default abgeschaltet<br />
● Algorithmen ohne ServerZertifikat können von der<br />
jeweiligen Applikation aber aktiviert werden<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
START<strong>TLS</strong>: Authentifizierung<br />
● Der Client kann ein Zertifikat übersenden, wenn der<br />
Server ihn dazu auffordert<br />
– Der Server liefert eine Liste der ihm bekannten CAs mit<br />
– Open<strong>SSL</strong>Client ist nicht standardkonform und sendet „das“<br />
konfigurierte Zertifikat, auch wenn keine passende CA<br />
gefunden wurde<br />
– Automatische Auswahl eines „richtigen“ ClientZertifikats<br />
schwer zu <strong>im</strong>plementieren, da die komplette Chain passen muß<br />
● Authentifizierung mit ClientZertifikaten <strong>im</strong><br />
START<strong>TLS</strong>Standard nicht durchdacht<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix und <strong>TLS</strong><br />
● Die Integration von <strong>TLS</strong> in Postfix beeinflußt 3<br />
Hauptkomponenten:<br />
– smtpd (eingehende Verbindungen)<br />
– smtp (ausgehende Verbindungen)<br />
– tlsmgr (Hilfsfunktionen)<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
● Struktur:<br />
Postfix und <strong>TLS</strong><br />
<br />
Network-> smtpd(8) tlsmgr(8) smtp(8) ->Network<br />
<br />
/ | \<br />
|<br />
/ \<br />
smtpd PRNG smtp<br />
session state session<br />
key cache file key cache<br />
(Source: Wietse Venema: Postfix 2.2, <strong>TLS</strong>_README)<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtpd<br />
● smtpd wurde erweitert, um das START<strong>TLS</strong>Protokoll zu<br />
unterstützen<br />
● Nach erfolgreichem START<strong>TLS</strong>Handshake wird<br />
<strong>SSL</strong>_accept() aufgerufen<br />
● Bei erfolgreichem <strong>TLS</strong>Handshake wird Verbindung<br />
verschlüsselt weitergeführt<br />
● Bei HandshakeFehler ist der Status der Gegenstelle<br />
unbekannt und die Verbindung muß abgebrochen<br />
werden<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtpd Optionen<br />
● smtpd_tls_cert_file, smtpd_tls_key_file<br />
– enthalten den öffentlichen und privaten Schlüssel<br />
● smtpd_tls_CAfile, smtpd_tls_CApath<br />
– enthalten File bzw. Verzeichnis mit CAListe<br />
● smtpd_tls_security_level<br />
– aktivieren (may) bzw. erzwingen (encrypt) <strong>TLS</strong> global<br />
● smtpd_tls_session_cache_database<br />
– Datenbank mit <strong>TLS</strong> session cache (per tlsmgr)<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtpd Optionen<br />
● smtpd_tls_loglevel<br />
– Ausgaben <strong>im</strong> Level 14, empfohlen 1<br />
● smtpd_tls_received_header<br />
– Ausgabe der <strong>TLS</strong>Informationen <strong>im</strong> Header<br />
● smtpd_tls_auth_only<br />
– Unterstütze AUTH nur für <strong>TLS</strong> geschützte Verbindungen<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtpd Optionen<br />
● smtpd_tls_ask_ccert, smtpd_tls_req_ccert<br />
– erfragen bzw. erfordern eines Client Zertifikats<br />
● relay_clientcerts, permit_tls_clientcerts,<br />
permit_tls_allclientcerts, check_ccert_access<br />
– Freigabe für MailWeiterleitung basierend auf Client<br />
Zertifikat, Datenbank/Tabelle mit Fingerprints<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtp<br />
● smtp wurde erweitert, um das START<strong>TLS</strong>Protokoll zu<br />
unterstützen<br />
● Nach erfolgreichem START<strong>TLS</strong>Handshake wird<br />
<strong>SSL</strong>_connect() aufgerufen<br />
● Bei erfolgreichem <strong>TLS</strong>Handshake wird Verbindung<br />
verschlüsselt weitergeführt<br />
● Bei HandshakeFehler ist Status der Gegenstelle<br />
unbekannt und die Verbindung muß abgebrochen<br />
werden<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtp Optionen<br />
● smtp_tls_cert_file, smtp_tls_key_file<br />
– Öffentlicher bzw. privater Schlüssel<br />
● smtp_tls_CAfile, smtp_tls_CApath<br />
– Datei bzw. Verzeichnis mit CAZertifikaten<br />
● smtp_tls_security_level<br />
– Benutze <strong>TLS</strong> wenn angeboten (may) oder <strong>im</strong>mer (encrypt)<br />
– Mit Prüfung des ServerZertifikats (verify/secure)<br />
● smtp_tls_policy_maps<br />
– Auswahl von <strong>TLS</strong>Benutzung nach Ziel<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: smtp Optionen<br />
● smtp_tls_session_cache_database<br />
– Datenbank mit SessionInformationen (via tlsmgr)<br />
● smtp_tls_loglevel<br />
– Ausgabe mit Level 14, empfohlen 1<br />
● smtp_tls_note_starttls_offer<br />
– Logge Informationen, welche Server START<strong>TLS</strong> angeboten<br />
hätten<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix: tlsmgr<br />
● tlsmgr verwaltet Session Cache Datenbanken<br />
– Datenbanken würde ohne Grenze wachsen<br />
– tlsmgr läuft regelmäßig durch die Datenbanken und löscht alte<br />
Einträge<br />
– Synchronisation erfolgt durch tlsmgr, welcher als einziger auf<br />
die Datenbanken zugreift<br />
● tlsmgr koordiniert auch den Zugriff auf<br />
Zufallsgeneratoren<br />
– nur nötig bei EGD mit begrenztem Vorrat<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
Postfix/<strong>TLS</strong>: Geschichte<br />
● Ursprünglich entwickelt für spezielles Problem<br />
– Postfix/<strong>TLS</strong> 0.1.0: März 1999<br />
● Entwicklung zur „FullyFeatured“ Ergänzung<br />
– Wesentliche Entwicklungen: 19992002<br />
– Pflege und Anpassung: 20032004<br />
● Integration in Postfix „Main Stream“<br />
– Postfix 2.2: März 2005<br />
– Inzwischen gepflegt durch Wietse Venema & Victor Duchovni<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
● Open<strong>SSL</strong><br />
– http://www.openssl.org/<br />
● <strong>SSL</strong>dump<br />
Tools<br />
– http://www.rtfm.com/ssldump/<br />
● Stunnel<br />
– http://www.stunnel.org/<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin
● OpenSource Projekte<br />
lutz@lutzjaenicke.de<br />
http://www.lutzjaenicke.de/<br />
● Firmenkontakt<br />
Dr. Lutz Jänicke<br />
Kontaktdaten<br />
Innominate Security Technologies AG<br />
AlbertEinsteinStraße 14<br />
12489 Berlin<br />
ljaenicke@innominate.com<br />
http://www.innominate.com/<br />
Lutz Jänicke: Postfix: <strong>SSL</strong>/<strong>TLS</strong> <strong>im</strong> <strong>Detail</strong>. 3. MailserverKonferenz, 2./3. Juli 2007, Berlin