Alex' blog (Artikel mit Tag ssl)

CAcert Assurer Challenge bestanden

nospam@example.com (Alex) — Fri, 18 Jul 2008 16:00:00 +0200

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.

Eigenes SSL-Zertifikat

nospam@example.com (Alex) — Sun, 06 Jul 2008 11:04:00 +0200

Vor einigen Wochen hatte ich geschrieben, dass ich in naher Zukunft ein eigenes SSL-Zertifikat haben werde. Das ist hiermit nun geschehen.

Der Fingerprint des SSL-Zertifikats von CAcert lautet:

SSL-Zertifikat und CAPTCHAs

nospam@example.com (Alex) — Fri, 06 Jun 2008 17:21:10 +0200

Es gibt mal wieder ein paar Änderungen an meinem Blog bzw. an der Domain.

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.

T-Mobile MDA Vario III funktioniert nicht mit E-Mail-Sicherheitspaket von T-Online

nospam@example.com (Alex) — Thu, 01 May 2008 19:32:18 +0200

Ich hatte ja schon einmal geschrieben, dass der E-Mail-Versand über T-Online nicht klappt, wenn man den MUA des T-Mobile MDA Vario III benutzt.

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.

Feed-Reader für Windows Mobile 6

nospam@example.com (Alex) — Sun, 27 Apr 2008 04:37:00 +0200

Momentan bin ich noch etwas auf der Suche nach brauchbarer und sinnvoller Software für meinen neuen PocketPC, den T-Mobile MDA Vario III.

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.

HTTP Auth Probleme mit Mozilla Firefox 3 Beta 5

nospam@example.com (Alex) — Mon, 21 Apr 2008 10:59:00 +0200

Seitdem ich etwas an der neusten Firefox-Version aus der Zweier-Reihe verzweifelt bin, habe ich den Schritt zur neusten Beta-Version der Dreier-Reihe gewagt. Leider hat es an meinem Problem nicht wirklich etwas verbessert (Änderung an Dateityp => Aktion).

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.

Firefox 3.0 und CAcert-Probleme

nospam@example.com (Alex) — Sat, 22 Mar 2008 22:10:00 +0100

Ich habe mir vor einigen Tagen die neuste Vorab-Version von Firefox 3.0 angeschaut. Die Neuerung "ausführliche Zertifikatsfehlermeldungen" ist immer noch enthalten.

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:

Schritt 1:

Schritt 2:

Schritt 3:

Schritt 4:

Anzahl nötiger Klicks bei permanenter Annahme des Zertifikats: 4
Anzahl nötiger Klicks bei temporärer Annahme des Zertifikats: 5

Zudem hat sich die Voreinstellung für die Annahme des Zertifikats unbekannter CAs geändert: die neue Voreinstellung ist "permanent". Nicht mehr "temporär".

eBay und SSL-Zertifikate

nospam@example.com (Alex) — Sun, 29 Apr 2007 21:20:27 +0200

Wirklich abgelaufen und bisher die Erneuerung ignoriert oder bekommt da jemand die SSL-Verschlüsselung mit, recht sicher vorhandenem, Load-Balancing dahinter nicht gebacken ?

Webdesigner != Netzwerkadmin

nospam@example.com (Alex) — Mon, 18 Dec 2006 14:44:23 +0100

Von einem Mediengestalter & Medienfachwirt habe ich den wahren Satz gehört, dass Mediengestalter sich eigentlich nur auf das Design konzentrieren und das ganze technische drum herum außer Acht lassen sollten, so dass ihre Arbeit kreativ und frei ihren uneingeschränkten Lauf nehmen kann ohne durch technische Limitierungen und Gegebenheiten darin gebremst zu werden.

Der Mann hat ganz recht mit dieser Aussage. (Natürlich kann man die technische Seite niemals vergessen und einem anderen zur Arbeit vorlegen, aber um die Kreativität nicht zu behindern wäre es sicherlich toll, wenn so etwas funktionieren würde.)

Nachdem ich mir dann von einem anderen Webdesigner anhören musste, dass bei einem (unverschlüsselten) Kontakt-Formular jeder Webcrawler die eingegebenen Daten nach dem Abschicken indizieren könnte, sehe ich diese Aussage bekräftigt. Die Daten stehen wohl gemerkt nach dem Abschicken nicht auf einer Webseite, sondern werden direkt per eMail versandt.
Schuster, bleib bei deinen Leisten (und erzähl mir nichts von Netzwerken).

Wenn also jemand den Verkehr nicht mitsnifft, dann kommen auch keine Daten zu irgendwelchen Webcrawlern. Und mitsniffen können Webcrawler nicht. Daher ist diese Aussage großer Blödsinn.

FTPS

nospam@example.com (Alex) — Tue, 28 Nov 2006 16:30:00 +0100

