Content from 2012-07

Site schnellstens aus Google entfernen: alles außer robots.txt sperren

posted on

Diese Woche bekomme ich einen Anruf von einem Bekannten: er entwickelt gerade eine Website für einen Kunden. Und obwohl die Seite noch nicht fertig ist, taucht sie schon im Suchindex von Google auf. Er hatte vergessen die Seite während der Entwicklung mit einem Passwortschutz zu versehen. Er fragte mich, ob ich eine Idee habe, wie er dieses Versäumnis so schnell als möglich korrigieren könne.

Wir sind nun gemeinsam ein paar Möglichkeiten durchgegangen das Problem zu beheben:

  • Site jetzt mit Passwortschutz versehen: es kommt zwar niemand mehr auf die Seite, allerdings ist sie noch in Google (und vermutlich anderen Suchmaschinen) gelistet,
  • robots.txt auf die Seite laden, die allen Suchmaschinen sagt, dass die Site nicht gelistet werden möchte: wer die Adresse kennt kommt trotzdem noch darauf oder
  • manuell über die Google Webmaster-Tools die Löschung beantragen: allerdings hatte Google schon über 10.000 Treffer auf der Site.

Alle drei Einzelmaßnahmen alleine reichen nicht aus. Wir haben uns entschlossen, dass alles drei in Kombination sinnvoll ist. Eine kleine Herausforderung war nun den Webserver so zu konfigurieren, dass alle Seiten der Site grundsätzlich mit einem Passwortschutz versehen waren, als einziges der Zugriff auf die Datei robots.txt jedoch ohne Passwort möglich war. Meistens wird ein Passwortschutz ja über einen Eintrag wie "require valid-user" in einer .htaccess-Datei eingerichtet. In diesem Fall hätte ein solcher Schutz allerdings ins Root-Verzeichnis der Domain gelegt werden müssen und die robots.txt wäre dann auch nicht mehr abrufbar gewesen.

Lösen lässt sich dieses Problem mit der <LocationMatch>-Einstellung von Apache und einem kleinen regulären Ausdruck:

<LocationMatch "^/(?!robots\.txt).|robots\.txt.+$">
    require valid-user
    AuthType Basic
    AuthUserFile /etc/apache2/users/.htuser
    AuthName Devel-Area
</LocationMatch>

