Leider beherrscht Firefox im Gegensatz zu Google Chrome den FIDO U2F Authentifizierungsmechanismus noch nicht nativ. Wenn man sich mit seinem Yubikey via U2F bei Google, GitHub, Dropbox oder einem anderen unterstützten Dienst anmelden will, musste man bisher auf Chrome / Chromium ausweichen.
Heute morgen bin ich bei meinen Nachforschungen auf ein Firefox Plugin (»Github) gestoßen, das verspricht, U2F Unterstützung nachzurüsten. Tatsächlich wurde mein Yubikey damit auf der Yubico U2F Demo Seite problemlos erkannt – auch wenn mir noch die Warnung zur fehlenden Kompatibilität mit Firefox angezeigt wurde. Die Warnung bleibt bestehen, solange die Website erkennt, dass ich mit Firefox unterwegs bin. Schließlich unterstützt Firefox ja offiziell noch kein U2F.
Vor einiger Zeit habe ich mir einen Yubikey zugelegt, der u.A. die Authentifizierung über den U2F Industriestandard unterstützt. Bei Diensten wie Dropbox, GitHub oder Gmail kann man sich schon via U2F Mechanismus und einem U2F-kompatiblen Authentifizierungsgerät anmelden – aber bisher nur über den Google Chrome Browser. Andere Browser (und so leider auch Firefox) unterstützen U2F noch nicht, obwohl der erste Standard zu U2F – FIDO v1.0 – schon im Dezember 2014 verabschiedet wurde.
Ein Jahr ist jetzt vorüber und mein Lieblingsbrowser Firefox arbeitet noch immer noch mit meinem Yubikey zusammen. Im Mozilla Bugtracker gibt es eine Diskussion zu dem Thema und offenbar bin ich nicht der einzige, der FIDO U2F Support im Firefox schon sehnsüchtig erwartet. Gerüchten zufolge soll Firefox in etwa 3 Monaten endlich U2F unterstützen. Ich bin gespannt.
Einige Professoren an meiner Hochschule schützen ihre PDF Skripte mit einem Passwort, sodass sie von fremden Usern nicht geöffnet oder bearbeitet werden können. Da die ständige Passworteingabe im Alltag lästig ist, habe ich mich nach einer Möglichkeit umgesehen, den Passwortschutz zu entfernen – am besten direkt über die Kommandozeile.
Mit dem PDF-Tool qpdf kann der Passwortschutz sehr unkompliziert entfernt werden:
Let’s Encrypt ist auf das automatische Abholen und Einrichten von TLS-Zertifikaten ausgelegt. Für Anwender, die mehr Kontrolle über den Prozess haben wollen, gibt es aber auch einen „Manual Mode“, der folgende Vorteile hat:
Die Zertifikate können von jedem Rechner aus abgeholt werden (Der LE Client muss nicht auf dem Zielserver laufen)
Der Webserver muss nicht wegen des LE Clients kurzzeitig abgeschaltet werden.
Und so funktioniert’s: Auf von einem beliebigen Rechner aus kann mit dem Let’s Encrypt ACME Client eine Zertifikatsanfrage abgeschickt werden. Zur Bestätigung des Domainbesitzes müssen in einem bestimmten Unterverzeichnis des Ziel-Webservers (Domain-Ziel) Dateien mit einem bestimmten Inhalt hinterlegt werden (=> Challenge-Dateien). Der ACME Server überprüft daraufhin, ob die Dateien unter den jeweiligen Domains erreichbar sind und der Inhalt korrekt ist. Wenn das der Fall ist, ist der Domainbesitz bestätigt und die Zertifikate werden ausgehändigt.
Kaum einer meiner Server läuft nur mit einer einzigen Anwendung. Der Webserver, auf dem dieser Blog läuft, beherbergt nicht nur thomas-leister.de, sondern auch noch zwei andere Blogs und weitere PHP-basierte Webdienste, die ich zur Verfügung stelle. Aus Sicht eines Hackers ein lohnenswertes Ziel: Wird über eine PHP-Anwendung wie z.B. einen schlecht gepflegten WordPress-Blog Zugriff auf das Dateisystem des Servers erlangt, kann der Hacker nicht nur die unsichere Webapplikation angreifen, sondern auch alle anderen Anwendungen, die unter dem PHP-User laufen. Aus diesem Grund ist es sinnvoll, die PHP-Anwendungen etwas voneinander abzuschotten, sodass ein Angreifer von der einen PHP-Anwendung aus keine andere PHP-Anwendung beeinträchtigen kann. Dies erreicht man, indem man für jede Anwendung einen eigenen User anlegt, der PHP ausführt. Die Verzeichnisrechte werden so gesetzt, dass nur der jeweils zugedachte PHP-User Zugriff auf die Anwendungsdateien hat und keine weiteren Änderungen im Dateisystem vornehmen kann.
Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:
Heute habe ich eine neue Version meines Gravatar Privacy Proxys für WordPress fertiggestellt. Für das Plugin ist keine Einrichtung eines externen Proxyservers mehr notwendig. Die Installation wurde dadurch erheblich vereinfacht: Einfach ZIP herunterladen, in WordPress hochladen, Plugin aktivieren und fertig.
Als Proxy wird nun ein mitgeliefertes PHP-Script genutzt, welches die Anfragen an die Gravatar-Server stellt. Ein Cache für bessere Performance ist derzeit noch nicht vorhanden, aber in Planung.
Um zu verhindern, dass der integrierte Proxy unberechtigt verwendet wird, verfügt die neue Version über eine Zugriffskontrolle, die externe Zugriffe verhindert.
Standardmäßig sind in WordPress Gravatare aktiv. Ist ein Kommentar mit einer E-Mail Adresse verknüpft, die Gravatar.com bekannt ist, wird das passende Profilbild vom Server heruntergeladen und auf dem WordPress Blog dargestellt. Die ständige Kontaktaufnahme zu Gravatar-Servern bei jedem Laden einer Blogseite kann jedoch ein Datenschutzproblem sein. Für Gravatar ist nachvollziehbar, welcher Blogbesucher eine bestimmte Seite eines bestimmten Blogs aufgerufen hat – alleine dadurch, dass ein Benutzer eine Blog-Seite und damit die Gravatare lädt.
Um auch dieses Datenleck zu schließen, habe ich ein kleines WordPress-Plugin namens „Gravatar Privacy Proxy“ entwickelt, das die Avatar-Anfragen nicht direkt an Gravatar.com stellt, sondern zunächst über einen (eigenen) Proxy leitet. Wenn ihr Seiten auf diesem Blog aufruft, werdet ihr feststellen, dass keine Anfragen an gravatar.com gestellt werden, sondern stattdessen an gravatar.trashserver.net – meinen Gravatar-Proxy. Dieser tut nichts anderes, als die Anfragen entgegenzunehmen und an den echten Gravatar-Server weiterzugeben. Für den Gravatar-Server sieht es so aus, als sei mein Proxy der Blogbesucher. Der tatsächliche Besucher bleibt hinter dem Proxy anonym.
Mein WordPress Plugin schreibt alle Avatar-Adressen so um, dass sie über den Proxy geleitet werden. Damit das Plugin funktioniert, braucht ihr einen externen HTTP Reverse Proxy Server. Mit Nginx lässt sich so ein Server sehr einfach einrichten (siehe README).
Mein Gravatar Privacy Proxy Plugin biete ich kostenlos unter der freien MIT Lizenz an. Wie ihr das Plugin installiert und einrichtet, könnt ihr in der README Datei nachlesen.
Leider beherrscht Firefox im Gegensatz zu Google Chrome den