Alex' blog

Nachdem ich mich endlich einmal um ein paar mehr Punkte bemüht habe, so dass ich die CAcert Assurer Challenge (irgendwie ein Witz ...) auch mal machen kann, ist mir vorhin eingefallen, dass ich diesen Test doch jetzt eigentlich mal machen könnte.

Nachdem ich ihn auch sofort bestanden habe, kann ich nun auch andere assure'n. Für das ((nicht-)elektronische) Zertifikat als PDF, was per E-Mail erfragt werden muss, war ich bislang allerdings zu faul. 

Der Fingerprint des SSL-Zertifikats von CAcert lautet:

SHA-1: 91:01:11:C5:BA:9C:ED:17:FD:26:83:17:00:9B:A7:96:26:3D:C7:4A
MD5: 99:46:66:6C:AD:9F:61:10:7D:F3:F8:B5:E2:B1:98:DF

Vorerst wird für ein paar Wochen kein gültiges SSL-Zertifikat vorhanden sein. Vielleicht hat das der ein oder andere schon bemerkt, wenn er z.B. die Galerie besucht hat. Solange das Zertifikat allerdings von schokokeks.org spricht und den SHA1-Fingerabdruck 80:C8:FA:A2:9E:06:CF:13:79:EC:69:FA:E2:4A:83:E8:62:4A:B2:DE aufweist, ist alles in Ordnung.

Für mein eigenes CAcert-Zertifikat fehlen mir noch ein paar Punkte, um die ich mich in den nächsten Wochen mal bei Gelegenheit kümmern werde. Danach werde ich auch mal die Prüfung zum CAcert Assurer machen.

Was das Blog betrifft: hier habe ich die Text-CAPTCHAs deaktiviert, da sie eigentlich nutzlos sind. Bislang hatte ich sie auf die stärkste Stuffe eingestellt (ok, es gibt nur insgesamt drei Stufen: aus, stark schwach, stärker schwächer), um automatisierten Blog-Spam draußen zu halten. Nachdem ich aber meine Spam-Protokollierung der letzten acht Monate durchgesehen habe, ist der Einsatz von Text-CAPTCHAs in einem Blog total nutzlos, sofern man andere Maßnahmen ergreift, wie z.B. externe Spamfilter-Dienstleister wie Akismet oder Defensio einsetzt.

Wenn man also andere passende Maßnahmen ergreift, kann man auch die dümmsten Spam-Bots draußen halten. Es scheint nämlich auch noch so Exemplare zu geben, die mit CAPTCHAs generell nichts anzufangen wissen und ins Lösungsfeld eines CAPTCHAs schlichtweg nur "You have a nice site ;)" schreiben. Die bleiben auch ohne Einsatz von Text-CAPTCHAs draußen.

Ansonsten hat sich seit acht Monaten gezeigt, dass CAPTCHAs letztendlich nur für Probleme bei Menschen sorgen. Ungefähr ein Dutzend Kommentare ist hängen geblieben wegen fehlerhaft eingegebener CAPTCHA-Lösungen. Das passiert also in Zukunft nicht mehr. Die meisten Personen aus dem knappen Dutzend haben es nämlich kein zweites Mal probiert, sondern haben es schlichtweg aufgegeben. Und das ist ja genau das, was man nicht will und was auch der Definition eines CAPTCHAs widerspricht.

Des Weiteren denke ich im Moment über die Erstellung eines eigenen Anti-Spam-Plugins nach, was ich wahrscheinlich mit den nächsten Wochen mal testweise integrieren werden, um zu sehen, was ein neuer Ansatz gegen Blog-Spam bringt bzw. wie lange er ungeknackt bleibt.

Jetzt habe ich mir das Problem einmal genauer angeschaut. Ich habe in meinem Tarif das Sicherheitspaket mit dabei, was den E-Mail-Empfang (SSL) und -Versand (TLS) über eine verschlüsselte und authentifizierte Verbindung ermöglicht. T-Online bietet da seinen Kunden ja mehrere Möglichkeiten und dementsprechend auch verschiedene Server an.

Für mich sind die folgenden zwei nur interessant:

securesmtp.t-online.de (TLS, Port 25 oder 587)
securepop.t-online.de (SSL, Port 995) bzw. secureimap.t-online.de (SSL, Port 993)

Der MUA des Handys versteht nur SSL. Und hier darf man SSL wörtlich nehmen. Normalerweise sind im Sprachgebrauch die Grenzen zwischen SSL und TLS eher nicht vorhanden.

