Artikel mit ‘ssl’ getagged

Dear VeriSign …

Dienstag, 15. Februar 2011

Wir sind VeriSign-Partner, um SSL-Zertifikate von Thawte, GeoTrust und anderen CAs dieser Gruppe beziehen zu können – immerhin werden diese häufig nachgefragt, und SSL ist ja im Prinzip auch eine gute Sache.

Allerdings nervt VeriSign gewaltig. Jeden Monat bekomme ich Mails mit meiner Accountaufstellung, mitsamt Vertragsbezeichnungen und konkreten Dollar-Beträgen, die ich ausgegeben habe und noch auf meinem Partner-Konto übrig habe – also durchaus sensible Daten. Die kommen unverschlüsselt, was ich für ein Unternehmen aus dem Security-Bereich schon bizarr genug finde. So bizarr, dass ich schon zig Mal und an verschiedene Adressen gefragt habe, worin denn hier die Sicherheit bestehen soll, wenn sensible persönliche Daten unverschlüsselt durch die Gegend gemailt werden, und dass man das doch bitte abschalten solle. Ergebnis? Keine Antwort, egal ob ich eine der generischen Adressen anschreibe oder meinen „persönlichen Account-Manager“, der namentlich unter der Mail genannt wird. Das stinkt mir schon mal gewaltig, wenn ein Unternehmen, bei dem ich jedes Jahr einige tausend Dollar lasse, sich nicht mal dazu in der Lage sieht, auf simple E-Mails zu antworten.

VeriSign ist aber noch anstrengender. Es kommen nämlich auch noch ständig Promotion-Mails rein, und jetzt seit neuestem auch noch eine Umfrage, die ich bitte ausfüllen möge und an die ich heute schon wieder erinnert wurde. So langsam reicht es mir. Wer uns kennt, weiß, dass wir nicht nur unsere Kunden, sondern auch unsere Lieferanten genau so höflich, professionell und vor allem auch herzlich behandeln, wie wir selbst gerne sowohl als Kunde als auch als Lieferant behandelt werden möchten. Das hat VeriSign aber im Lauf der Monate kräftig verspielt, denn wenn ich eins nicht haben kann, dann ist das „Kundenbeziehungsmanagement“, bei dem der Kunde die Beziehung selbst managen soll, unter anderem, in dem er irgendwelche Arbeiten erledigen soll, mit dem der Anbieter „messen“ will, wie „zufrieden“ man ist. Denn, ganz klar: „Your opinion is extremely valuable to us“! So extremely valuable, dass man sich die Mühe gemacht hat, ein Script anzuwerfen, das automatisiert dem gesamten Kundenbestand den Bauch pinselt und gleichzeitig anquengelt, man möge jetzt doch bitte auch noch kundtun, wie zufrieden man ist. In Sachen „Kundenbeziehung“ kommt das einer Bankrotterklärung nahe, denn Hand aufs Herz: Gäbe es tatsächlich eine Kundenbeziehung, dann wüsste das Unternehmen ja bereits, ob ich zufrieden bin oder nicht.

Daher nun also:

Dear VeriSign Partner Program Loyalty Team,

As part of our commitment to improve our partner program, I wrote to you last week to solicit your feedback about your experience with the VeriSign Partner Program. Although I understand the many constraints on your time, your opinion is extremely valuable to us.

Obviously, you do not understand the many constraints on my time, otherwise you wouldn’t constantly annoy me with such mailings.

We will ensure that your feedback is reviewed and used to drive improvements in the partner experience.

I don’t trust that.

For example, I constantly receive monthly accounting statements containing financial details of my account via unencrypted mail. I asked my account manager three times about VeriSigns understanding of security which obviously does not include the encryption of sensible data, which is baffling enough for a „security“ company.

I never got a single response.

That’s not the kind of company I’d invest even five minutes for your dumb „surveys“ if you’re simply not able to listen to things I tell you personally.

The survey will take about 5 to 10 minutes to complete. To access the survey, please click the Web address below.

Your mail is sent as multipart/alternative, containing both a HTML variant and a plain text variant.

The plain text variant does not contain a link at all. Are you really a company of Internet professionals?!

The HTML variant contains a link to the survey, which is unencrypted. Are you really a company of data security experts?!

To remove yourself from receiving future Symantec promotional mailings http://www.verisign.com/compref and update your communication preferences and user profile.

When I open that link, I get a redirect to …

https://forms.verisign.com/websurveys/servlet/ActionMultiplexer?Action_ID=ACT2000&WSD_mode=3&WSD_surveyInfoID=500&toc=…&brand=01&country=26&cid=…

… which provides a HTML page consisting of the word „null“ and nothing else. Are you really a company of Internet professionals?!

I never opted in into receiving such promotional mailings, and I’m not willing to invest any time to click through an obviously broken site of „communication preferences“. I’m paying you for getting SSL certs. Story finished. For God’s sake, stay away from me with your „promo“, „survey“ and „loyalty“ rubbish.

Regards,
Jonas Pasche

SSL-Client-Zertifikate mit Chrome

Donnerstag, 14. Oktober 2010

SSL-Zertifikate gibt’s von einer Menge Anbietern. Wir nehmen unter anderem auch die Dienste von StartCom in Anspruch, bei denen wir am ehesten den Eindruck haben, dass die auch selbst was von Sicherheit verstehen – ein Eindruck, den fatalerweise viele SSL-Zertifizierungsstellen nicht machen.

