Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀

 

Neue TLS Probleme beim BSI

Vor zwei Wochen habe ich auf Probleme beim EMailversand des BSI aufmerksam gemacht. Damals bekam ich nach 24h die Rückmeldung, daß die Probleme behoben seien.

Leider mußten wir heute feststellen, daß das BSI Mailserver benutzt, die nicht-deterministisch sind, sprich, mal gehts, mal nicht 😉  Einer unser Server, der die gleiche Konfig hat wie alle anderen mit StartTLS anbietet, bekam nun unverschlüsselt Post vom buerger-cert.de Mailserver, obwohl dieser keine Stunde vorher einem anderen Server eine TLS verschlüsselte Verbindung angeboten hat… HMMMM!

Da haben wir dann mal genauer hingesehen und fanden noch weitere Probleme beim TLS des bei der OpenIT GmbH gehosteten Servers:

A) Es fällt auf, daß buerger-cert.de als MX gar keinen eigenen Mailserver einsetzt, sondern den zentral Mailserver von Openit.de benutzt :

2016-08-23 13:18:08 1bc9iZ-0005l4-Nl => mailversand@buerger-cert.de R=dnslookup T=remote_smtp H=mx.openit.de [217.69.65.200] X=TLSv1:AES128-SHA:128 C=“250 Ok: queued as E9B4011A055″

Das wird den gleichen Sicherheitslevel haben wie mx.kundenserver.de aka 1und1 Mailserver, oder vielleicht doch nicht ? 🙂

B) Nein, haben sie nicht, denn der dort eingesetzte Postfix Mailserver (220 mx.openit.de ESMTP Postfix)  scheint „etwas“ veraltet zu sein, oder auf veralteter Software zu laufen, denn er bietet nur TLS 1.0 an. Experten kennen das auch als SSLv3 und das ist ja bekanntlich geknackt worden und sollte nicht mehr eingesetzt werden.

Jetzt muß man 1und1 bescheinigen, wenigstens konsequent zu sein und überall TLS 1.2 einzusetzen, aber dafür immer noch SSLv3 anzunehmen 😀 Was die Macher von ssl-tools.net dazu meinen, kann man hier sehen :

https://ssl-tools.net/mailservers/1und1.de    (Ja, den Gag versteht man nur, wenn man den Link aufruft 😉 )

Was ssl-tools.net vom bueger-cet.de Mailserver hält, sieht man hier :

BSI-Neue-Probleme-mit-TLS(Stand: 25.8.2016 )

C) Die Mailserver im Cluster sind unterschiedlich konfiguriert … hää ?????? Einer kann TLS 1.2 der nächste nicht ??  Da kann man nur den Kopf schütteln.

Fazit

Auch wenn das BSI ein Problem gelöst hat, es sind noch viel mehr vorhanden. Bin mal gespannt, wann das behoben wird, denn die Meldung an das BSI ging natürlich vor diesem Artikel raus 🙂

F5 Firewalls ?

Wer täglich die Warnung des Cert liest, wird die Firma F5 mit Ihren Firewalllösungen kennen, ob wir Sie mögen sollten, ist eine andere Sache. Jedenfalls sind die in letzter Zeit Dauergäste in den Emails des Cert.

Heute konnte ich in einer Meldung zu einem lokalen Kernelprivilegienescalation Problem folgendes lesen:

Version 1 (2015-04-30 14:38)
Neues Advisory
Version 2 (2015-05-04 11:00)
Für die Distributionen Fedora 20, 21 und 22 stehen Sicherheitsupdates zur Behebung der Schwachstelle bereit. Die Updates für Fedora 20 und 21 befinden sich im Status ‚testing‘, das Update für Fedora 22 im Status ’stable‘.
Version 3 (2015-05-06 09:32)
Canonical stellt für die Distributionen Ubuntu 12.04 LTS inkl. Trusty HWE, Ubuntu 14.04 LTS inkl. Utopic HWE, Ubuntu 14.10 und Ubuntu (vivid) Sicherheitsupdates zur Behebung der Schwachstelle bereit.
Version 4 (2016-02-01 10:49)
F5 Networks informiert über die betroffenen Produkte und Versionen. Unter anderem ist BIG-IP Protocol Security Module (PSM) in den Versionen 10.1.0 – 10.2.4 und 11.0.0 – 11.4.1 verwundbar. Um Angriffe zu vermeiden, sollten nur vertrauenswürdige Administratoren Zugang zu der erweiterten Shell haben. Im Appliance-Modus kann die Schwachstelle nicht ausgenutzt werden, da Benutzer in diesem Modus keinen Zugriff auf die erweiterte Shell haben.
Quelle:
DFN-CERT Services GmbH

Da ich natürlich zuerst lese, um was es geht und welche Plattform betroffen ist, fiel mit nicht sofort auf, daß es sich um Kernel 4.0.1 handelte, da entgegen sonst üblichen Emails der Kernel gar nicht genannt wurde. (Das DNF Cert schickt manchmal Emailteaser für Ihr Webangebot rum, für den Fall egal.)

Wenn man nun genauer hinschaut, muß man schon etwas stutzen, da Version 1 der Meldung vom 30.4. 2015 ist und erst heute, am 1.2.2016 F5 merkt, daß sie auch betroffen sind. Von einer Firma aus dem Securitybereich, erwarte ich mir mehr, wenn jede Linuxdesktopdistribution schneller ist, als meine Firewalllösung.

Vielleicht mag der eine oder andere ja mal einen Kommentar dazu abgeben.

Wie schnell sollte eine Unternehmensfirewall reagieren ?

Was ist das maximal Grenze, die noch akzeptabel ist, klar sofort die Norm sein sollte.