Am 09.08.2013 14:30, schrieb Robert Schetterer:

schau mal evtl http://sys4.de/de/blog/2013/03/27/uebermittlungssicherheit-mit-mailservern-p... Best Regards MfG Robert Schetterer

Danke, der Artikel hilft mehr sehr!

Am 09.08.2013 16:34, schrieb Florian Streibelt:

Zudem liegen die Emails dann wieder unverschlüsselt bei den jeweiligen Anbietern. Damit spiegelt es den Anwendern eine Sicherheit vor die nicht da ist.

Ich denke das ist das geringere Problem, da heutzutage die Mails direkt, ohne Beteiligung weiterer MTAs, zum MTA des Empfängers zugestellt werden. Wie der sein System vor fremdem Zugriff schützt ist Sache des Empfängers.

Wie wir von Snowden gelernt haben, zapfen die Geheimdienste ihre Daten aber an den Internet Knoten und Backbones ab, und da würde eine TLS-Verschlüsselung schon viel verhindern.

Um es wirklich sicher zu bekommen, also so, dass sich der Aufwand auch lohnt, muss man leider zu echter Ende zu Ende Verschlüsselung greifen, also gpg oder wenns sein muss s/mime.

Das schützt aber leider nur den Inhalt, nicht die Metadaten. Und die scheinen den Geheimdiensten momentan das wichtigste zu sein.

Sicher ist nur eine Kombination aus beidem: verschlüsselter Inhalt, und verschlüsselter Transport. Wobei man den Inhalt nicht immer verschlüsseln kann. Versuche mal mit einem Versandhändler oder einer Bank verschlüsselt zu kommunizieren.

Am 11.08.2013 15:58, schrieb Jochen:

Am 09.08.2013 14:30, schrieb Robert Schetterer:

...

schau mal evtl

http://sys4.de/de/blog/2013/03/27/uebermittlungssicherheit-mit-mailservern-p...

Woran erkenne ich denn nun ob auch tatsächlich verschlüsselt übertragen wird?

Hieran?

Aug 11 08:01:31 server postfix/smtpd[6048]: setting up TLS connection from indium.canonical.com[91.189.90.7] Aug 11 08:01:32 server postfix/smtpd[6048]: Anonymous TLS connection established from indium.canonical.com[91.189.90.7]: TLSv1 with cipher AES256-SHA (256/256 bits)

jo, das sieht schonmal gut aus

---

postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users

Best Regards MfG Robert Schetterer

Am 11.08.2013 18:12, schrieb Jochen:

Am 11.08.2013 17:14, schrieb Robert Schetterer:

...

...

Aug 11 08:01:31 server postfix/smtpd[6048]: setting up TLS connection from indium.canonical.com[91.189.90.7] Aug 11 08:01:32 server postfix/smtpd[6048]: Anonymous TLS connection established from indium.canonical.com[91.189.90.7]: TLSv1 with cipher AES256-SHA (256/256 bits)

jo, das sieht schonmal gut aus

Komisch ist nur, wenn ich Mails an web.de sende taucht sowas nicht auf. Nur:

Aug 11 16:41:38 server postfix/smtp[22163]: 6E3AA14A64: to=xxx@web.de, relay=mx-ha02.web.de[213.165.67.120]:25, delay=1.4, delays=0.59/0.46/0.14/0.26, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=0MK0Cn-1V79vT1htF-001TFI)

Wollten die nicht jetzt auch TLS anbieten? _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users

ich hab mal nachgesehen fuer 213.165.67.120 sieht gut aus bei mir

Aug 11 17:43:54 mail02 postfix/smtp[27062]: Trusted TLS connection established to mx-ha02.web.de[213.165.67.120]:25: TLSv1 with cipher AES256-SHA (256/256 bits)

allerdings koennte der Mailserver auch hinter loadbalancer stehen die wechselweise eben tls anbieten oder nicht

mach mal grep 213.165.67.120 /var/log/mail.log etc evtl hast du was uebersehen

hast du sowas in main.cf ?

smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes

smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes

Best Regards MfG Robert Schetterer

Am 11.08.2013 20:48, schrieb Jochen Fahrner:

Jetzt fehlt mir wohl bloss noch ein Root-Zertifikat der Telekom.

Damit hab ich jetzt irgendwie Probleme. Ich hab mir das Root-Zertifikat bei der Telekom runtergeladen und nach /etc/ssl/certs kopiert. Dann c_rehash /etc/ssl/certs