Zu diesem Eindruck trägt auch bei, dass StartCom konsequent auf SSL-Client-Zertifikate zur Authentifizierung setzt, und nicht auf das klassische Paar aus Benutzername/Passwort. Technisch gesehen läuft das so, dass man einen kleinen Assistenten durchläuft, der eine Browserfunktion anwirft, die einen privaten Schlüssel direkt im Browser erzeugt und ablegt (sprich, er wird nie an den Website-Betreiber übermittelt) und anschließend auf dieser Basis dann ein Zertifikat generiert, was dann direkt in den Browser importiert wird. Ist der Prozess abgeschlossen, kann man sich mit diesem Zertifikat gegenüber der Website ausweisen. Im Prinzip ist das ein gutes Beispiel, wie man starke Authentifizierung wirklich bequem und einsteigerfreundlich machen kann, denn der ganze Prozess ist sehr einfach gestaltet und lässt sich auch ohne besondere Vorkenntnisse durchlaufen. Die Frage, die unerfahrene Anwender dabei noch am ehesten stellen, ist von daher weniger „Was muss ich hier machen?“, sondern eher „Wieso funktioniert das einfach so, ich musste ja nicht mal ein Passwort eingeben?!“ – tja, willkommen in der manchmal doch ganz schönen Welt von SSL.

Damals hatte ich diesen ganzen Prozess mit Firefox abgewickelt. Mittlerweile nutze ich im Alltag fast nur noch Chrome, genaugenommen die freie Variante Chromium, für die Tom „spot“ Calloway Fedora-Pakete pflegt. In puncto SSL unterscheidet sich Chromium von Firefox: Unter Linux benutzt es nämlich die NSS-Funktionalität des Systems, statt einen eigenen Keystore zu basteln (was ich für eine äußerst gute Idee halte), während Firefox auf allen Plattformen einen eigenständigen Keystore nutzt. Natürlich können die Client-Zertifikate in Form von PKCS#12-Dateien exportiert und im jeweils anderen Tool importiert werden – das nur so zum Hintergrund.

Nun laufen auch Client-Zertifikate irgendwann aus, so dass ein neues fällig wurde. Also habe ich den Client-Zertifikats-Assistenten von StartCom angeworfen – diesmal aber im Chromium. Nun ist aber gerade jenes „Certificate Enrollment“ derzeit noch eine Baustelle und läuft beileibe nicht „einfach so“ rund, wie ich es oben beim Firefox noch so gelobt habe. Und damit meine ich nicht, dass es mehr Handarbeit bräuchte, sondern dass es schlicht überhaupt nicht erfolgreich funktioniert. Hätte ich mal vorher nachgeschaut – hatte ich aber nun mal nicht.

Das vorläufige Ende vom Lied: Chromium hat es durchaus geschafft, einen privaten Schlüssel in der NSS-Datenbank zu erstellen. Mit dem Import des darauf basierenden Zertifikats hat das aber leider nicht geklappt: „Fehler 207 (net::ERR_CLIENT_CERT)“ war alles, was ich zu sehen bekam – sprich, das war ein Schuss in den Ofen – und zwar noch ein schlimmerer, als ich dachte: Die naheliegendste Lösung, den Key einfach wegzuschmeißen und ein neues Client-Zertifikat zu erstellen (diesmal dann wieder im Firefox) klappt nämlich auch nicht: StartCom lässt es nicht zu, ein Client-Zertifikat zu erstellen, wenn ein vorheriges noch gültig ist.

Dunkle Wolken ziehen am Horizont auf. Das von StartCom generierte Client-Zertifikat kann ich über deren Toolbox immer wieder beziehen; das ist nicht das Problem – nur funktioniert es eben nur in Kombination mit dem Key. Und das ist genau das Problem: Im Chromium (bzw. in der NSS-Datenbank) habe ich den Key, bekomme aber das Client-Zertifikat nicht rein. Der Firefox könnte zwar das Client-Zertifikat importieren, aber da er den Key nicht hat, schlägt das fehl.

Mein nächster Gedanke war: „Bei SSL-Server-Zertifikaten hantieren wir ja auch immer mit einer Datei für den privaten Schlüssel und einer Datei mit dem Zertifikat. Wieso also nicht einfach den Key aus der NSS-Datenbank exportieren und in Firefox importieren – und dann, wenn der Firefox den Key hat, kann er ja wohl auch das Zertifikat aus der Toolbox importieren.“

Denkste. Christopher wies mich direkt darauf hin:

Nein, Firefox kann nur Keys nur in PKCS-Dingsbums importieren, nicht roh. Also kannst es versuchen, aber bei Firefox…

Wäre ja nett gewesen, überhaupt bis zum diesem Punkt zu kommen. Faktisch ist es nämlich gar nicht möglich, nur den Key aus der NSS-Datenbank zu exportieren. Exportieren geht nur im PKCS#12-Format, und das besteht zwingend aus Key und Zertifikat. Nelson B Bolyard schreibt:

Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.

Ja, toll. Ich will aber nicht meine Security ruinieren; ich weiß ja, was ich hier tue und warum. Und ich habe mir beileibe auch nicht aus freien Stücken ausgesucht, so vorzugehen. Chris ergänzt: „Abandon all hope, ye who enter here“. Wie wahr.

So oder so: Dieser Weg war wohl ein Schuss in den Ofen. Also vielleicht doch anders herum, sprich, „irgendwie“ an das Zertifikat kommen und das manuell in die NSS-Datenbank mit reinpacken. Nur wie? Erstmal müsste man dazu wissen, wie denn die URL heißt, unter der man das Zertifikat bekommen kann. Und das ist nicht so ganz einfach, denn die Toolbox vom StartCom ist völlig ajaxisiert; man kann sich nicht einfach irgendwo mal schnell eine URL rauskopieren. Abhilfe schafft das Firefox-Plugin Live HTTP Headers, das die HTTP-Header jeglicher Browserkommunikation mitschneidet – also auch die der Ajax-Kommunikation. Und siehe da: Klappt prima, und ich komme auf eine URL in dieser Form:

https://www.startssl.com/getcrt.ssl?certID=...

Genau was ich brauche!

Leider ist es damit nicht getan, denn Firefox versucht beim Aufruf dieser URL sofort, das Zertifikats zu importieren – was natürlich nicht geht, weil der dazu passende private Schlüssel im Keystore vom Firefox ja fehlt. Ich will das Zertifikat ja auch eigentlich nicht importieren, sondern herunterladen, sprich: als Datei speichern. Das Problem kann man grob damit vergleichen, wenn man die URL eines Bilds direkt im Browser eingibt: Dann wird man ja auch nicht gefragt, ob man das Bild anzeigen oder speichern will, sondern es wird eben einfach angezeigt. Mit einem entscheidenden Unterschied: Ich kann dann immer noch über das Kontextmenü „Bild speichern unter …“ auswählen und das Bild auf die Platte bannen. Hier wird aber ja gerade gar nichts angezeigt – ergo hilft mir das Kontextmenü (und auch das Datei-Menü, das einen gleichnamigen Punkt bietet) überhaupt nicht weiter.

Der Workaround, auf den ich schließlich gekommen bin, gehört zu der Kategorie, bei der man sich mit einem herzhaften „D’oh!“ an die Stirn schlagen möchte. Also: Wo kann man sonst noch über das Kontextmenü Dinge direkt abspeichern? Richtig, bei Links, „Ziel speichern unter …“. Zwar ist die StartCom-Toolbox wie gesagt ajaxisiert und bietet daher keinen solchen Link, aber das macht nichts: Da wir ja nun die URL kennen, bauen wir uns einfach selbst einen Link in einer lokalen Datei, rufen diese via file:///tmp/link.html im Firefox auf, rechte Maustaste auf den Link, Ziel speichern unter, und voilà: Das Zertifikat ist im PEM-Format mit der Endung .p7b auf der Festplatte gespeichert.

Damit ist die größte Klippe umschifft. Nun gilt es nur noch, diese Datei in die NSS-Datenbank zu importieren, wo bereits der zugrundeliegende Key wartet:

certutil -d sql:$HOME/.pki/nssdb -A -t "u,u,u" -n "Jonas Pasche" -i cert.p7b

Klappt sofort – und spontan kann Chromium das SSL-Client-Zertifikat benutzen. Der Vollständigkeit halber soll es aber auch in den Firefox. Also exportieren wir es aus der NSS-Datenbank; um genau zu sein, exportieren wir Zertifikat und Key, denn es gibt ja nur beides in Kombination:

pk12util -d sql:$HOME/.pki/nssdb -o export.p12 -n "Jonas Pasche"

Die resultierende Datei kann dann schließlich problemlos in Firefox importiert werden – und ein ätzendes Problem mit einem zunächst verwaisten Key in der NSS-Datenbank hat seinen sauberen Abschluss gefunden.

Bleibt noch zu sagen, dass dieser ganze Krampf rein akademischer Natur war. Es hätte nämlich auch gereicht, sich in der StartCom-Toolbox ein neues Client-Zertifikat mit einer anderen E-Mail-Adresse generieren zu lassen. Entscheidend für die Anmeldung an der Toolbox ist schließlich nicht die Mail-Adresse, sondern die damit verbundene Identität, und da sämtliche Client-Zertifikate, die ich in meinem Account ausstelle, auch auf meine Identität verweisen, kann ich auch alle gleichermaßen für den Login benutzen. An dieser Stelle soll nicht unerwähnt bleiben, dass diese letzte – natürlich viel einfachere – Variante dem wie immer hervorragenden StartCom-Support eingefallen ist. Danke dafür!

Ist die Seite echt?

Donnerstag, 29. Juli 2010

Über den Newsletter unseres Domainregistrars, der unter anderem auch SSL-Zertifikate anbietet, wurde ich auf die Website www.ist-die-seite-echt.de gestoßen, einer werblichen Website für Extended-Validation-SSL-Zertifikate (im Folgenden kurz EV-Zertifikate genannt), die ich absichtlich nicht direkt verlinke, um ihr nicht noch mehr unverdiente Hits zu verschaffen. Wer nicht weiß, was EV-Zertifikate sind: Das sind die SSL-Zertifikate, die dafür sorgen, dass im Browser die Adressleiste grün wird, und von denen die wenigsten wissen, warum überhaupt. Doch dazu gleich mehr.

Die Werbe-Website soll den Blick dafür öffnen, Phishing-Sites von echten Websites unterscheiden zu können. Dazu werden 10 Mal je zwei Screenshots parallel gezeigt und man soll beurteilen, welche davon die Phishing-Site ist. Nur die ersten fünf sind ein Ratespiel: Bei den zweiten fünf geht es um genau die selben Sites, aber eine davon hat eine grüne Adressleiste – Marketing mit dem Holzhammer.

Im ersten Fall tragen beide Screenshots eine https://-URL unter der identischen Domain. Die zweite trägt einen lustigen Text, der mit „Wir haben einen kleinen Fehler in Ihrem Konto entdeckt. Sie müssen links auf den Anmeldelink klicken“ beginnt, und die Erläuterung verrät: „Auf einer echten Website werden Sie niemals zur Abgabe von Benutzernamen und Passwörtern gezwungen“. Äh, wie meinen? Natürlich zwingen mich auch echte Websites dazu, unter anderem nämlich das Onlinebanking meiner Bank. Wie sonst sollte ich mich auch autorisieren? Mich hätte hier in diesem Fall eher der Sprachduktus des Texts stutzig gemacht, aber wie gesagt: Beide Screenshots zeigen eine Seite unter korrekter URL mit korrektem SSL-Zertifikat – nur eben keinem EV. Fragwürdiges Beispiel.