Da SMTP over SSL auf Port 465 festgelegt wurde klappt der Verbindungsaufbau mit den genannten T-Online-Servern nicht. Andere Ports kam man im MUA nicht angeben. Angaben wie z.B. securesmtp.t-online.de:25 werden ebenfalls ignoriert. (Ja, tatsächlich ignoriert. Nicht mit einer Fehlermeldung bemängelt.)

Interessant gestaltet sich aber der Netzwerkverkehr, der zwischen Handy und SMTP-Server abläuft:
Irgendwann initiiert der MUA eine Verbindung auf Port 25 und labert auf den T-Online Server mit wirren Zeichen ein. Dieser gibt eine Fehlermeldung über die nicht zu verarbeitenden Zeichen aus. Daraufhin beginnt das Spiel erneut. Danach verbindet sich der MUA nochmals auf Port 25 mit dem T-Online Server und meldet sich mit "EHLO foobar", worauf der Server dann mit ein paar möglichen Befehlen antwortet (u.a. natürlich "STARTTLS"). Jetzt beendet der MUA des Handys die Verbindung und zeigt auf dem Touchscreen eine Fehlermeldung an, die letztendlich nur besagt, dass keine SSL-Verbindung hergestellt werden konnte.

Tolle Sache.

Da ich bislang noch keinen freien Feed-Reader finden konnte und der Feed-Reader im Opera Mini mir etwas suspekt und langsam erscheint, habe ich jetzt meinen eigenen erstellt. Er ist allerdings auch noch nicht ganz fertig, läuft aber schon recht problemlos.

Jetzt suche ich nur noch einen Webbrowser oder ein passendes Add-On für den IE, Opera Mini, Opera Mobile oder auch MiniMo, welches den Quelltext einer Webseite anzeigen kann.

Außerdem wäre ein besseres und freies E-Mail Programm nicht schlecht, da man mit dem integrierten keine E-Mails von seinem T-Online-Account verschicken kann, wenn dies verschlüsselt geschehen soll.

Einen freien Jabber-Client suche ich ebenfalls, da MGTalk nicht funktioniert.
Ein Programm für einen Countdown und für eine Stoppuhr suche ich ebenfalls noch. Das solche Standard-Anwendungen fehlen, ist schon etwas seltsam. Sind sie doch fast bei jedem Handy dabei.

Wahrscheinlich muss ich für einiges wieder selber in die Trickkiste greifen. Für Vorschläge, Empfehlungen oder Anregungen bin ich allerdings jederzeit offen.

Dafür hat mir die neue Version gleich ein neues Problem beschert: wenn man ein Bookmark zu einer Webseite anlegt, die vor dem eigentlichen Abruf erst mittels HTTP Auth Logindaten bearbeitet werden muss, und diese in der Form:

https://benutzername:passwort@example.com/pfad

eingibt, so funktioniert dies in der neusten Beta leider nicht mehr automatisch. Jetzt muss man sie wieder händisch eingeben. (Vielleicht betrifft dies neuerdings auch nur SSL-verschlüsselte Verbindungen. Unverschlüsselte habe ich nicht getestet.)
Hoffentlich bleibt diese Einschränkung nur bis zur Final. Es war doch recht bequem.
(Ja, auch unsicher, solange man keine anderen Vorkehrungen trifft.)

Leider ist dies bei HTTP/HTTPS auch nicht über ein RFC standardisiert, sondern nur bei FTP. Trotzdem machen es alle Webbrowser, die mir so einfallen, dennoch richtig.

Das gibt, wie ich hier schon einmal erwähnt hatte, auf jeden Fall Probleme für Betreiber von Webseiten mittels CAcert-Zertifikat (oder einem self-signed Zertifikat).

Da der Nutzer nicht mehr zur Interaktion gezwungen wird, wie eins mit dem Dialogfeld, dessen Voreinstellung das temporäre Erlauben der Webseite gewesen wäre, werden sicherlich viele Nutzer die Webseite verlassen, bevor sie sie richtig aufgesucht haben.

Da CAcert als CA auch im Firefox 3.0 noch nicht dabei sein wird (abgesehen von einigen Linux-Distributionen, die CAcert als CA gleich dazupacken), werden meiner Ansicht nach viele Nutzer aus Sicht des Betreibers einer Webseite ausgesperrt werden. Andererseits ist es eine ausführliche Warnung natürlich besser für die Sicherheit.

Wenn ein Nutzer nun das Zertifikat akzeptieren will (egal ob temporär oder permanent), so durchläuft er folgende Screenshot-Abfolge: