WordPress: Let’s Encrypt Zertifikate und PHP CURL

Let’s Encrypt Zertifikate und PHP CURL sind wie es scheint eine unheilige Verbindung, denn sie wollen nicht zusammen arbeiten. Aber der Reihe nach:

Am Anfang war das Update…

… und nach dem WordPressupdate, kommt auch die WordPress-Netzwerk-Updatefunktion, die, wenn man wie Bloggt-in-Braunschweig.de eine MultiSite betreibt, alle Blogs auf Stand bringt. Das war bislang kein Problem, weil die ohne SSL im Spiel zu haben, updated WordPress die Subinstallationen per HTTP aufruf. Nun, wenn man wie unsere Admins aber ein Lets Encrypt Zertifikat für die WordPressseite benutzt, ruft man den WP-Admin auch mit HTTPS auf, weil sonst das Zertifikat vollkommen umsonst wäre.

Solange man selbst den Adminteil aufruft, ist alles ok, weil der Browser kennt das LE Root Zert schon. Will man jetzt aber das Netzwerk updaten, ruft WordPress die Subseiten auch per HTTPS auf, auch wenn die gar nicht per HTTPS erreichbar sind, weil sie mit Subdomains arbeiten, für die der Webserver auch konfiguriert sein muß. Ab 100 Subdomains spielt LE auch bei der Zertifikaterstellung nicht mehr mit, was bedeutet, MultiSites mit über hundert Blogs müssen ein Wildcard-Zertifikat kaufen und das kann ins Geld gehen.

Jetzt gibt es zwei Wege das Problem mit LE zu lösen, ohne Geld auszugeben :

Man wechselt unschön auf HTTP und aktualisiert die Blogs so, oder man manipuliert den ROOT.CA Speicher von PHP und parkt das LE Root CA dort. Der letztere Teil rein technisch nicht weiter tragisch:

  1. Firefox aufmachen -> Einstellungen -> Erweitert -> Zertifikate  und das LE ROOT unter DST suchen und als /home/username/LEROOTCA.cert abspeichern.
  2. im PHP Code vor das curl_exec() folgende Anweisung schreiben:
    curl_setopt ($ch, CURLOPT_CAINFO, ‚/home/username/LEROOTCA.cert‘);
  3. Dann sollte das PHP Script auch das LE Zertifikat akzeptieren

Hier ein paar Wege um an so ein Zertifikat zu kommen:

Im FireFox auf der Seite mit dem benötigten Zertifikat einfach die Seiteninformationen aufrufen, dann Sicherheit und Zertifikat ansehen ( Details ) :

Wie man Zertifikate Exportiert Ein Klick auf Export und

Und speichern...

Jetzt der Haken an der Sache: im WordPress sind einfach zu viele Curl Calls drin, als das man als Laie mal eben die obige Operation durchführen kann. Ergo: Melden wir WP-User uns jetzt mal bei WP, auf das die den Support für LE bei WordPress einfach mitbringen 🙂

 

 

BND bekommt eigene VDS für 6 Monate ohne Beschränkungen

Wie einem Artikel von Heise zu entnehmen ist, hat der Bundesrat einem Gesetz zugestimmt, daß dem BND eine sechs monatige Vorratsdatenspeicherung aller Verbindung- und Standortdaten erlaubt. Der BND darf diese Daten nach eigenem Gutdünken durchsuchen, ohne daß es eine kontrollierende Instanz wie einen Richterbeschluß gibt. Die Daten dürfen sogar automatisch mit anderen Ländern getauscht werden.

Damit ist faktisch ein Überwachungsstaat geschaffen worden, der ohne rechtsstaatliche Kontrollen alle Daten erfassen kann und wird. Offiziell dürfen natürlich nur Ausländer überwacht werden, aber an Datenströmen steht so selten dran, daß sie nicht aus oder nach Deutschland kommen.

Damit sollte eine rote Linie für alle Bürger überschritten sein, die bisher nichts zu verstecken hatten, denn jetzt sind auch sie betroffen und können jederzeit zum Ziel von Ermittlungen werden, nur weil jemand einen Zahlendreher bei der Eingabe einer IP Adresse gemacht hat. Das war zwar vorher schon möglich, aber wurde zumindest noch von einem Richter abgesegnet.

Für uns Linuxnerds heißt es jetzt natürlich zu handeln. Großflächige Überwachung können wir mit großflächigem Einsatz von VPNs und allgemeiner Verschlüsselung bekämpfen, denn wenn der Preis zum Entschlüsseln aller Verbindungen zu hoch wird, kann sich das der BND oder auch die NSA schlicht nicht leisten. Wenn das ganze Internet verschlüsselt ist, kann man nur noch die Datenströme verfolgen und dekodieren, die einem wirklich wichtig sind. Daran ändern auch die viel beschworenen Quantencomputer nichts. Die Überwachung der Standortdaten kann man ganz leicht umgehen, schaltet das Handy einfach mal aus!

Deswegen gibt es hier im Blog demnächst die Neuauflage der Anleitungen zum Aufbau von VPNs, Anweisungen zu Kryptomessangern, Anleitungen zum Aufsetzen von sicheren PCs und Webserverdiensten. Zukünftig an der eigenen Kategorie „Secure The Web“ zu erkennen.

 

Noch keine Patches für MariabDB Root Exploits vorhanden

Für die u.a. bei The Hacker News gemeldeten Root-Exploits für MariaDB gibt es noch keine Patche im Fedora Repository, auch nicht im Unstable Bereich. Da hilft nur, den möglichen Exploit durch Verschleierung zuvermeiden.

Der bereits verfügbare Testexploit, legt Dateien im /tmp/ Ordner an. Das kann man schon mal verhindern, indem beim Start mit Systemd ein privates Temp-Verzeichnis benutzt wird. Das verhindert den Hack nicht, aber die kleinen Scriptkids werden an der Hürde scheitern 😉

Wenn man sein mariadb.service File nicht geändert hat, kommt es in Fedora bereits mit der richtigen Einstellung:

[Unit]
Description=MariaDB 10.0 database server

# Place temp files in a secure directory, not /tmp
PrivateTmp=true

In der my.cnf sollte man sowieso immer das Benutzen von Symbolischen Links abschalten, eine Serverdatenbank braucht das i.d.R. nicht:

symbolic-links=0

Damit kann man auch ohne Patch CVE-2016-6662 nicht ausnutzen um seine Rechte zu eskalieren. Wer bislang „mariadb-10.0.27-1“ noch nicht eingespielt hat, sollte das trotzdem dringend nachholen.

Gegen die Lücken CVE-2016-6663 und CVE-2016-6664 sind die Patche bei Fedora noch in Arbeit. Leider ist auch im Koji noch keine Testversion ersichtlich. Die letzten Builds stammen vom Anfang des Monats, welche zudem die CVE Patche nicht enthalten. Dies kann natürlich daher rühren, daß diese Versionen nicht anfällig waren, da es sich um den 10.1.17/18 er Zweig von Mariadb handelt.