Im zweiten Fall war die URL gefälscht („http://www.quickmoos.de@12.21.101.4“). Nicht mal SSL-verschlüsselt. Das war leicht.

Im dritten Fall habe ich nun wirklich lange suchen müssen: Beide Sites sahen auf den ersten Blick völlig identisch aus. Beide Sites mit korrekter Domain; beide Sites mit korrektem Zertifikat – nur eben keinem EV. Die Begründung überrascht: Man hätte den linken Screenshot als Phishing-Site identifizieren sollen, weil … dort Rechtschreibfehler auf der Seite sind. Das ist doch nicht euer ernst, VeriSign. Nachdem ich in der Vergangenheit nicht nur Rechtschreibfehler, sondern zum Beispiel auch überhaupt nicht existierende E-Mail-Adressen auf der EV-zertifizierten (!) Website einer Zertifizierungsstelle (!!) der VeriSign-Gruppe (!!!) fand und noch dazu dann mit deren Support zu tun hatte, der überhaupt nicht verstand, wo hier das Problem lag, soll das ein Erkennungsmerkmal für Phishing-Sites sein?!

Beispiel Nummer vier ist nicht SSL-verschlüsselt. Simpel.

Beispiel Nummer fünf ist SSL-verschlüsselt, unter der korrekten Domain, und die Sites zeigen keinen Unterschied. Überraschung: VeriSign tut kund, dass manchmal Phisher so gut darin seien, Seiten zu fälschen, dass man tatsächlich überhaupt keinen Unterschied wahrnehmen könnte, und der einzige Schutz dagegen sei … der Einsatz von EV-Zertifikaten. Whoa!

Nun kann man natürlich zu dem Schluss kommen: Wow, EV-Zertifikate sind das neue geschnitten Brot, und ohne ist eigentlich alles andere unsicher – nicht zuletzt Beispiel Nummer 5 legte ja auch durchaus nahe, dass VeriSign der Meinung ist, ein „normales“ SSL-Zertifikat würde einen offensichtlich nicht vor Phishing schützen.

Unabhängig davon, ob das nun stimmt oder nicht, so ist es doch vor allem eins: Ein Armutszeugnis. Denn VeriSign hört natürlich in keinster Weise damit auf, auch weiterhin genau die Nicht-EV-Zertifikate zu verkloppen, von denen es auf seiner werblichen Website sagt, dass die überhaupt nichts taugen, wenn es darum geht, eine Phishing-Website von einer echten zu unterscheiden. Und zwar zu einem Nettopreis von, festhalten, 349,00 € für ein „Secure Site“- und 895,00 € für ein „Secure Site Pro“-Zertifikat. Und zwar für ein Jahr. Dazu fällt mir nur eins ein: Schamlos. Ein Produkt taugt was, das andere nicht; für diejenigen, denen das, was etwas taugt, aber vielleicht zu teuer ist, bieten wir das, was nichts taugt, aber ruhig weiterhin an. Das hat zwar vielleicht sehr viel mit Betriebswirtschaft zu tun – mit Sicherheit und Vertrauen aber gewiss nichts.

Davon abgesehen stellt sich doch die Frage: Was haben wir denn die ganzen letzten Jahre überhaupt mit SSL gemacht, wenn erst EV der Heilsbringer schlechthin ist und vorher jeglicher Schutz ganz offensichtlich wirkungslos?

Die Wikipedia fasst die Ansichten verschiedenster Quellen prägnant zusammen:

Die Ausgabe von SSL-Zertifikaten ist zwar grundsätzlich an eine Überprüfung des Antragstellers gebunden, der Preisdruck unter den Anbietern hat aber zu einer teilweise laxen Vergabepraxis und zu vereinfachten Zertifikaten geführt, die nicht mehr als den Domain-Namen zertifizieren. […] Kritiker sehen in dem neuen Standard teils den Versuch der Zertifizierungsstellen, sich dem Preiskampf in der SSL-Zertifikat-Ausgabe durch die Einführung eines neuen Premium-Produktes zu entziehen, das dem Benutzer wenig zusätzliche Sicherheit bringt, und das auch mit anderen Mitteln zu erreichen wäre.

Aha. Es ist also die laxe Vergabepraxis der Zertifizierungsstellen gewesen, die die Argumentation nährt, dass heutzutage angeblich alle Nicht-EV-Zertifikate nur Augenwischerei wären. Nur dass VeriSign wie gesagt selbst die laut ihrer eigenen Werbekampagne nicht als sicher erkennbaren Zertifikate weiterhin für sehr teures Geld verkauft (und die EV-Zertifikate dann für extrem teures Geld), während es gleichzeitig Website-Besuchern beibringt, solchen Zertifikaten nicht zu vertrauen, sondern nur denen mit der grünen Adressleiste.

Dazu muss man ein bisschen wissen, wie das alles mit SSL funktioniert. Kurz gesagt: Jeder kann SSL-Zertifikate ausstellen, zum Beispiel mit OpenSSL. Die eigentliche Wertigkeit bekommt ein Zertifikat dadurch, dass es von einer Stelle signiert wird, die überprüft, ob derjenige, der via Zertifikat behauptet, eine bestimmte Person oder ein bestimmtes Unternehmen zu sein, auch derjenige ist. Das kann zum Beispiel anhand der Vorlage eines Personalausweises geprüft werden oder auch anhand eines Handelsregisterauszugs. In einem Client (also zum Beispiel in Webbrowsern, genauso aber auch in Mailclients, in Handys, oder auch ganz allgemein in Betriebssystemen) ist dann eine Liste von Zertifizierungsstellen hinterlegt, die als vertrauenswürdig gelten. Soll heißen: Die Herausgeber jener Clients haben die Entscheidung über die Vertrauenswürdigkeit für den Anwender vorab getroffen. Dafür geben sie sich gewisse Richtlinien; hier als Beispiel die Mozilla CA Certificate Policy. Inweit es gut und richtig ist, Anwendern diese Entscheidung abzunehmen, kann diskutiert werden, aber es dient ohne Frage durchaus der Sicherheit, dem Anwender eine Liste vorzuschlagen (die er selbst ja noch anpassen kann), als ihm die Akzeptanz bestimmter Zertifizierungsstellen grundsätzlich ohne jegliches „Vorschussvertrauen“ selbst zu überlassen, was – Hand aufs Herz – vermutlich dazu führen würde, dass die meisten Anwender einfach ungesehen auf den Ja-und-Amen-Button klicken würden, wenn eine neue, bisher unbekannte Zertifizierungsstelle ins Spiel käme. Insofern muss man realistisch bleiben und sagen: Auch wenn die Vorgabe einer Liste von vertrauenswürdigen Zertifizierungsstellen nicht optimal ist; ohne solche Listen wäre das Sicherheitsdebakel heute sicherlich noch wesentlich schlimmer (oder hätte möglicherweise zu ganz anderen, vielleicht auch besseren Lösungen geführt – aber das ist nur Spekulation).

Festzuhalten bleibt jedenfalls eins: Auch wenn man darüber streiten mag, dass vielleicht die Policies der Browserhersteller schlicht nicht streng genug waren oder schwarze Schafe nicht aggressiv genug entfernt worden sind: Letztlich haben es die Zertifizierungsstellen selbst verbockt. Da finden sich Fälle, wo die Validierung ausschließlich darin besteht, eine Mail unter einer der vorgegebenen Adressen unter der zu zertifizierenden Domain empfangen zu können, wobei die Liste der erlaubten Adressen so umfangreich ist, dass man sich etliche davon einfach bei Freemailern registrieren kann, um flugs ein SSL-Zertifikat zu bekommen, das auf die Domain des Freemailers ausgestellt ist. Aber warum die Mühe, gibt es doch auch „Zertifizierungsstellen“, die Zertifikate gleich ganz ohne irgendeine Art von Prüfung ausstellten – wie hier im prominent gewordenen Fall für mozilla.com. Zwei äußerst lesenswerte Beiträge zu genau dieser Thematik finden sich auch bei mitternachtshacking.de: Teil 1, der sehr griffig die verschiedenen Stufen von Validierung erläutert, und Teil 2, der eine gesunde Portion Paranoia ergänzt.

Zu all diesen Beispielen für Verfehlungen von Zertifizierungsstellen fällt mir nicht mehr viel ein. Außer vielleicht eins: Liebe Zertifizierungsstellen, ihr seid die Letzen, von denen ich mir etwas verkaufen lassen würde, was angeblich einem Mehr an Sicherheit dienen soll. Das, was ihr nun großspurig als Extended Validation verkauft, ist das, was ihr eigentlich schon immer bei allen SSL-Zertifikaten hättet tun sollen. Dass ihr da in der Vergangenheit geschlampt habt und das nun zum Anlass nehmt, den Kunden noch viel teurere Zertifikate zu verkaufen, ist wirklich eine bodenlose Frechheit.

Und noch eins verstehe ich nicht: Nämlich, wieso Browserhersteller diesen „Spaß“ auch noch mitmachen und mit einer besonderen Hervorhebung wie der grünen Adressleiste würdigen, statt einfach eiskalt alle Zertifizierungsstellen aus der Liste zu werfen, die keine vertrauenswürdige Validierung durchführen. Diese Zwei-Klassen-Validierung hat nämlich ein Problem: Normale Anwender verstehen sie sowieso nicht. Kaum ein Anwender kann mir erklären, was denn nun bei einem grünen Zertifikat so besonders geprüft worden sei, dass erklärt wäre, warum es so besonders aussieht. Es sieht einfach nur besser aus. Und der perfide Umkehrschluss ist nämlich folgender: Die Zertifizierungsstellen können jetzt lauthals tönen, dass das einfache Schloss-Symbol im Browser nicht mehr aussagekräftig sei; es müsse schon die grüne Adressleiste sein – und damit den Druck auf Webmaster zu erhöhen, sich dieses überteuerte Schlangenöl zuzulegen. Damit diejenigen, die neben all den technischen Sicherheitsproblemen von SSL die mit Abstand größte Sicherheitslücke im System darstellen, künftig noch mehr Geld verdienen.

Christopher ergänzte, dass es früher wohl üblich war, dass die Zertifizierungsstellen den Browserherstellern eine nicht unerhebliche Menge Geld dafür in den Rachen warfen, um auf die Liste der vertrauenswürdigen Zertifizierungsstellen zu kommen, was mit der Folgerung „Finanzielles Interesse!“ eine veritable Erklärung für die im vorherigen Absatz aufgeworfene Frage darstellt:

Back in the early days of SSL Netscape charged CAs rather large fees to have their root certificates included in Netscape products.

Allerdings ist das heute offensichtlich nicht der Fall; weder Apple noch Opera noch Microsoft nehmen Geld für die Aufnahme in die Liste, und communitybasierte Produkte wie Firefox und Thunderbird erwartungsgemäß auch nicht. Damit bleibt die Frage des vorherigen Absatzes weiterhin offen.

Ach ja: An die Werbe-Website schließt sich übrigens ein „Gewinnspiel“ namens „SSL EV Race“ ein. Zu gewinnen gibt’s ein iPad. Bei einem Gewinnspiel wird typischerweise ein Preis ausgelost. Das ist hier aber überhaupt nicht der Fall. Das iPad bekommt nämlich derjenige, der in der vorgegeben Zeit die meisten EV-Zertifikate verkloppt hat. Insofern ist die Angelegenheit dann doch wirklich eher ein Rennen als ein Gewinnspiel. Und an diesem werden wir definitiv nicht teilnehmen – wollen.

In der Plesk-Hölle: qmail-smtpd, SSL … und spamdyke

Dienstag, 27. Juli 2010

Wenn man etwas weiter hinter die Kulissen schaut, findet man manchmal ganz erstaunliche Dinge. Heute soll es mal um verschlüsseltes SMTP mit dem qmail-Paket von Plesk gehen. Für Verschlüsselung gibt es, um das ganz kurz zu erläutern, zwei Verfahren: TLS und SSL. TLS bedeutet: Man verbindet sich mit dem unverschlüsselten Port (normalerweise 25), der Server annonciert, dass er STARTTLS beherrscht, der Client sendet jenes STARTTLS, und die Verbindung ist verschlüsselt. Alternativ benutzt man SSL: Hier stellt der Server einen separaten Port bereit (normalerweise 465), auf dem dann direkt eine verschlüsselte Verbindung entgegengenommen wird.

Der aufmerksame Leser wird bereits eins ahnen: SSL über einen separaten Port kann man in der Art eines Wrappers um beliebige Dienste „drumherumstricken“, z.B. mit stunnel oder ucspi-ssl, ohne dass man den Dienst selbst anpassen muss. Dass ein Dienst hingegen ein Schlüsselwort wie STARTTLS versteht und daraufhin die Verschlüsselung einschaltet – da dürfte auf der Hand liegen, dass das nur mit einem Patch geht. Für qmail gibt es dafür seit langem einen etablierten Patch von Frederik Vermeulen, der (unter anderem) qmail-smtpd beibringt, auf STARTTLS zu reagieren. Im Vorbeigehen unterstützt er auch noch die traditionelle Variante mit dem separaten Port – ganz ohne Wrapper: Es reicht aus, die Umgebungsvariable SMTPS zu setzen, bevor qmail-smtpd aufgerufen wird, und das war’s.

Nun schauen wir uns mal an, wie das bei Plesk aussieht. Ich habe die Konfigurationsdateien jeweils auf das Wesentliche gekürzt, also bitte nicht wundern. Erstmal für den Standard-SMTP-Port 25:

# cat /etc/xinetd.d/smtp_psa
service smtp
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd [...]
}