FTPS (FTP over SSL) ist etwas feines, wenn man kein SCP oder SFTP (SSH File Transfer Protocol) zur Hand hat. (Bitte SFTP nicht mit Secure FTP (SFTP) verwechseln, denn dort wird nur der Steuerkanal über SSH getunnelt.)
Hier kann man je nach FTP-Server statt SSL auch TLS verwenden.

Die Verschlüsselung mittels FTPS lässt sich für den Steuer- sowie den Datenkanal nutzen, was einen wesentlichen Vorteil darstellt. Leider scheint aber der FTP-Server bei domain)factory keine Verschlüsselung des Datenkanals bereitstellen zu können. Ich weiß zwar noch nicht wieso man sich dort dazu entschieden hat, aber das angebotene FTPS unterstützt schlichtweg nur die Verschlüsselung des Steuerkanals, was natürlich ein großes Manko darstellt.

Und nein, hier geht es nicht um meinen Hoster. Viel mehr würde ich Interessierten an Domains und sicherem Webhosting den Hoster schokokeks ans Herz legen.

Forderungen an ein besseres Online-Banking mit TANs

nospam@example.com (Alex) — Sat, 18 Nov 2006 01:01:42 +0100

Ja, ich weiß. TANs zu benutzen ist in jeder Hinsicht schwachsinnig, egal ob nun mTAN bzw. SMSTAN oder iTAN, etc.

Aber es gibt heute immer noch genug Leute da draußen, die von HBCI nichts wissen wollen. Wenn sie doch schon einmal etwas darüber gehört haben sollten, so verachten sie den hohen Preis, den der Chipkartenleser kostet. Dabei scheint ihnen aber nicht bewusst zu sein, dass HBCI grundsätzlich auch per Diskette möglich ist. Allerdings besitzen die neueren PCs heutzutage kein Diskettenlaufwerk mehr. Vielleicht wird man eines Tages zu USB-Sticks übergehen ...

Wenn man bei HBCI mittels Chipkartenleser bleibt, stellt sich auch die Frage nach der Sicherheitsklasse. Momentan gibt es vier Klassen. Wer sich gerne die Unterschiede der einzelnen Klassen genauer anschauen möchte, der kann z.B. beim Hersteller REINER SCT vorbeischauen und sich im Glossar belesen oder beim ZKA.

Anzumerken wäre vielleicht noch, dass HBCI über die Zeit weiterentwickelt wurde und dabei dann FinTS bzw. HBCI+ herauskam, was man aber eigentlich nicht benutzen sollte. (Für genaueres: siehe Wikipedia.)

Aber leider betreiben die meisten Leute ihr Online-Banking mittels irgendeiner Form von TANs. Da "wir" momentan auch auf der Suche nach einer neuen, gemeinsamen Bank sind, schaut man sich ja auch im IT-Bereich genauer um - zumindest ich. Da Fragen zu HBCI vor Ort auch heutzutage noch in einem Desaster enden, hofft man wenigstens im Online-Auftritt der jeweiligen Bank besser "beraten" zu werden. So kann man auch gleich die Seiten nach XFS- und XSS-Lücken absuchen. Nicht, dass mich jetzt das PIN/TAN-Verfahren annähernd interessieren würde bei der Suche nach einer neuen Bank, aber es ist schon interessant zu sehen, welche Banken sich mehr Mühe mit der Absicherung dieses schwachsinnigen Verfahrens geben und welche nicht. Leider greifen einige Absicherungen der Bank auch erst im Nachhinein, nachdem u.U. eine Attacke bereits erfolgreich ausgeführt wurde und oft muss man auch selbst noch Hand anlegen, bevor überhaupt eine weitere Absicherung ihre Wirkung erzielt.

Daher möchte ich an dieser Stelle nur eine kurze Auflistung der, nennen wir es ironischer Weise einfach einmal, Features machen, die mir so unter die Augen gekommen sind.

BEN (Bestätigungsnummer, die der Bank-Server nach erfolgter Aktion, zu der eine iTAN nötig war, ausgibt damit diese auf der Liste passend zur eingesetzten iTAN abgeglichen werden kann)
Zeitschloss (nur während eines gewissen Zeitraums am Tag kann Online-Banking überhaupt benutzt werden)
Personalisierung des Logins (Begrüßung mit Name und Adresse)
Überweisungslimit
Sperrung von Auslandsüberweisungen
Sperrung der kompletten iTAN-Liste nach zu vielen Fehleingaben
Automatische Anzeige des Kontostands nach erfolgter Transaktion
Möglichkeit zur Selbstsperrung des Online-Zugangs
Stornierungsmöglichkeit
Virtuelle Tastatur

Die Bestätigungsnummer ist sicherlich ein interessantes Feature, da der Angreifer niemals (außer er hat natürlich Zugriff auf die Liste) die BENs auf der Liste der iTANs bzw. den Inhalt der SMS (mit TAN und zugehöriger BEN) kennen kann (außer er ändert die Handy-Rufnummer).

Die Begrenzung des Zugriffs auf einen bestimmten Tageszeitraum ist zwar ebenfalls eine nette Vorstellung, wird aber sicherlich ziemlich oft nicht praktikabel sein und verhindert auch keine automatisierten Angriffe.

Die Personalisierung des Logins ist für den Angreifer aus Timbuktu auch nicht ohne einen gewissen Mehraufwand zu schaffen.

Das Überweisungslimit hilft zwar nicht gegen einen erfolgreichen Angriff, kann aber die Höhe des Schadens begrenzen. Auch die Sperrung von Überweisungen ins Ausland hilft nicht immer, da genug gekaperte Konten im Inland zur Verfügung stehen bzw. durch "Finanzagenten" dummerweise zur Verfügung gestellt werden. Eine Sperrung der kompletten TAN-Liste bei zu häufiger Fehleingabe der Nummer schützt eigentlich nur vor "Vandalen".

Eine automatische Anzeige des neuen Kontostands nach erfolgter Transaktion würde einigen Leuten sicherlich auch schneller die Augen öffnen, so dass man schneller (selber) den Online-Zugang sperren und seine Bank über den Vorfall in Kenntnis setzen könnte.

Wer seinen Kunden erlaubt den Online-Zugang selbst sperren zu können, der verhindert u. U. noch weiteren Schaden. Wer zudem noch dem Kunden die Möglichkeit zu einer Stornierung bis x Minuten nach Tätigung der Überweisung gibt, der verhindert ebenfalls u.U. einen erfolgreichen Angriff.

Als letztes bleibt noch der Einsatz einer virtuellen Tastatur, die z.B. mittels JavaScript Klicks auf Buttons in Zahlen wandelt, so dass ein reiner Key-Logger nichts aufzeichnen kann. Diese Sicherheitsmaßnahme lässt sich mit der automatischen Anfertigung von Screenshots oder Screen-Videos zwar umgehen, bietet aber dennoch gegenüber reinen Key-Loggern etwas mehr an Schutz.

Sicherlich sind die aufgezählten Möglichkeiten kein Allheilmittel, aber sie können die Sicherheit des PIN/TAN-Verfahrens etwas verbessern. Um mehr ging es mir dabei auch nicht. Eine bessere Aufklärung über die Benutzung von verschlüsselten Webseiten, sprich: SSL-Zertifikaten und deren Fingerprint, wäre von Seiten der Banken her auch dringend zu empfehlen.

Ganz wichtig wäre dann dabei noch zu erwähnen, dass Banken, die den Versuch machen zu erklären, wie man den Fingerprint eines SSL-Zertifikats überprüft, zu ungenau bei der eigenen Ausführung sind. Sie beschreiben, wo man den Fingerprint im Zertifikat auf ihrer Webseite zum Vergleich nachschauen kann, aber das ist bereits wieder ein Sicherheitsproblem. Schließlich können nachgebaute Webseiten einer Bank auch einen neu angepassten Fingerprint in der HTML-Seite passend zum eingesetzten SSL-Zertifikat haben.

Dieser Fingerprint des Zertifikats sollte an einer anderen Stelle vorliegen. Vorzugsweise in Papierform - z.B. bei den Anmeldeunterlagen zum Online-Banking. Einige Banken stellen ihren Fingerprint allerdings auch auf eine andere Webseite auf einer anderen Domain. Das ist zwar besser als nichts, aber nicht perfekt gelöst. Vor allem weil man den Benutzer mittels einem Link wie "Fingerprint des Zertifikats überprüfen" in der Rubrik "Service" auf der (gefakten) Login-Seite seiner Bank wiederum auf einen anderen gefakten Inhalt verweisen könnte.

Letztendlich bleibt wiederum nur die Empfehlung zu HBCI zu greifen. Vorzugsweise mit einem Chipkartenleser der Klasse 3 (oder 4), wobei ein extra Keypad und Display nicht ein Garant für hundertprozentige Sicherheit sind. Ein Abhören des Keypads und eine gefakte Ausgabe auf dem Display des Chipkartenlesers ist ebenfalls möglich, jedoch komplizierter zu bewerkstelligen als bspw. ein Keylogger für den PC.

Eine Forderung an die Hersteller der HBCI-Chipkartenleser hätte ich allerdings auch noch: "Wie wäre es mit einem mechanischen Auswurf der Karte nach Beendigung einer Transaktion, wie bei einigen EC-Bezahlstationen an Tankstellen ?" So nimmt man dem Angreifer die Möglichkeit automatisiert mehrere Transaktionen in einem Rutsch zu erledigen, wenn das Gerät manipuliert wurde. (Funktioniert natürlich auch nur solange bis die Steuerung zum Auswurf softwaretechnisch manipuliert wurde, damit nach der Transaktion kein Signal zum Auswurf der Karte erfolgt ...)