In main.cf habe ich: smtp_tls_CApath = /etc/ssl/certs

Aber es bleibt immer noch bei dem "Untrusted" :-(

* Jochen Fahrner jf@fahrner.name:

Am 11.08.2013 20:59, schrieb Jochen Fahrner:

...

Aber es bleibt immer noch bei dem "Untrusted" :-(

Fehler gefunden. Der Postfix macht einen chroot nach /var/spool/postfix, deswegen findet er meine Zertifikate nicht.

Lösung: cat /etc/ssl/certs/*.pem > /var/spool/postfix/etc/ssl/certs/ca-certificates.crt

und dieses als CA-File eintragen.

Fehler gefunden, aber nicht ideal gelöst (wenn ich das anmerken darf).

Jetzt hast Du die Zertifikate in das chroot hineinkopiert. Da wären sie für einen Angreifer erreichbar, wenn er denn über Postfix ins chroot käme. Der Angreifer könnte die Certs manipulieren und Dir damit Schaden zufügen.

Sicherer wäre es, wenn Du die Certs folgendermaßen lädst:

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Das geht genauso, denn Postfix liest dieses File in seinen Prozess ein _bevor_ es ins chroot wechselt. Dort sind sie dann in Memory verfügbar und nur solange in Reichweite eines Angreifers wie der Prozess selbst lebt. Postfix läßt die Prozesse regelmäßig sterben. Das ist prinzipbedingt sicherer, als die Certs ins chroot zu legen.

Komischwerweise war die Datei schon vorhanden, mit Datum 30.7.2013.

Ich würde sie rauskicken und die main.cf vorher auf ungewollte Referenzen prüfen.

Scheint so als würde irgendein cronjob die gelegentlich erneuern. Fragt sich nur welcher, und wie? Nicht dass der meine manuell erzeugte Datei wieder zerschiesst.

Vielleicht steht es da:

$ man update-ca-certificates

p@rick

* Jochen Fahrner jf@fahrner.name:

Am 11.08.2013 22:04, schrieb Patrick Ben Koetter:

...

Sicherer wäre es, wenn Du die Certs folgendermaßen lädst:

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Das geht genauso, denn Postfix liest dieses File in seinen Prozess ein _bevor_ es ins chroot wechselt. Dort sind sie dann in Memory verfügbar und nur solange in Reichweite eines Angreifers wie der Prozess selbst lebt. Postfix läßt die Prozesse regelmäßig sterben. Das ist prinzipbedingt sicherer, als die Certs ins chroot zu legen.

Offensichtllich nicht, siehe hier:

http://giantdorks.org/alain/fix-for-postfix-untrusted-certificate-tls-error/

$ zless /usr/share/doc/postfix/TLS_README.gz

..

The $smtp_tls_CAfile contains the CA certificates of one or more trusted CAs. The file is opened (with root privileges) before Postfix enters the optional chroot jail and so need not be accessible from inside the chroot jail.

Probier es aus. Wenn es nicht stimmt, dann eröffne einen Bug-Report für LaMont Jones, den Debian Postfix Maintainer.

p@rick

* Jochen Fahrner jf@fahrner.name:

Am 11.08.2013 22:40, schrieb Patrick Ben Koetter:

...

The $smtp_tls_CAfile contains the CA certificates of one or more trusted CAs. The file is opened (with root privileges) before Postfix enters the optional chroot jail and so need not be accessible from inside the chroot jail.

Probier es aus. Wenn es nicht stimmt, dann eröffne einen Bug-Report für LaMont Jones, den Debian Postfix Maintainer.

Hast Recht, er nimmt die Datei aus /etc/ssl/certs. Dann war mein Problem davor dass ich es mit CApath statt CAfile probiert hatte. Ich war

Ja, genau. Ich vermute, das der Autor des Blog-Eintrags auf den Du verwiesen hattest, dasselbe Problem hat/hatte.

eigentlich der Meinung dass er mit CApath die ganzen Einzel-PEM-Dateien aus dem Verzeichnis nimmt. Dem ist aber wohl nicht so. Mann ist das kompliziert! :-(

openssl geht davon aus, dass der Inhalt im Verzeichnis sich ändern kann und will deshalb live, über einen vorab gebildeten hash, nach certs suchen. Wenn Du alles in ein file packst, dann liest openssl das einmal ein. Änderungen im File übernimmt Postfix wenn der betroffene Prozess regelmäßig neu gestartet wird.

Wenn Du es jetzt auf Debian/Ubuntu - falls noch nicht geschehen - noch amtlich machen willst, fügst Du Postfix zur Gruppe ssl-cert hinzu:

# adduser postfix ssl-cert # postfix stop # postfix start # id postfix uid=116(postfix) gid=125(postfix) Gruppen=125(postfix),45(sasl),110(ssl-cert)

Mit den Gruppenrechten darf Postfix Debian-konform die certs und auch die keys (!) unterhalb /etc/ssl/ lesen:

# tree -ugp /etc/ssl/private/ /etc/ssl/private/ ├── [-rw------- root dovecot ] dovecot.pem ├── [-rw-r----- root ssl-cert] patrick.example.com.key └── [-rw-r----- root ssl-cert] ssl-cert-snakeoil.key

p@rick

Am 12.08.2013 08:47, schrieb Jochen Fahrner:

Am 12.08.2013 08:12, schrieb Patrick Ben Koetter:

...

Wenn Du es jetzt auf Debian/Ubuntu - falls noch nicht geschehen - noch amtlich machen willst, fügst Du Postfix zur Gruppe ssl-cert hinzu:

Ok, hab ich gemacht. Gruppe sasl fehlte auch.

Eins ist aber immer noch merkwürdig: Bei Mails zu web.de ist die Verbindung jetzt "Trusted" und ich sehe auch welches Root-CA benötigt wurde.

Zu den meisten anderen ist die Verbindung jedoch nur "untrusted" und es fehlt auch die Angabe des Root-CA. Kann das sein dass die Mehrzahl nur selfsigned Zertifikate besitzt?

Und auch seltsam: zu GMX bekomme ich outbound ein "Trusted", inbound aber nur "untrusted". Ist da bei mir noch was schief, oder bei GMX?

die Frage ist letztendlich wie wichtig ist dir trusted und untrusted

ssl crts koennen selbst gemacht sein oder sich aendern, willst du immer ( oder mehr ) trusted haben musst du im Zweifel die crts deiner Verbindungspartner importieren, distros liefern eher selten updates in dieser Hinsicht, der entscheidente Punkt ist aber letztendlich dass eben verschluesselt uebertragen wird, es ist deine Entscheidung welchen weiteren Level an Sicherheit du noch anwenden moechtest, bei "may" wird verschluesselt wenn beide Partner es anbieten, dabei ist es erstmal egal ob das crt "trusted" ist oder nicht, das ist fuer den normalen Alltag normalerweise ausreichend, willst du zusaetzlich zu bestimmten domains garantiert nur verschluesselt uebertragen nutze den Parameter

smtp_tls_policy_maps

http://sys4.de/de/blog/2013/03/27/uebermittlungssicherheit-mit-mailservern-p...

Das Ssl System setzt ja auf "Notare" die sozusagen die Identitaet versichern, die Frage heut zu Tage ist "glaubt" man den Notaren ist man paranoid wird man dies wohl mittlerweile verneinen deshalb ist ein selbst erstelltes crt erstmal auch in Ordnung, aus meiner Sicht ist vor allem eben wichtig das eine Verschluesselung stattfindet wenn moeglich.

insgesammt nicht ganz trivial das Thema ich hoffe ich habe so richtig wiedergegeben

Best Regards MfG Robert Schetterer

Am 12.08.2013 09:37, schrieb Jochen Fahrner:

Am 12.08.2013 09:24, schrieb Robert Schetterer:

...

Das Ssl System setzt ja auf "Notare" die sozusagen die Identitaet versichern, die Frage heut zu Tage ist "glaubt" man den Notaren ist man paranoid wird man dies wohl mittlerweile verneinen

Ja das stimmt leider. Kürzlich ist ja eine dieser Zertifizierungsstellen aufgeflogen, weil sie falsche Zertifikate ausgestellt hat. Mein Lieblings-CA, cacert.org, ist leider nirgendwo vorinstalliert, weil die nicht dafür bezahlen können/wollen.

meiner info nach ,gibts wenigstens ein paar linux distros die das cacert root crt mitausliefern

http://wiki.cacert.org/FAQ/ImportRootCert

... Linux

How your particular distribution will need to be modified to trust the CAcert root certificates will vary from one distribution to the next. However, there are some distributions about which we know some information, listed below.

Debian: Install the ca-certificates package.

Knoppix: CD versions newer than 3.8 have the certificates already. ...

Best Regards MfG Robert Schetterer

Am 12.08.2013 09:50, schrieb Martin Rabl:

Mozilla-Software hats auch nicht drin, wobei da CaCert immer noch irgendwie im Audit-Prozess mit denen drin steckt, dass das Root-Cert mit ausgliefert wird

Mein Wissensstand (von vor einem Jahr) ist, dass Mozilla (wie Microsoft auch) für die Auditierung Geld wollte und Cacert sich das nicht leisten konnte.

Ich finde das sowieso unmöglich, dass ein Software-Hersteller (wie Microsoft oder Mozilla) entscheidet was vertrauenswürdig ist, und was nicht (und dann auch noch Geld dafür einkassiert). Warum sollte ich (nur als Beispiel weil mir grad nix besseres einfällt) einer "Türktrust" vertrauen sollen? Eigentlich möchte ich das schon lieber selber entscheiden und nicht einfach vorgesetzt bekommen.

Wenn man sich die vorinstallierten Zertifizierungsstellen anschaut (das sind ja hunderte), dann muss man sich schon fragen wieviel schwarze Schafe darunter sind.

* Jochen Fahrner jf@fahrner.name:

Am 12.08.2013 08:12, schrieb Patrick Ben Koetter:

...

Wenn Du es jetzt auf Debian/Ubuntu - falls noch nicht geschehen - noch amtlich machen willst, fügst Du Postfix zur Gruppe ssl-cert hinzu:

Ok, hab ich gemacht. Gruppe sasl fehlte auch.

Eins ist aber immer noch merkwürdig: Bei Mails zu web.de ist die Verbindung jetzt "Trusted" und ich sehe auch welches Root-CA benötigt wurde.

Zu den meisten anderen ist die Verbindung jedoch nur "untrusted" und es fehlt auch die Angabe des Root-CA. Kann das sein dass die Mehrzahl nur selfsigned Zertifikate besitzt?

Ja, darauf würde ich jetzt mal ohne "die Mehrzahl" abgeklappert zu haben auch tippen. Den Meisten reicht es, wenn sie mit einer selbstsignierten, verschlüsselten Verbindung "Datenintegrität", "Privatsphäre" und ggf. "Zugangskontrolle" herstellen können. Auf "Authentizität" (Identität) legen sie scheinbar nicht denselben Wert.

Ob ein cert selfsigned ist, kannst du ggf. mit openssl auf der Kommandozeile nachvollziehen. Das hier ist selfsigned:

$ openssl s_client -starttls smtp -CAfile /etc/ssl/certs/ca-certificates.crt -connect mail.sy4.de:25

... Verify return code: 18 (self signed certificate) ...

Das hier passt:

$ openssl s_client -starttls smtp -CAfile /etc/ssl/certs/ca-certificates.crt -connect mail.sys4.de:25

... Verify return code: 0 (ok) ...

Und auch seltsam: zu GMX bekomme ich outbound ein "Trusted", inbound aber nur "untrusted". Ist da bei mir noch was schief, oder bei GMX?

Es obliegt dem Client zu entscheiden, ob eine STARTTLS-Verbindung aufgebaut wird. Die RFCs fordern sogar ausdrücklich, dass ein öffentlich (!) erreichbarer SMTP-Server nicht zwingend STARTTLS einfordern darf, weil nicht vorausgesetzt werden kann, das der Client es auch beherrscht.

Das würde ich bei GMX jetzt schon voraussetzen. Wir müssten die GMXler fragen, warum deren Mailserver das Angebot Deines Servers nicht wahrnehmen.

p@rick

Am 12.08.2013 11:28, schrieb Florian Streibelt:

Und hier ist halt das Problem, dadurch ist ein man in the middle Angriff trivial möglich, einzig der Fingerprint des ZErtifikats ändert sich. Und da das regelmässig der Fall ist kann man das leider vergessen.

Um man in the middle zu werden müsste er auch noch das DNS manipulieren können. Das wäre schon arg viel Aufwand um einen 0815 Mailaccount auszuspionieren.

Für den Mailtransport ansich ist es doch recht unerheblich, ob der einliefernde MTA echt ist oder nicht. Wer will das schon überprüfen? Dazu müsste man ja ständig die Mail Logs überwachen. Oder man weist Mail von nicht-vertrauenswürdigen MTA komplett ab, aber so weit sind wir noch nicht dass wir so etwas machen können. Telekom, 1&1 und web.de sind ja gerade erst eingestiegen in das Zeitalter der verschlüsselten Übertragung. ;-)

Wichtig ist IMHO nur, dass man im MUA die Echtheit einer Mail verifizieren kann, und das ist mit PGP oder S/MIME Signaturen ja kein Problem.