… und schließlich für den Standard-SMTPS-Port 465:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd [...]
}

Der xinetd erkennt an der service-Bezeichnung den numerischen Port, in dem er ihn über /etc/services auflöst. So weit, so gut.

Nun stellt sich aber doch eine Frage: Woher weiß qmail-smtpd im zweiten Fall denn, dass es bitte SSL sprechen möge und nicht Plaintext? Plesk arbeitet hier genauso mit dem etablierten TLS-Patch, der eigentlich verlangt, dass die Umgebungsvariable SMTPS gesetzt sein muss. Die wird hier aber doch gar nicht gesetzt..?!

Des Rätsels Lösung ist, dass Plesk hier ganz gewaltig trickst. Nicht etwa, dass es ein Leichtes gewesen wäre, in der /etc/xinet.d/smtpd_psa kurzerhand env = SMTPS=1 einzutragen: Nein, das wäre doch viel zu nachvollziehbar gewesen.

Stattdessen patcht Plesk. Und patcht. Und patcht. Details dazu finden sich in der Plesk-Knowledgebase. Wir schnappen uns das erste der Patche-Archive und schauen mal rein. Darin findet sich ein Haufen Patches mit so klangvollen Namen wie patch-pb, patch-pe oder auch patch-ps. Oder, und darum geht’s: patch-pu-tls. Darin steckt so eine Art Variante des etablierten qmail-TLS-Patches, „natürlich“ bereinigt um jegliche Kommentare oder Dokumentation. Und ganz am Ende, da findet sich plötzlich ein Teil, den es im Original nicht gibt, nämlich diesen hier:

