Re: [postfix-users] TLS von MTA zu MTA
Am 09.08.2013 15:40, schrieb Florian Streibelt:
Am Fr, 09.08.13 um 14:30:38 Uhr schrieb Robert Schetterer rs@sys4.de:
Am 09.08.2013 14:15, schrieb Jochen:
Hallo,
seit dem PRISM-Skandal macht man sich natürlich Gedanken, wie man die staatliche Schnüffelei weitestgehend unterbinden kann. Ist es mit möglich (und sinnvoll) eine TLS-Verschlüsselung zwischen 2 MTAs zu erzwingen? Wenn ja, wie müsste man das in seinem Postfix konfigurieren, sodass niemals unverschlüsselt Mails ausgetauscht werden?
das musst du am Ende selbst entscheiden die Frage ist ,ob du noch am allgemeinen unverschluesselten Mailverkehr teilnehmen willst oder nicht, du kannst andere nicht per se zur Verschluesselung zwingen
Es gibt noch ein weitaus größeres Problem - die passenden Zertifikate.
Ich hab grade keine Zeit für eine ausführliche Antwort, daher nur grob.
Es gibt ja gerade diese 'Email made in Germany Aktion' - da versuchen sie genau das.
http://www.heise.de/newsticker/meldung/E-Mail-Made-in-Germany-SSL-Verschlues...
Das skaliert aber nicht, und spiegelt m.E. eine Sicherheit vor die nicht da ist und sperrt wieder mal kleinere Anbieter aus, deren Mails als nicht sicher angezeigt werden.
Marketing Fasel...., und die "Anzeige" wuerde ja erstmal nur in deren Webmail zu sehen sein, mal ehrlich wer nutzt das schon, wenn er gerade nicht muss, es ist eher peinlich fuer diese Firmen ,wenn man es genau nimmt, dass sie nicht schon immer die Uebertragung verschluesselten,falls es moeglich war.
Microsoft hat mit Exchange auch so einen Modus , als besonderes neues Feature angepriesen hat wie immer nur einen einen tollen neuen Namen dafuer erfunden und die Anzeige geht natuerlich nur mit Outlook und Exchange....ich befuerchte es gibt sogar Admins die das als neues Killerfeature ansehen *g
Zum einen sind da draußen hundertausende Mailserver, die keine 'offiziellen' Zertifikate von einer 'anerkannten' CA haben. Meine auch nicht, ich benutze CaCert Zertifikate und habe auch nicht vor das zu ändern, da es kein mehr an Sicherheit bietet.
Spätestens seit DigiNotar wissen wir, wie kaputt das CA-System ist. Und das kann man auch nicht reparieren - da jede CA prinzipbedingt für jede Domain ein Zertifikat ausstellen kann. Damit ist es dann eben möglich, dass China Telekom oder Türktrust oder eine 'vertrauenswürdige' CA in den USA ein Zertifikat für eine Domain Deiner Wahl ausstellt.
Wenn Du also den 'anerkannten' CAs traust kann die NSA immer noch ein mitm machen - du müsstest schon manuell die ZErtifikatsprüfsummen pflegen.
Und selbst wenn das nicht so kaputt wäre, was macht man mit den Leuten die kein TLS anbieten? Auch weil sie sich kein Zertifikat leisten wollen - und wie bekommt man raus wer kein TLS anbietet und bei wem von außen die TLS verhandlung unterbunden wird?
Grüße, Florian
also ich hab jahrelang selbst produzierte ssl crts verwendet, ich hab zwar nicht gelogged wer die alles akzeptierte, aber ich kann mich eigentlich nicht daran erinnern dass sie massenhaft abgelehnt wurden, ich gehe davon aus dass die meisten es pragmatisch handhaben und eben nach dem Motto verfahren besser ein selbst gemachtes crt und verschluesseln als gar nicht, einfach ausprobieren und mitloggen
Am Ende sollte die Email selbst aber auch verschluesselt sein ( pgp,smime etc ) sonst ist es eh immer eine "Scheinsicherheit"
Wer ganz sicher gehen will sollte ausserdem auf Open Source Betriebssysteme setzen *g
Best Regards MfG Robert Schetterer
Am 2013-08-09 17:31, schrieb Robert Schetterer:
Am 09.08.2013 15:40, schrieb Florian Streibelt:
[..] Und selbst wenn das nicht so kaputt wäre, was macht man mit den Leuten die kein TLS anbieten? Auch weil sie sich kein Zertifikat leisten wollen - und wie bekommt man raus wer kein TLS anbietet und bei wem von außen die TLS verhandlung unterbunden wird? [..]
also ich hab jahrelang selbst produzierte ssl crts verwendet, ich hab zwar nicht gelogged wer die alles akzeptierte, aber ich kann mich eigentlich nicht daran erinnern dass sie massenhaft abgelehnt wurden, ich gehe davon aus dass die meisten es pragmatisch handhaben und eben nach dem Motto verfahren besser ein selbst gemachtes crt und verschluesseln als gar nicht, einfach ausprobieren und mitloggen
Apropos - ich hab dann grade auch noch mal in mein Log geschaut. Und dabei hätt' ich mal gerne ne Frage ;-)
Mails raus an bspw. web.de sehen total super aus:
Aug 9 17:46:12 mail2 postfix/smtp[15152]: Trusted TLS connection established to mx-ha02.web.de[213.165.67.120]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aber rein steht (auch bei *allen* anderen eingehenden ESMTPS Serververbindungen):
Aug 9 16:29:27 mail2 postfix/smtpd[29718]: Anonymous TLS connection established from mout.web.de[212.227.15.3]: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
Ich beziehe mich hier auf den Unterschied "Trusted TLS connection" zu "Anonymous TLS connection". Müsste dort nicht irgendwann auch mal "Trusted" stehen...? Wie gesagt - das steht *nie* da. Oder fehlt mir was in der Konfiguration bei smtpd_tls_* ?
smtpd_tls_security_level = may smtpd_tls_CAfile = /etc/postfix/ssl/StartSSL_chain.pem smtpd_tls_CApath = /etc/ssl/certs/ smtpd_tls_cert_file = /etc/postfix/ssl/cert.crt smtpd_tls_key_file = /etc/postfix/ssl/cert.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes
Das Zertifikat ist von StartSSL - also nicht ganz so "unakzeptiert" wie ein's von CACert ;)
Ich *glaube* was fehlen würde wäre "smtpd_tls_ask_ccert=yes" - lasse mich aber von dem Satz: | Additionally some MTAs (notably some versions of qmail) are unable to complete | TLS negotiation when client certificates are requested, and abort the SMTP session. | So this option is "off" by default etwas einschüchtern das auf einem public MX zu aktivieren..
Grüsse Christian
Am Fr, 09.08.13 um 18:32:12 Uhr schrieb Christian Bricart christian@bricart.de:
Mails raus an bspw. web.de sehen total super aus:
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
jop, ist sogar diffie hellman key exchange bei.
Aber rein steht (auch bei *allen* anderen eingehenden ESMTPS Serververbindungen):
Ich beziehe mich hier auf den Unterschied "Trusted TLS connection" zu "Anonymous TLS connection". Müsste dort nicht irgendwann auch mal "Trusted" stehen...? Wie gesagt - das steht *nie* da.
IMHO:
Da du das Zertifikat des Clients nicht kennst ist der anonymous für Dich in Deiner Rolle als Server. Du authentifizierst ja den remote server nicht direkt wie ein Client Zertifikat im Browser eines users.
Ich *glaube* was fehlen würde wäre "smtpd_tls_ask_ccert=yes" - lasse mich aber von dem Satz: | Additionally some MTAs (notably some versions of qmail) are unable to complete | TLS negotiation when client certificates are requested, and abort the SMTP session. | So this option is "off" by default etwas einschüchtern das auf einem public MX zu aktivieren..
Genau, ich gehe auch davon aus, dass das ausschliesslich benutzt wird, damit Du nur noch Verbindungen von servern annimmst, die ein valides ZErtifikat präsentieren - alle anderen machen dann entweder nen fallback auf plain oder sehen das als error und stellen nicht zu.
Das will man in der Regel beides nicht.
Die Verwendung von CAs dafür ist... naja... unpraktisch. Besser wäre da DNSSEC und ein fingerprint des keys im DNS - wenn man denn dnssec vertraut. *sigh*
/Florian
Am 09.08.2013 23:47, schrieb Florian Streibelt:
ie Verwendung von CAs dafür ist... naja... unpraktisch. Besser wäre da DNSSEC und ein fingerprint des keys im DNS - wenn man denn dnssec vertraut. *sigh*
da ist was in Arbeit, ich hab grad nur keine url fuer den Patch parat
Best Regards MfG Robert Schetterer
* Robert Schetterer rs@sys4.de:
Am 09.08.2013 23:47, schrieb Florian Streibelt:
ie Verwendung von CAs dafür ist... naja... unpraktisch. Besser wäre da DNSSEC und ein fingerprint des keys im DNS - wenn man denn dnssec vertraut. *sigh*
da ist was in Arbeit, ich hab grad nur keine url fuer den Patch parat
Ich denke, Robert bezieht sich auf DANE, für das Viktor im Moment Code für Postfix entwickelt. Er hat auch einen RFC Draft eingereicht, der vorletzten Donnerstag in Berlin auf dem IETF-Treffen https://datatracker.ietf.org/meeting/87/agenda/dane/ in einer Session besprochen wurde: http://tools.ietf.org/wg/pwe3/minutes
p@rick
* Patrick Ben Koetter postfix-users@de.postfix.org:
- Robert Schetterer rs@sys4.de:
Am 09.08.2013 23:47, schrieb Florian Streibelt:
ie Verwendung von CAs dafür ist... naja... unpraktisch. Besser wäre da DNSSEC und ein fingerprint des keys im DNS - wenn man denn dnssec vertraut. *sigh*
da ist was in Arbeit, ich hab grad nur keine url fuer den Patch parat
Ich denke, Robert bezieht sich auf DANE, für das Viktor im Moment Code für Postfix entwickelt. Er hat auch einen RFC Draft eingereicht, der vorletzten Donnerstag in Berlin auf dem IETF-Treffen https://datatracker.ietf.org/meeting/87/agenda/dane/ in einer Session besprochen wurde: http://tools.ietf.org/wg/pwe3/minutes
Sorry, hatten den falschen Link zu den minutes kopiert. Die minutes für DANE scheinen mir nicht online zu sein. Stattdessen den Link auf das aktuell gültige Draft von Viktor: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01
p@rick
participants (4)
-
Christian Bricart
-
Florian Streibelt
-
Patrick Ben Koetter
-
Robert Schetterer