Verified by Visa – Unsicherheit mit System

Früher konnte man mit einer Kreditkarte einfach online zahlen, indem man Kreditkartennummer und Gültigkeitsdatum (und später noch CVV2) eingegeben hat. Das hatte den Nachteil, dass ein Betrüger, der diese Angaben erfahren hat, auch mit der Karte einkaufen konnte. Besonders einfach ist es natürlich, wenn ein Händler selbst der Betrüger ist oder mit Betrügern zusammenarbeitet.

Deswegen haben sich die Kartenherausgeber ein System ausgedacht, was dieses Problem lösen sollte: Der Händler leitet einen auf die Seite der Bank um, dort meldet man sich mit einem Kennwort an, was nur dem Karteninhaber und der Bank bekannt ist, und die Bank bestätigt, dass der Karteninhaber sich angemeldet hat. Visa nennt das „Verified by Visa“, Mastercard nennt es „Mastercard SecureCode“, und allgemein werden diese Verfahren als 3-D-Secure-Verfahren bezeichnet. Da das Passwort im Gegensatz zu den Kreditkartendaten immer nur zwischen Kunde und Bank (verschlüsselt) ausgetauscht wird, ist es für Betrüger deutlich schwerer, an dieses Passwort zu gelangen. Eigentlich genial.

Eigentlich. Wenn der Nutzer auch tatsächlich das Passwort nur auf der Bankseite eingibt. Dafür muss er wissen, wie er die Bankseite erkennt, und auch darauf achten. Idealerweise, indem die Verifikationsseite, auf der der Kunde sein Verified-by-Visa-Passwort eingibt, auf der dem Kunden bekannten Domain seiner Bank betrieben wird. Aus unerklärlichen Gründen passiert genau das leider oft nicht, und ein Kunde kann nicht wissen, ob die Seite wirklich zu seiner Bank gehört oder nicht. Auch dafür gibt es eine Lösung: Mit EV-Zertifikaten wird der Name des Webseitenbetreibers neben der Adresszeile angezeigt (Beispiel). Darauf könnte man die Kunden trainieren, und Kunden mit Ahnung von IT-Sicherheit hätten etwas, worauf sie sich verlassen könnten.

Das setzt aber voraus, dass die Kunden wirklich auf die Bankseite umgeleitet werden, und somit sehen können, auf welcher Seite sie sind. Immer mehr Händler binden die Bankwebsite aber per IFrame in ihre eigene Website ein, statt den Kunden auf die Bankwebsite umzuleiten. Ohne den Quelltext der Seite auseinanderzunehmen, kann der Kunde nicht sehen, ob das Eingabeformular wirklich von seiner Bank stammt, oder einfach das Passwort einem betrügerischen Onlineshop (oder einem Hacker, der einen echten Onlineshop manipuliert hat) ausliefert. Was eigentlich ein untrügliches Zeichen für Phishing ist (Eingabeformular für Bankpasswort auf Nicht-Bank-Website), ist bei Verified-by-Visa/3D-Secure nicht nur völlig normal, sondern sogar die ausdrücklich empfohlene Art, das 3D Secure-Verfahren umzusetzen.

Um dem Kunden die Echtheit der Seite zu bestätigen, gibt es daher eine „persönliche Begrüßung“, die nach der Eingabe der Kreditkartennummer, aber vor der Eingabe des Passworts, angezeigt wird. Dieses auch auf anderen Seiten beliebte Verfahren ist völlig wirkungslose Scheinsicherheit: Eine bösartige Website, die das Passwort abgreifen will, kann per Software die Website der Bank besuchen, die Kreditkartennummer des Kunden dort eingeben, und bekommt daraufhin die persönliche Begrüßung mitgeteilt. Diese kann sie nun dem Kunden anzeigen und sich so als besonders echt ausweisen. Theoretisch könnte das gegen „dumme“ Phishingseiten schützen, die sich diese Mühe nicht machen wollen, praktisch wird dort das Fehlen der Begrüßung aber den meisten Kunden nicht auffallen.

Das Verfahren mit Kreditkartennummer, Gültigkeitsdatum und später CVV2 war auch notorisch unsicher, führte zu Missbrauch, aber es war bequem. Die Kartenherausgeber nahmen das bewusst in Kauf und übernahmen die Schäden, weil die Kreditkarten gerade durch ihre Bequemlichkeit attraktiv waren – den Kunden konnte die Unsicherheit egal sein, da die Kreditkartenherausgeber die Schäden übernahmen. Mit der Einführung von Verified by Visa/3-D Secure könnte sich das ändern. Mit dem Argument, das Verfahren sei sicher und jeder Missbrauch sei auf Fahrlässigkeit des Kunden zurückzuführen, könnten Banken nun versuchen, die Schäden auf Kunden abzuwälzen. Insbesondere das sinnlose Verfahren mit der persönlichen Begrüßung stinkt förmlich danach, dass das System als deutlich sicherer dargestellt werden soll, als es ist.

Deswegen schreibe ich diesen Beitrag: Das Verfahren ist unsicherer Murks, aber der Kunde hat keine andere Wahl, als es zu benutzen, wenn er seine Kreditkarte nutzen will. Solange die Bank dafür haftet, ist das auch völlig OK. Sollte eine Bank aber versuchen, die Folgen ihrer eigenen Fahrlässigkeit auf die Kunden abzuwälzen, ist dies inakzeptabel. Ich hoffe, dieses Posting trägt dazu bei, dass die Unsicherheit von Verified-by-Visa/3-D Secure besser bekannt wird, und es Banken dadurch schwerer wird, die Schäden unrechtmäßig auf ihre Kunden abzuwälzen.

Das Problem ist übrigens nicht neu und es haben schon zig Leute darüber geschrieben – siehe z. B. das Paper von Steven J. Murdoch und Ross Anderson, die regelmäßig vermurkste Bank-Sicherheitssysteme auseinandernehmen. Von Ross Anderson ist auch dieser herrliche offene Brief (Leseempfehlung!) an einen Kartenherausgeber-Verband, der die Publikation unangenehmer Forschungsergebnisse mit rechtlichen Drohungen verhindern wollte. Anderson findet in seinem vor Sarkasmus triefenden Meisterwerk  sehr deutliche Worte für das Abwälzen von Schäden durch unsichere Systeme auf die Kunden, indem behauptet wird, die Systeme seien sicher.

 

Es gibt noch einen weiteren, viel banaleren Grund, warum ich Verified by Visa hasse: Es ist lästig. Da man in Deutschland Kreditkarten online meist ca. einmal im Jahr braucht, kann ich mir das Passwort nie merken (speichern/aufschreiben darf man es natürlich auch nicht, und die sinnlosen Beschränkungen auf 8-10 Zeichen, die die Comdirect einem aufzwingt, tun ihr übriges). So besteht eine Kreditkartenzahlung für mich immer daraus, dass ich mich bei meiner Bank einloggen und dort mittls PIN+iTAN ein neues Kennwort setzen muss. Sehr komfortabel. Insbesondere, wenn die Bank wie gerade eben Wartungsarbeiten hat, und ich meine Kreditkarte deswegen nicht nutzen kann, oder wenn man dringend unterwegs ein Zugticket per Kreditkarte online bezahlen muss, aber die TAN-Liste zu Hause liegt. Die Kreditkarte ist so vom bequemsten Online-Zahlungsverfahren zum Umständlichsten geworden, ohne auch nur ansatzweise vergleichbare Sicherheit zu bieten. Herzlichen Glückwunsch.

Bundestag kann SSL abhören

Der Bundestag kann SSL-gesicherte Verbindungen abhören. SSL ist vielen vielleicht nur als „https“ bekannt und sichert neben Onlinebanking auch z. B. Verbindungen zu E-Mail-Servern und ziemlich viele andere Sachen. (Kurzzusammenfassung für Leute die sich mit SSL auskennen: Der Bundestag hat ne CA. Der Artikel erklärt halbwegs laienfreundlich genau das, die Grundidee hinter SSL und warum SSL kaputt ist.)

SSL funktioniert so: Eine vertrauenswürdige Stelle stellt dem Server einen Ausweis aus, den er vorzeigt, und darüber wird die Verbindung verschlüsselt. Das nennt sich Zertifikat und die technischen Details habe ich schonmal erklärt, hier will ich es einfach halten. Ein Angreifer kann sich in die Verbindung nicht einklinken, weil er keinen passendes Zertifikat hat (nur der Besitzer oder jemand der das Original kopiert hat kann ein Zertifikat zeigen, weil beim Zeigen ein Teil geheim bleibt. Klingt komisch, ist aber Mathematik.)

In jedem Browser ist eine Liste der aus Sicht des Browsers vertrauenswürdigen Stellen enthalten. Das sind ungefähr 50 Stück und zwar auch solche, die man vielleicht nicht ganz so vertrauenswürdig findet, wie z. B. die chinesische Internetbehörde.

Die Sicherheit von SSL beruht darauf, dass ein Angreifer kein Zertifikat bekommt für die Seite, deren Datenverkehr er abhören will. Wenn jemand den Datenverkehr zur Postbank abhören will, muss er also jemanden finden, der ihm ein Zertifikat ausstellt, was bestätigt dass ihm Postbank.de gehört. Das kann aber jede der vertrauenswürdigen Zertifizierungsstellen.

Es wird noch „besser“: Die Zertifizierungsstellen können jedermann zu einer Zertifizierungsstelle machen. Derjenige hat dann die gleichen Möglichkeiten wie die im Browser eingetragenen Zertifizierunsstellen. Neben den 50 Stellen können also noch viele viele weitere ein falsches Zertifikat ausstellen – und mit einem solchen kann man eine eigentlich gesicherte Verbindung abhören. (Das funktioniert so, dass der Angreifer die Verbindung über sich umleitet und behauptet, er sei die Postbank – über das Zertifikat prüft der Browser ob das stimmt.)

Zertifizierungsstellen kürzt man übrigens mit CA ab.

SSL ist also unsicher, wenn

• Eine einzige dieser CAs einen Fehler macht und ein Zertifikat ausstellt ohne zu merken, dass der Angreifer nicht die Postbank ist
• Eine CA dem Angreifer bewusst oder z. B. über einen erpressten Mitarbeiter ein falsches Zertifikat ausstellt (man denke an Geheimdienste oder Industriespionage, viele CAs werden von Regierungen/regierungsnahen Organisationen und noch mehr von Firmen die eigentlich was ganz anderes machen betrieben)
• Der Angreifer eine eigene CA hat/ist/kauft
• eine Sicherheitslücke im Protokoll oder im benutzten Browser/Server auftaucht
• oder irgendwas was ich vergessen hab passiert

Fehler sind schon oft passiert. Ein paar Forscher haben mal das Internet nach SSL-Zertifikaten abgegrast und das zusammen mit ein paar anderen Sicherheitsproblemen auf der DefCon präsentiert. Sie sind auf über 500 Organisationen gekommen die direkt oder indirekt eine CA haben.

Weiterhin haben sie gemerkt, dass CAs ca. 500 noch gültige Zertifikate, die praktisch „geknackt“ sind (durch eine Sicherheitslücke bei Debian) nicht für ungültig erklärt haben, und gültige Zertifikate für private IPs. Das ist in etwa so wie ein Ausweis der bestätigt dass Büro Nummer 37 einer bestimmten Person gehört – ohne zu sagen, von welchem Haus in welcher Stadt man redet. Das scheint übrigens dann das Ausnutzen eine anderen Sicherheitslücke zu erlauben (vereinfacht: man sagt dem Nutzer, dass er die Postbank im gleichen Flur in Büro 37 suchen soll, geht in dieses fremde Büro und zeigt dann wenn der Nutzer kommt den Ausweis vor. Deswegen darf es so einen Ausweis eigentlich nicht geben).

Ach ja, und um zu prüfen, ob jemandem eine Domain gehört, wird eine Mail verschickt. Über oft unverschlüsseltes SMTP. Nachdem über bisher ungesichertes DNS nachgeschaut wurde, wohin die Mail gehen soll. Wenn also jemand es schafft, eine dieser Verbindungen zu manipulieren, bekommt er falsche Zertifikate.

Trotzdem sollte man SSL benutzen. Ohne SSL kann ein Angreifer einfach so mithören, was passiert. Mit SSL muss er selbst bei groben Sicherheitsproblemen (z. B. Zertifikate gar nicht prüfen) auch Kommunikation manipulieren statt einfach nur mitzuhören (geht recht leicht, ist aber eine Hürde). Selbst wenn eine CA falsche Zertifikate ausstellt, muss der Angreifer diese finden und sie muss auch ihm so ein Zertifikat geben. Wenn z. B. die Telekom dem BND ein Zertifikat geben würde (was ich jetzt nicht unterstellen möchte), würde sie es immer noch nicht mit einem gewöhnlichen Kriminellen tun. Auch hier wird also eine Hürde geschaffen.

Schützen kann man sich nur bedingt. Die Firefox-Extension CertPatrol zeigt an, wenn sich ein Zertifikat ändert, und auf Wunsch auch bei neuen Zertifikaten, wer es ausgestellt hat. Dabei machen sowohl die Extension als auch Firefox (beim Klick auf das blaue „gesicherte Verbindung“-Feld in der Adressleiste) einen groben Fehler, den ich hier allerdings noch nicht erklären werde. Erinnert mich in nem Monat dran wenn ich nicht dran denke. (Update: In CertPatrol inzwischen behoben – es wird/wurde nur die CA angezeigt, die das Zertifikat ausgestellt hat. Ein Angreifer, der eine falsche CA hat, kann aber erst eine andere falsche CA mit beliebigem Namen erstellen, und damit dann das Cert ausstellen.) Mit dieser Extension habe ich auch gemerkt, dass der E-Petitionsserver des Bundestags plötzlich ein von der mir bis dahin unbekannten Bundestags-CA ausgestelltes Zertifikat hat. Damit könnte der Bundestag theoretisch falsche Zertifikate ausstellen und so SSL-Verbindungen abhören.

Beim Ausstellen falscher Zertifikate geht die CA aber ein gewisses Risiko ein – normale Nutzer merken das nicht, aber wenn es mal einer mit z. B. CertPatrol merkt und das Zertifikat abspeichert, kann die CA sich nicht völlig herausreden, das Zertifikat verrät unabstreitbar wer es ausgestellt hat. Sie muss es auf einen Fehler schieben und hoffen dass nichts passiert. Wenn sich solche Fehler häufen, düfte die CA aus den Vertrauenslisten in den Browsern rausfliegen und andere CAs dürften sich hüten, diese Organisation wieder in den CA-Status zu heben. Um Zertifikate direkt abspeichern zu können, wenn sie auftauchen (und so das Risiko zu vermeiden, dass beim Abruf mit einem anderen Tool wieder das „saubere“ Zertifikat drin ist), kann man die Extension Cert Viewer Plus nutzen.

Die Bundestags-CA wurde vom DFN (Deutsches Forschungsnetz) bestätigt, welches wiederum seine CA von der Telekom bestätigt bekommen hat. Hier die Zertifikate:

Certification path for "epetitionen.bundestag.de"
Inhaber: C=DE,ST=Berlin,L=Berlin,O=Deutscher Bundestag,OU=PetA,CN=epetitionen.bundestag.de
Aussteller: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Validität: from 2010-09-27 13:09:06 UTC to 2015-09-26 13:09:06 UTC
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIEEMAVAjANBgkqhkiG9w0BAQUFADCBlDELMAkGA1UEBhMC
REUxHDAaBgNVBAoTE0RldXRzY2hlciBCdW5kZXN0YWcxHDAaBgNVBAsTE0RldXRz
Y2hlciBCdW5kZXN0YWcxJTAjBgNVBAMTHERldXRzY2hlciBCdW5kZXN0YWcgQ0Eg
LSBHMDExIjAgBgkqhkiG9w0BCQEWE3BraS1jYUBidW5kZXN0YWcuZGUwHhcNMTAw
OTI3MTMwOTA2WhcNMTUwOTI2MTMwOTA2WjB/MQswCQYDVQQGEwJERTEPMA0GA1UE
CBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xHDAaBgNVBAoTE0RldXRzY2hlciBC
dW5kZXN0YWcxDTALBgNVBAsTBFBldEExITAfBgNVBAMTGGVwZXRpdGlvbmVuLmJ1
bmRlc3RhZy5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxlR8dG
FjtzBE05l7RKRgQwy6DSzLE8qeoPuycX4VrYvgRdX0NyeoZ3h9MqT0DJHvXAWS+d
BHkNrnhRHFf4cxZsIbSjnrSr311QUmwityCoinESNqXAdY/i466/TEE+GcUOS4t2
Mfmba8Zi3qKGspgcGec14xuyNc8ENlKvTjKBC+mJrjlh/Gpb3VW/rNh65V8EXvbW
vlXbyDbZ/5n57TZqM2bblPWRnh/Zual54Y/khqlPdWuNxHMSr+OtvgXW/aJGWOzh
uusPIzxp1uYgd7PMCvP5aHf1w5mMy3Em1c6w8PiH7Fq1yDa1CbpFpq+SHQ0NF2lu
lQecru1cdFefpsUCAwEAAaOCAcwwggHIMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXg
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUJUpy4/No
XDOu0LAY+DNj7g+E51QwHwYDVR0jBBgwFoAUd42VgQQK41VYmdALyblb5SJ+LjYw
gZkGA1UdHwSBkTCBjjBFoEOgQYY/aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZXV0
c2NoZXItYnVuZGVzdGFnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMEWgQ6BBhj9odHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Ny
bC9jYWNybC5jcmwwgbIGCCsGAQUFBwEBBIGlMIGiME8GCCsGAQUFBzAChkNodHRw
Oi8vY2RwMS5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Nh
Y2VydC9jYWNlcnQuY3J0ME8GCCsGAQUFBzAChkNodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0
MA0GCSqGSIb3DQEBBQUAA4IBAQB4XvDdQcukMgEEvgLklMuAjrU7GT4SgyiHZCkY
hcEqqOHA0WiP6i1H66MTui00TDVv9QRpjnMgy9jD0QXynWgHG0F07ZrpO+8YBQvL
NsuslkYr9SXMnOOw3AfwDTUbo+sLKWaRiBiVeP6WOrbtCddrbmMvWexf/1M8dx/E
ynIEIyhRgXD/1YyFLzi85I8UP4eCKa38HPxIgI5An5baOjA4rgOH/LyAKV+9659T
/vjTZZ4R2t/ratiLZEoZ1byUqdit3msDQoq5YXKF5DVgMGF+jL6V+wXg8Vu10ajg
KO6AxrzMS+WBgY4PXuwLMY3iO8GL8s0IlAtMu9Ew0svPAH2V
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Aussteller: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Validität: from 2008-12-17 14:39:27 UTC to 2019-06-30 00:00:00 UTC
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIEDWiMrzANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJE
RTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UE
AxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA4MTIxNzE0MzkyN1oX
DTE5MDYzMDAwMDAwMFowgZQxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2No
ZXIgQnVuZGVzdGFnMRwwGgYDVQQLExNEZXV0c2NoZXIgQnVuZGVzdGFnMSUwIwYD
VQQDExxEZXV0c2NoZXIgQnVuZGVzdGFnIENBIC0gRzAxMSIwIAYJKoZIhvcNAQkB
FhNwa2ktY2FAYnVuZGVzdGFnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyV2H0tJjqK2L25XRrdkSyAmCm5AO71u+xAme6ppAunax/aW11Bhn2cet
N3nj0govnSVnOCre2inqvm49d/MVj0zyhhw7v5AG2Ab5WK/4TryLofCHJEEn+1oy
CWnNqBQIjFLawUbhfjOOspPxLujDTdaYDn7Z00nY85c7cRESdW3BbeL0a2OrSJyJ
yW93nR/+of9tsyTLsy9LiKZvRaGnXtYUDy/Sq3MSpgiWjsq95VFBT0lMBE1J+xv7
4ZrXikfZs+o3cfVxFQluLPwmxSqrd4BmH6rTxUb9iFLWwEFWJIYLlV8Z6GG9kxOd
KG9Q+T3QxUqi0Mw7/5hrl8Zs0wXbDQIDAQABo4IBtTCCAbEwEgYDVR0TAQH/BAgw
BgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFHeNlYEECuNVWJnQC8m5W+Ui
fi42MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB4GA1UdEQQXMBWB
E3BraS1jYUBidW5kZXN0YWcuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8v
Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3Js
MD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1
Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7
aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB
BQUAA4IBAQCTl0KbJX0XEEVgNkLeS/dmgJzwcSC6z8aFvhQPzbE08Q/qhWItV4iU
YYZ9nkfuoKzoz1V1CoqEFhE7QRKr0OLMHVs+yJnWXfWEuQ11ph6KMEAvK8b/9J0O
Hz83WRO7pqZp1VWZGZ0Prj3CWkqxUEmFiPcCC3N1pRcVvufimpchB3SA2NeUKE4C
G2fo3XT3q99ltN53wAPGXhqzSVXO8zYIW+bglion3IdeYna/Hzx94RpXNKl5q4pK
e0lSRUtj0k0yWS/YDptFsVPhr5wLm+uVXz/G43/7I5TYEZ56Yz6LqUhrY59XkSeG
6trUzc7DpXEZWvoqFQy/0jonReRX15x9
-----END CERTIFICATE-----
Inhaber: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 2006-12-19 10:29:00 UTC to 2019-06-30 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUx
HDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNl
YyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMC
REUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV
BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0
j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8v0oO
GwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJovZr
zr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z
s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTb
yRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNV
HR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2
aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVy
PURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYD
VR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEGMBIG
A1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjs
ga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5r
eJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/
czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzzje5H
s1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGerI2iN
Y6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+Mzklj
qAD38hw=
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 1999-07-09 12:11:00 UTC to 2019-07-09 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc
MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj
IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENB
IDIwHhcNOTkwNzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxl
U2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290
IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrC6M14IspFLEU
ha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7TuKhC
QN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1Mjwr
rFDa1sPeg5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1S
NNs671x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0moc
QqvF1afPaA+W5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoH
txa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT1xfgiXotF2wKsyudMzAP
BgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOC
AQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756Abrsp
tJh6sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpa
IzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl
6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+
xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9WgbRGOiWrqnNVmh5XAFmw4jV5mU
Cm26OWMohpLzGITY+9HPBVZkVw==
-----END CERTIFICATE-----