Eingetragen kann dies allerdings nicht in eine .htaccess-Datei werden. <LocationMatch> ist in einer solchen Datei nicht zulässig. Der Eintrag muss in den vhost-Eintrag der Apache-Konfiguration gemacht werden (unter Debian: /etc/apache2/sites-available/*).

Auf diesem Weg konnten wir den Zugriff auf die Seite sofort sperren und trotzdem den Suchmaschinen ermöglichen die Datei robots.txt zu lesen. Da diese Datei von Suchmaschinen häufig angefragt wird und wir darin die komplette Indizierung der Site gesperrt haben, waren so auch die Einträge in Google auch innerhalb von ein paar Stunden wieder Vergangenheit.

Probleme mit TLS-Verbindungen bei StartSSL-Zertifikaten

posted on

Ich greife mit zwei E-Mail-Programmen auf meinen Mailaccount zu. Das eine ist mutt, das andere ist Thunderbird. Während ich mit mutt keine Probleme habe, kann ich seit zwei Tagen mit Thunderbird nicht mehr auf mein E-Mail-Konto zugreifen.

Wenn ich es probiere, dann sehe ich Thunderbird für etwa 20 Sekunden versuchen eine Verbindung mit dem Mailserver aufzubauen. Nach diesen 20 Sekunden stellt sich Thunderbird wieder so als hätte es nicht versucht E-Mails abzufragen. Es kommt also auch keine Fehlermeldung oder dergleichen.

Da ich meinen Mailserver selbst betreibe, habe ich auch die Gelegenheit in dessen Logfile zu schreiben. Besonders aussagekräftig ist der Eintrag dort allerdings auch nicht:

Jul 11 22:30:24 eder imapd: couriertls: read: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate

Das heißt so viel wie „der Client hat uns gesagt, dass er unser Zertifikat nicht akzeptiert, mehr weiß ich auch nicht“.

Ich habe eine ganze Zeit gesucht an was es liegen könnte, dass mein Thunderbird das Zertifikat des Mailservers nicht mehr akzeptiert. Des Rätsels Lösung ist, dass ich Thunderbird so eingestellt habe, dass er jedes Zertifikat bei der jeweiligen Zertifizierungsstelle (in meinem Fall StartSSL) überprüft, ob es inzwischen zurückgezogen wurde. Hierzu gibt es das Protokoll OCSP (Online Certificate Status Protocol).

Screenshot von den OCSP-Einstellungen meines Thunderbirds.
OCSP-Einstellungen von Thunderbird. Zu erreichen über Einstellungen > Erweitert > Zertifikate > Validierung

Hier liegt auch das aktuelle Problem: StartSSL scheint aktuell nicht in der Lage zu sein OCSP-Anfragen zu beantworten. Und eine weitere Einstellung in meinem Thunderbird sagt diesem: „Wenn eine OCSP-Server-Verbindung fehlschlägt, das Zertifikat als ungültig betrachten“. Soweit ich weiß, ist diese Einstellung per Default in den Mozilla-Produkten ausgeschaltet. Ich halte dies jedoch für keine gute Idee, da auf diesem Weg von einem Angreifer sehr einfach eine Überprüfung eines ggf. gestohlenen Zertifikates über OCSP verhindert werden kann. Er müsste nur dafür sorgen, dass kein Connect zum Zertifikatsherausgeber mehr gelingt. Diese Einstellung abzusichern ist bei der Konfiguration von Thunderbird also immer eines der ersten Dinge die ich mache.

Auch jetzt habe ich mich dazu entschlossen, dass ich diese Einstellung in meinem Mailprogramm nicht lockere sondern stattdessen besser vorübergehend auf den Einsatz von Thunderbird verzichte und all meine E-Mails mit mutt lese. Man könnte zwar nun sagen, dass dieser aktuell ja auch nur funktioniert, da er keiene OCSP-Überprüfung durchführt. Allerdings läuft mein mutt auf dem gleichen Server wie auch mein Mailserver. Da aller Traffic nur über das loopback-Device läuft habe ich hier geringere Sorgen auf diesem Weg angegriffen zu werden. Wenn jemand in der Lage ist diese IP-Pakete zu modifizieren, dann hat er solchen Zugriff auf den Server, dass er sich diese Mühen nicht mehr machen muss. Er verfügt dann ohnehin über mehr Möglichkeiten.

Was man an der ganzen Erfahrung eigentlich am Meisten enttäuscht ist, dass mir Thunderbird keine Fehlermeldung ausgibt. Ein Hinweis, dass die OCSP-Abfrage beim Herausgeber des Zertifikates nicht möglich war und er das Zertifikat des Servers deswegen ablehnt, hätte mir viel Problemsuche erspart. Oder zumindest nur eine Ausgabe, dass das Zertifikat ungültig sei, hätte mir zumindest die Suche nach dem Grund dafür erleichtert. Ich habe einen Bug hierzu bei Thunderbird aufgemacht. Vielleicht baut ja jemand eine entsprechende Fehlermeldung in zukünftige Versionen ein.

Mein Dank geht übrigens an Milan Berger, er hat mich mit seinem Blogpost OCSP, StartSSL und Performanceeinbußen auf den richtigen Weg gebracht die Ursache zu finden.

Nachtrag 12. Juli 2012, 10:00

Aktuell scheint der OCSP-Responder von StartSSL wieder zu funktionieren. Thunderbird akzeptiert das Zertifikat meines Mailservers wieder.

Android 4.0.3+ überholt Version 2.3.3+

posted on

Diese Woche hat für die erste meiner Anwendungen (SKS-Trainer) die Anzahl der Installationen auf Android 4.0.3+ die der Installationen auf Android 2.3.3+ überholt. Bei meinen anderen Apps – vor allem denen für die Funkscheine – hat letztere die Nase noch vorn. Nach den Zahlen von Google ist Android 2.3.3+ auch an sich noch immer die am häufigsten genutzte Version des Handybetriebssystems.

Ich biete fünf Android-Apps im Play Store an. All diese Programme richten sich an annähernd die gleiche Zielgruppe: Anwender, die sich auf einen Segelschein vorbereiten und die Theoriefragen lernen wollen.

VersionDurchschnitt lernenSportboot binnenSKSUBISRCLRC
Android 2.3.3+56,61 %45,1 %40,7 % 42,0 %45,5 %49,5 %
Android 2.215,51 %7,5 %6,6 % 9,0 %7,5 %8,0 %
Android 4.0.3+15,23 %38,7 %41,5 % 33,5 %32,0 %29,0 %
Android 3.25,72 %6,2 %9,0 % 13,0 %12,0 %12,0 %
Android 2.13,87 %1,7 %0,9 % 1,5 %1,0 %1,5 %
Android 3.12,36 %0,5 %0,9 % 0,5 %1,0 %
Android 2.30,32 %0,1 %0,1 %
Android 4.00,14 %0,1 %0,1 % 0,5 %
Android 3.00,13 %0,1 %0,1 % 0,5 %

In vorstehender Tabelle befinden sich die Android-Versionen nach denen Google die Verteilung unterscheidet. Ich habe dabei nur die Versionen berücksichtigt auf denen meine Anwendungen lauffähig sind. (Android 1.5 und 1.6 hätten zusammen einen Anteil von 0,62 % im Play-Store in der Kategorie „Lernen“.)

In der Spalte „Durchschnitt lernen“ steht die Verteilung der Android-Versionen wie sich durchschnittlich bei Anwendungen vorkommt, die in den Bereich „Lernen“ einsortiert sind. In den anderen Spalten stehen die Verteilungen für die Verschiedenen Apps von mir.

Screenshot aus der Play-Konsole, der die Verteilung auf Android-Versionen
darstellt.
Verteilung der Installationen meines SKS-Trainers auf Android-Versionen

An meinen Zahlen fällt dabei auf, dass ich einen deutlich überdurchschnittlichen Anteil von Nutzern habe, die meine Anwendungen mit Android 3.0 oder höher nutzen (Tabletts und neuere Mobiltelefone). Mein Anteil an Nutzern mit älteren Versionen dagegen ist unterdurchschnittlich.

Woher könnte dies kommen? Nun zuerst ist festzustellen, dass die Anteile die Google für den Play-Store ermittelt weltweit ermittelt werden. Meine Apps dagegen richten sich fast ausschließlich an Nutzer in Deutschland, da damit auf deutsche Segelscheine gelernt wird. Außerdem ist festzustellen, dass meine Apps natürlich mit Seglern (und Motorbootfahrern) eine thematisch deutlich eingeschränktere Zielgruppe ansprechen. Als dritten Grund könnte man noch annehmen, dass meine Apps überhaupt erst seit unter drei Monaten verfügbar sind. In die allgemeine Statistik von Google zählen dagegen auch Programme, die auf älteren Geräte installiert wurden, die inzwischen ungenutzt in irgendeiner Schublade liegen.

Meine Zahlen für meine Apps von oben beziehen sich übrigens auf derzeit knapp 5.000 Installationen. Mit Abstand am meisten installiert sind die Anwendungen auf dem Samsung Galaxy S2 (knapp 20% der Installationen). Für dieses Gerät gab es ursprünglich Android in der Version 2.3, seit Februar 2012 gibt es Version 2.3.6 und seit April ist Android 4.0.3 für dieses Gerät als Update verfügbar.


Unless otherwise credited all material Creative Commons License by Matthias Wimmer