--- ./tcp-env.c.orig    Thu Feb 20 11:33:43 2003
+++ ./tcp-env.c Thu Feb 20 11:37:05 2003
@@ -70,6 +70,9 @@
    temp[fmt_ulong(temp,localport)] = 0;
    if (!env_put2("TCPLOCALPORT",temp)) die();
 
+   if (localport == 465)
+      if (!env_put2("SMTPS","true")) die();
+
    byte_copy(&iplocal,4,&salocal.sin_addr);
    temp[ip_fmt(temp,&iplocal)] = 0;
    if (!env_put2("TCPLOCALIP",temp)) die();

Dass qmail-smtpd unter Plesk also auf „magische“ Weise plötzlich SSL spricht, liegt daran, dass das vorgeschaltete tcp-env die Variable SMTPS kurzerhand setzt, sobald es feststellt: Oh, ich laufe unter Port 465! Unnötig zu sagen, dass Plesk die man page von tcp-env nicht angerührt hat – die verrät von diesem Verhalten nichts. Da muss man sich dann auch nicht wundern, wenn in Foren Fragen wie diese auftauchen – und unbeantwortet bleiben (Hand aufs Herz, die Frage ist von 2007, und in dem Forum müsste ich mich auch erstmal registrieren, um antworten zu können):

When i copy smtps_psa to another port / service, SSL does not work. Is SSL hard-coded somewhere in Plesk’s qmail ? For instance : i would like to run smtps on port 665

Aber nun gut, lassen wir das für einen Moment so stehen und wenden uns dem Thema zu, das mich erst auf diese ganze Thematik gebracht hat, und das für mich vor allem deshalb so ein „Aufreger“ ist, weil es dazu Howtos über Howtos gibt und praktisch alle in puncto SSL falsch sind – wahrscheinlich schreiben alle voneinander ab. Hier findet sich in zig Howtos der Hinweis, dass Spamdyke auf Plesk-Systemen in /etc/xinetd.d/smtp_psa und /etc/xinetd.d/smtps_psa eingetragen werden muss. Das ist so auch nicht ganz falsch – allerdings geben fast alle Howtos an, dass man dort das Gleiche eintragen soll; viele liefern sogar konkrete Konfigurationsbeispiele, die aber vor Veröffentlichung definitiv nie getestet worden sein können. Dann hätte nämlich auffallen müssen, dass sie in der Realität überhaupt nicht funktionieren – nicht mit SSL.

Und so finden wir falsche Howtos im offiziellen Plesk-Forum, im inoffiziellen Plesk-Forum, im Serversupport-Forum, nochmal dort, im Howto des RootForums, in der Anleitung von huschi.net, bei Blue Orix oder bei Haggybear, um nur eine kleine Auswahl an Quellen zu nennen. Hier und da (aber Ausnahmen bestätigen ja bekanntlich die Regel) findet sich auch jemand, der es richtig macht, zum Beispiel The BOFH. Andere kriegen es auch hin, so wie Alexander Koch, wenngleich auf ganz andere Weise (nämlich, in dem gar nicht von der SMTPS-Funktionalität Gebrauch gemacht wird, sondern in dem stunnel als Wrapper eingesetzt wird – was aber fraglos auch eine legitime Lösung ist, nur eben eine aufwendige).

Im Endeffekt laufen alle Howtos darauf hinaus, dass man spamdyke vor den Aufruf von qmail-smtpd setzen soll. Aus

server_args = [...] /var/qmail/bin/qmail-smtpd [...]

soll also werden:

server_args = [...] /usr/local/bin/spamdyke -f /etc/spamdyke.conf \
              /var/qmail/bin/qmail-smtpd [...]

Und genau da liegt der Knackpunkt. Die TCP-Verbindung kommt jetzt ja nun nicht mehr bei qmail-smtpd an, sondern bei spamdyke. Und so schön und gut es auch ist, dass qmail-smtpd eine Umgebungsvariable namens SMTPS interpretiert, und so tricky und gruselig es ist auch ist, dass Plesks tcp-env diese Umgebungsvariable heimlich setzt: spamdyke hat deswegen noch lange keine Ahnung davon – und spricht deshalb auch auf Port 465 schlicht und einfach Plaintext. Warum um alles in der Welt sollte es auch etwas anderes tun?

Praktischerweise kann man spamdyke sagen, dass es SSL sprechen soll. Nämlich, in dem man tls-level=smtps setzt anstelle des Defaults tls-level=smtp. Nur tut das keins der oben genannten Howtos! Es kann also überhaupt nicht funktionieren.

