Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und ist nicht mehr verfügbar. Let’s Encrypt ist der kostenlose Standard für TLS-Zertifikate.
Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.
Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.
1. OpenFire beenden.
2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.
In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.
3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.
Openfire hat ein Problem wenn in der /etc/resolv.conf der Nameserver als IPv6-Localhost eingetragen ist (::1). Der Java-DNS-Client kann die IPv6-Adresse nicht parsen und wirft eine NumberFormatException. Das Ergebnis: Keine S2S-Verbindungen, keine Authentifizierung mit Remote-Servern.
Fehlerbild
Im /var/log/openfire/error.log findet sich:
org.jivesoftware.openfire.session.LocalOutgoingServerSession
- Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
at java.lang.Integer.parseInt(Integer.java:492)
at com.sun.jndi.dns.DnsClient.(DnsClient.java:125)
at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession
.createOutgoingSession(LocalOutgoingServerSession.java:270)
Java versucht ::1 als Portnummer zu parsen und scheitert an dem Doppelpunkt. Der Bug steckt in Javas DnsClient-Klasse die IPv6-Adressen in der resolv.conf nicht korrekt behandelt.
Lösung
In der /etc/resolv.conf den Nameserver von ::1 auf 127.0.0.1 umstellen:
Openfire neu starten. Der lokale DNS-Resolver lauscht in der Regel auf beiden Adressen, die Namensauflösung funktioniert über IPv4 genauso. Neuere Java-Versionen haben den Bug behoben, aber wer eine ältere Version nutzt oder nicht updaten kann, ist mit dem IPv4-Workaround auf der sicheren Seite.
Weitere Openfire-Probleme mit S2S-Verbindungen: 404 Remote Server Not Found behandelt fehlende Intermediate-Zertifikate.
In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.
Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.
Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.
CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten. Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden und werden offenbar dazu verwendet, um in mit dem FTP-Account verbundene Webseiten schädlichen Code einzuschleusen, welcher auf Drive-by-Exploits verweist. Es liegen leider keine Informationen vor, wann und wie die Zugangsdaten ausgespäht wurden.
Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.
Format: ASN | IP-Adresse | FTP-Login
Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden entsprechend zu informieren.
Bitte bestätigen Sie den Eingang dieser Benachrichtigung und informieren Sie uns über die von Ihnen getroffenen Maßnahmen.
Liste der Zugangsdaten für Server in Ihrem Netzbereich:
Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.
Zertifikat holen
Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:
Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:
Usage
0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector
0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type
0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512
Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:
dig _25._tcp.smtp.kernel-error.de TLSA +short
Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):
In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.
Google schaut in die E-Mails seiner gmail Nutzer, wertet den Inhalt aus und zeigt dem Nutzer dann maßgeschneiderte Werbung…. OK, ist jetzt nichts Neues! Nun hat Google aber bekanntgegeben dass sie zumindest keine Schüler mehr in dieser Form abschnorcheln will.
Toll, oder? Super… Alle freuen sich…. ALLE FREUEN SICH! Leute, schlaft ihr alle? Google durchsucht, nach eigenen Angaben, keine E-Mail Accounts von Schülern mehr und SCHÜTZT sie somit vor Werbung welche zu E-Mail Inhalten passt!!!!!
Das ist so als wenn der Postbote die Briefe liest und immer direkt das passende Werbeprospekt beilegt. Warum freuen sich alle? Ich verstehe es nicht, tut mir leid!
Au man… Das ist ja der Hammer! Wie konnte denn bitte dieser Scheiß passieren? Zum Glück war mein System noch auf der Version 0.9… Aber keine Sorge, ich muss an genug anderen Systemen neue Schlüssel erstellen und die Anwender zu neuen Kennwörter „überreden“.
Das ist einer der größten Löcher die ich bisher gesehen habe und wer hat es gefunden? Google…. Ö_ö
Hier muss nun unbedingt ein Plan her für besseren Code Audit, richtig? Ich habe sogar bereits von Exploids gelesen, welche noch vor dem Bekanntwerden im Umlauf gewesen sein sollen. Alle Systeme mit den bösen Versionsständen müssen also als kompromittiert angesehen werden. Ich habe nun schon mit einigen Leuten darüber gesprochen und in diesem Punkt stimmen mir die Meisten zu, bis zu dem Punkt an welchem die damit verbundenen Konsequenzen klar werden. Also neue Schlüssel bauen, von der CA signieren lassen, einbinden, allen Anwendern neue Kennwörter zuschieben usw. usw. usw… Denn mit dem einspielen der Patches ist zwar das Loch gestopft, die möglicherweise abgeschnorchelten und vielleicht bereits missbrauchten Daten sind damit noch nicht zurückgeholt. Denn noch tun sich hier einige Entscheider schwer..
Richtig unangenehm wird es, wenn man daran denkt das in der Vergangenheit aufgezeichnete -verschlüsselte- Daten mit dem vielleicht eingesammelten privaten Schlüssel nun entschlüsselt werden können. Es sei denn Perfect Forward Secrecy war aktiviert. Das ist wohl das Gute an der ganzen Nummer. Man hat nun nicht nur einen theoretischen Grund um PFS einzuführen.
O-o nun mal im Ernst, mich wundert an der Geschichte eher dass dieses Viele überrascht. Schauen wir uns doch mal die durchschnittlichen Kennwörter der meistern Benutzer an. Die sind nicht wirklich gut und oft haben sie ebenfalls nur ein Kennwort für alle ihre Dienste. Natürlich haben sie ja per default nichts zu verbergen, also wird auf „Sicherheit“ nicht unbedingt Wert gelegt… Klar geht mir in diesen Fällen immer ein Schmunzeln über die Lippen. Denn man hat ja nichts zu verbergen und ist ja alles nicht SO schlimm. Nur wenn mein E-Mail Passwort von anderen geklaut wurde, ne da muss natürlich was passieren.
Ich lese und höre in den letzten Tagen immer das fiese, böse, Masken und Kapuzen tragende Hacker die E-Mail Accounts gehackt hätten. Viel eher werden wohl verseuchte Rechner die Kennwörter bei der Eingabe oder Übertragung eingesammelt und Kriminellen geschickt haben. Wenn ich mich so bei einigen Kunden umschaue sieht man schnell dass die großen drei Sicherheitslöcher Anwendungsprogramme (Java, Flash, PDF) meist in recht alten Versionen vorliegen. Die Microsoft Produkte selbst bekommen ja meist per WSUS oder direkt von Microsoft ihre Updates. Java, Flash oder der Acrobat Reader kümmern sich „selbst“ darum. Leider muss der Anwender für die Installation der Updates administrative Rechte auf dem Rechner haben. Sonst kann er die Installation kaum durchführen. Gut, es gibt auch hier Lösungen… Welche ich produktiv im Einsatz gesehen habe kann ich an einer Hand abzählen. Daher hängt es mal wieder vom Einsatz der hauseigenen IT ab. Das klappt mal gut, mal weniger gut. Gibt es keine eigene IT, sieht es schnell schlecht aus. Warum muss überhaupt jeder Anwender ins Internet und warum immer mit Flash, Java und PDF?!?!
Es lässt sich kaum ändern. Vor einiger Zeit hatten wir ja schon mal etwas ähnliches. Wie groß ist dann wohl die Dunkelziffer ? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*
Man hat also seine E-Mail Adresse eingegeben und hat daraufhin die Info bekommen: Wenn deine E-Mail Konto geklaut wurde, dann bekommst du von uns eine GPG signierte E-Mail mit folgendem Betreff (Zufallszeichen). Nur wenn die E-Mail auch diesen Betreff hat ist sie von uns und du hast ein Problem!
Einmal mit Profis…. Nun nehmen wir das mal eben auseinander:
1. der GPG Schlüssel vom BSI ist auf der gleichen Webseite zu saugen und ist so vertrauenswürdig wie „der dicke Mann aus der Sparkassenwerbung“… 2. GPG ist toll nur wie viele der Anwender nutzen es wohl? 3. der Betreff, auf welchen es ankommt, wird bei einer GPG signierten E-Mail NICHT signiert. Er kann also wild geändert werden… 4. die E-Mail welche den Anwender darüber informiert das sein Account ggf. von anderen missbraucht wird, geht also an diesen Account. Der Missbrauchende müsste sie also nur ?löschen?.
Welcher Internetausdrucker hat sich dieses bitte überlegt?!?!?
Diese Kritikpunkte sind beim BSI angekommen und man könnte meinen, sie hätten es beim jetzt neuen Fall besser gemacht… Haben sie?
Natürlich nicht!!!
Zusätzlich wird man nun noch von seinem Provider informiert das sein Account „gefressen“ wurde und direkt gezwungen sein Kennwort zu ändern. Klappt natürlich nur bei den großen Providern. Ja OK, die meisten abgefischten Accounts liegen dort… Macht es denn noch nicht wirklich besser, oder?
Jetzt halten einige von den Pressemenschen wieder jedem dritten ihr Mikrofon unter die Nase… Dabei ergeben sich so Ideen wie: Es muss rechtliche Regelungen für so etwas geben. Zwei Wege Authentisierung usw. usw… Ob das wirklich alles so richtig ist?
Was bringt das alles wenn man Windows XP einsetzt, Java und Flash einem Sieb ähneln und die großen Provider dir beim Login erzählen das dein Adblocker die Sicherheit deines Browsers gefährdet? Dann sind wir schon bei E-Mail Made in Germany, richtig? Die Jungs hängen gerade an die große Glocke dass sie es 2014 geschafft haben TLS für ihre Verbindung einzuschalten und für die Anmeldung voraussetzten. 2014… Ich meine 2014… Das ist knapp 20 Jahre als. 2014. Die haben ihren Werbemastschweinen Kunden bis 2014 per Plaintext (also im Klartext) ein Login gestellt. Jeder hat durch bloßes hinschauen die Zugangsdaten abschreiben können. Die kommen dann mit „Sicherheit wiederherstellen“ und E-Mail Made in Germany und jetzt ist alles sicher?
Ach ich rege mich hier schon wieder auf…
Vielleicht sollte man aufhören seine Kunden auszuquetschen und mit Müll zu füttern. Hm, setzt natürlich voraus das die Kunden es wollen und vor allem mal von ihrem „kostenlos“ Ding wegkommen. Ach, ich höre nun auf, sonst habe ich für heute wieder schlechte Laune!
Unsichere Protokolle und Chiper aus Postfix, Dovecot und Apache2 sind schonmal weg!
Jetzt ist mein xmpp Jabber Server ejabberd dran… Auch hier müssen die Protokolle SSLv2 sowie SSLv3 weichen. Nur alles größer TLSv1 ist erlaubt…. Bei den Chipern fliegt alles raus das „böse“ ist… Zum Beispiel MD5, RC4 usw. usw… Natürlich werden auch die ECDHE Cipher suite aktiviert um Forward secrecy zu unterstützen.
? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*