Einzelne CAs im Browser rauswerfen bringt wenig, weil gerade die kleinen/neuen CAs oft (nicht öffentlich sichtbare!) Bestätigungen von anderen CAs haben. Wenn man eine CA rauswirft, die viele Zertifikate ausstellt, kann man deren Zertifikate nicht mehr von gefälschten unterscheiden. Da man nicht jedes Zertifikat manuell prüfen kann – ganz schlecht. Am Sinnvollsten dürfte CertPatrol sein und für kritische Sachen eben auf die Warnungen achten und beim ersten Mal das Zertifikat genau prüfen. Interessanterweise hat Microsoft dieses Problem scheinbar erkannt – bei WLAN-Verbindungen wo die Anmeldung über Zertifikate gesichert wird muss man ausdrücklich auswählen, welchen CAs man für diesen Zweck traut, und nur die werden akzeptiert. So kann eine Firma sicherstellen, dass ihre Rechner für die Anmeldung in ihrem WLAN nur ihrer eigenen CA und nicht der des Konkurrenten trauen. Und in der Fehlermeldung wird unterschieden zwischen „Zertifikat einer unbekannten CA“ und „Zertifikat einer bekannten aber nicht angekreuzten CA“ sodass man sich zumindest halbwegs sicher verbinden kann, wenn man die richtige CA nicht weiß.

Für Serverbetreiber gilt: Es spielt keine Rolle, wie sicher die CA ist, die man wählt – wichtig ist nur, welche CA in den Browsern akzeptiert wird. Selbst erstellte (nicht von einer CA bestätigte) Zertifikate sind eine relativ schlechte Lösung – eine CA bietet zusätzlich die Möglichkeit, halbwegs sicher zu sein, selbst wenn man das Zertifikat nicht selbst prüfen konnte. Kostenlose Zertifikate für Webserver gibts bei StartSSL, was bis auf Opera von allen Browsern akzeptiert wird. Das oft vorgeschlagene CAcert ist in den meisten Browsern standardmäßig nicht enthalten und daher IMHO nur zweite Wahl – bietet dafür aber auch andere Zertifikatstypen an.

Fefe hat das Thema auch schon kommentiert und ein weiteres Horrorgeschichtenkabinett findet sich in den „A mighty fortress is our PKI“-Mails von Peter Gutmann: Teil 1, Teil 2, Teil 3

Kostenlose SSL-Zertifikate, auch für IE

Um verschlüsselte Verbindungen über SSL bzw. HTTPS zu ermöglichen, benötigt man als Server-Betreiber ein SSL-Zertifikat. Diese werden von Zertifizierungsstellen, sogenannten CAs, ausgegeben. Die CA überprüft, ob der Bestellende wirklich berechtigt (also Inhaber der Domain) ist, und stellt dann meist gegen viel Geld das Zertifikat aus. Damit kann sich die Website gegenüber einem Browser „ausweisen“ und eine sichere, verschlüsste Verbindung wird möglich. Details gibt es in meinem ausführlichen SSL-Artikel, wo auch noch ein paar Worte über die Sicherheit von SSL stehen.