Die Abhilfe ist dann letztlich trivial. Entweder man legt sich eine zweite Konfigurationsdatei für spamdyke an, zum Beispiel eine spamdyke-smtps.conf, die eine Kopie des Originals ist, aber tls-level=smtps beinhaltet. In der xinetd-Konfiguration sieht das dann so aus:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock \
                /usr/local/bin/spamdyke -f /etc/spamdyke-smtps.conf \
                /var/qmail/bin/qmail-smtpd [...]
}

Oder man hat verständlicherweise keine Lust, eine zweite Konfigurationsdatei zu pflegen, und setzt die Angabe direkt als Parameter mit in den Programmaufruf ein:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock \
                /usr/local/bin/spamdyke -f /etc/spamdyke.conf --tls-level=smtps \
                /var/qmail/bin/qmail-smtpd [...]
}

So, und damit wir jetzt zum Schluss alle nochmal herzhaft lachen können:

Alle, wir alle inklusive mir, hätten eigentlich nur die ganz offizielle INSTALL.txt von spamdyke lesen müssen. Dort lesen wir schnöde vier Zeilen:

   Plesk users can also use spamdyke for their SMTPS connections by adding it to
   the /etc/xinetd.d/smtps_psa file.  spamdyke's configuration in that file will
   need to include the options "tls-level" (set to "smtps") and
   "tls-certificate-file".

Das wär’s auch schon gewesen. Aber andererseits: Ansonsten wäre ich nie darauf gekommen, wie Plesk das mit dem SSL eigentlich macht. Insofern hat sich’s doch gelohnt …

Rede ich mit einer Wand?

Montag, 23. März 2009

Für einen Kunden wollte ich ein SSL-Zertifikat verlängern. Bei Thawte. Ich war es gewohnt, dass zumindest bei einem Renewal nach einem Jahr noch nicht die Unterlagen (HR-Auszug etc.) neu eingereicht werden müssen und war von daher einigermaßen überrascht, als mir die Statusseite des Zertifikats anzeigte: „all renewals need to be re-authenticated and will no longer be issued automatically“. Aber nun gut. Also wollte ich die mir ja noch vorliegende Dokumentation nochmal losschicken. Dazu steht auf der Statusseite: „Your documentation is being processed by our Customer Services team. You can contact the Representative working on your order directly.“

Schade, schade, schade: Die mit dem Wort „Representative“ verlinkte Adresse b_eu_general_entry@thawte.com existiert überhaupt nicht. Das Logfile meines Mailservers notiert:

starting delivery 686131: msg 1673822 to remote b_eu_general_entry@thawte.com
delivery 686131: failure: 64.18.5.10_does_not_like_recipient.
Remote_host_said:_550_No_such_user_-_psmtp/Giving_up_on_64.18.5.10.

Also dachte ich mir, hm, wäre doch eine gute Idee, den Thawte-Support darauf hinzuweisen. Ich öffne ein „Live Chat“-Fenster, berichte, wo genau die fehlerhafte Adresse verlinkt ist und sende die Fehlermeldung des Mailservers mit. Jeremy E, mit dem ich chatte, teilt mir freundlicherweise mit, dass das ja nicht schlimm sei und mein Zertifikat ja schon praktisch auf dem Weg sei:

Jeremy E: This certificate will be issued soon, and an email willb e sent to thawte@jonaspasche.com, it should be issued within the next hour or so, I am not sure where that email address will come into play

Er sei sich nicht sicher, wo diese Mailadresse überhaupt „into play“ komme? Ich erläutere, dass da doch steht, dass man nun auch bei jedem Renewal die Doku erneut einschicken solle und es von daher doch eine gute Idee wäre, für das Einsenden auch eine funktionierende Adresse anzugeben.

Jeremy E ist nicht beeindruckt. Er meint weiterhin, es ginge hier um speziell das eine Zertifikat, das ich gerade verlängern lassen will, und betont, ich brauche die Adresse doch gar nicht, das Zertifikat sei doch schon unterwegs.

Jeremy E: Yes, but your one will be issued, as it is only awaiting issuance.

Jaaa, ich weiß. Hast du mir schon gesagt, Jeremy. Ich weise darauf hin, dass es doch zumindest für andere Kunden relevant sei, eine funktionierende Adresse bereitgestellt zu bekommen:

Jonas Pasche: Fine!
Jonas Pasche: However, the e-mail address published on the status page should be fixed IMHO …

Jeremy E hat mittlerweile schon vergessen, um welche Adresse es geht und fragt:

Jeremy E: Which email address do you have there?

Oh bitte, das habe ich doch bereits oben geschrieben. Zusammen mit einem Logfile-Auszug. Aber gut:

Jonas Pasche: The word „Representative“ on the status page is linked to: b_eu_general_entry@thawte.com

Jetzt könnte es doch mal in der Sache vorangehen. Nicht so bei Schnellmerker Jeremy:

Jeremy E: I dont think you should worry about that honestly Jonas, your certificate is already pending issuance, so you will receive an email at thawte@jonaspasche.com when it has been issued, then you can simply install that to your server.

Meine Kollegen schauen schon etwas merkwürdig, als ich mit dem Kopf auf die Tischplatte schlage.

Jonas Pasche: Yes, I understood that. Thank you. However, OTHER users might worry about a non-functional e-mail address on your status page.

Ich werde dann bei der nächsten Verlängerung mal schauen, ob sich was bei der Adresse getan hat …


Impressum