Nur Zertifikate von CAs, die der Browserhersteller als vertrauenswürdig in den Browser eingebaut hat, werden als gültig erkannt. Deswegen ist es schwierig, eine neue CA aufzubauen, denn die Kriterien für eine Aufnahme sind streng und es gibt viele Browserhersteller, die man zur Aufnahme bewegen muss. Aus diesem Grund gab es bis vor kurzem keine CA, die kostenlos Zertifikate ausgegeben hat und von allen gängigen Browsern akzeptiert wurde. CAcert und StartCom/StartSSL vergeben seit langem kostenlose Zertifikate. CAcert ist jedoch weder in Firefox noch im Internet Explorer als vertrauenswürdig enthalten. Somit kann man CAcert nicht für Seiten benutzen, die von Normalnutzern besucht werden, denn diese würden eine hässliche Sicherheitswarnung erhalten. StartSSL war schon länger in Firefox enthalten, jedoch nicht im Internet Explorer, und war für ernsthafte Nutzung mit unerfahrenen Nutzern daher auch ungeeignet.

StartSSL hat es jetzt aber endlich geschafft, in den Internet Explorer aufgenommen zu werden. Der Internet Explorer akzeptiert die kostenlosen StartSSL-Zertifikate somit seit kurzem als gültig. Dank einer eingebauten Auto-Update-Funktion funktioniert das auch mit veralteten Versionen des IE! Ein IE 6.0 aus meiner Sandbox-VM, Stand Anfang 2008, hat das Zertifikat anstandslos akzeptiert. Mozilla Firefox, Apple Safari (inkl. dem iPhone-Browser), Opera, Google Chrome und einige andere akzeptieren StartSSL schon länger, damit sind alle gängigen Browser abgedeckt. (Lediglich Konqueror unter einer aktuellen (K)Ubuntu-Version hatte Probleme damit.) StartSSL ist somit endlich eine voll einsetzbare CA geworden, und somit gibt es endlich kostenlose SSL-Zertifikate für alle! (StartSSL bietet übrigens auch EV-Zertifikate zu relativ humanen Preisen an.) Edit: Opera (etwa 5% Marktanteil) unterstützt StartSSL scheinbar leider doch noch nicht.

Als Serverbetreiber muss man übrigens der CA nicht besonders vertrauen (solange man nicht irgendwelche sehr besonderen Sachen macht wie Client-Zertifikate, aber das weiß man dann), wichtig ist nur, dass die Browser die CA akzeptieren. Eine bösartige, aber in Browsern als vertrauenswürdig eingetragene CA kann sich jederzeit für jede Website ein Zertifikat ausstellen lassen, unabhängig davon, ob der Websitebetreiber dort Kunde ist oder nicht. Die eigene CA könnte höchstens das eigene Zertifikat widerrufen und somit ungültig machen, aber mehr auch nicht. Darüber hinaus hat die CA noch ein paar persönliche Angaben, die aber bei einfachen Zertifikaten nicht über das hinausgehen, was die meisten Online-Shops auch wissen. Insbesondere den privaten Schlüssel des Zertifikats hat die CA normalerweise nicht! Es gibt zwar oft die Möglichkeit, die CA diesen Schlüssel generieren zu lassen, aber man kann es auch richtig machen und das selbst tun und den eigenen Schlüssel zertifizieren lassen. Selbst wenn man der CA also aus welchem Grund auch immer nicht vollständig vertrauen sollte, kann man sie als Serverbetreiber dennoch nutzen.

Ich erhalte für diesen Artikel keine Vergütung o.ä. von StartSSL/StartCom. Diesen Artikel habe ich geschrieben, weil es mich ankotzt, dass Firmen für das simple Ausstellen eines einfachen domain-validierten Zertifikats horrende Preise (oft sogar dreistellig!) verlangen, und weil ich froh bin, das es endlich eine kostenlose Alternative gibt und ich auf diese hinweisen möchte. Ich selbst habe von der Aufnahme in den IE auch erst heute erfahren. Nutzt diese kostenlose Möglichkeit, um die Datenübertragung zu euren Webseiten zu sichern! Macht diese Möglichkeit bekannt, damit die kommerziellen CAs ihre überzogenen Preise endlich etwas realistischer machen müssen.