adminlife.net – We care for your security!
Vielleicht ist es dem einen oder anderen schon aufgefallen:
Hier im Blog kann man nun über eine verschlüsselte SSL Verbindung surfen. Bei dem Zertifikat handelt es sich um ein “echtes” Class 1 Zertifikat.
Für Interessierte: die Zertifizierung eines Zertifikats bzw. einer Seite und dessen Inhabers teilt sich in folgende Klassen auf:
- Class 0 – keinerlei Prüfung
- Class 1 – geprüfte E-Mailadresse, Prüfung des WHOIS Eintrages
- Class 2 – schriftliche Bestätigung, dass die Angaben korrekt sind
- Class 3 – amtliche Dokumente erforderlich
Für umgerechnet ca. 15EUR pro Jahr gibt es solch ein Zertifikat bei GoDaddy.com (seltsamer Name für eine CA, ich weiß). Das Zertifikat funktioniert mit allen von mir getesteten Browsern, so dass man keine Kompatibiltätsprobleme zu fürchten hat.
Related posts:
- Wildcard SSL Zertifikat mit OpenSSL erstellen Mit Wildcard Zertifikaten kann man beliebig viele Subdomains unterhalb einer Domain mit nur einem Zertifikat...
- adminlife.net wünscht frohe Weihnachten! Ich wünsche allen Blogbesuchern und Feedabonennten ein frohes Weihnachtsfest, ein paar ruhige Stunden im...
- Debugging von SSL-Zertifikaten SSL kann zur Verschlüsselung verschiedenster Protokolle genutzt werden. Neben dem bekannten HTTPS gibt es u.a....
- adminlife.net online Endlich ist mein neuer Blog (fast komplett) online! Nachdem gehirnschnecke.net lange Zeit dank meines vorherigen...
- LPIC-2 Vor ein paar Tagen ist mein LPIC-2 Zertifikat eingetrudelt. Im Gegensatz zum LPIC-1 Zertifikat...



Stefan
Juhuu
Stevie
So, ich weiß nun also, dass ich gerade auf einer Seite bin, die nachweislich von jemandem installiert wurde, der Zugriff auf die in dem WHOIS-Eintrag gelistete Mailadresse hat.
Das heißt, wenn ich den Fähigkeiten des Admins vertraue (dass er also nur selbst Zugriff auf seine Mailbox hat), dann ist das Zertifikat etwas wert. Kenn ich den Admin nicht, hab ich zwar eine verschlüsselte Übertragung zwischen dem Server und mir, weiß aber nicht WER die Daten dann wirklich bekommt – denn das Zertifikat wurde ja an den jenigen ausgeliefert, der die godaddy-mail lesen kann.
Für einen Blog und normale Webseite ist diese Art Zertifikat sicherlich ausreichend. Sollte man aber einen Webshop betreiben, sein Webmail oder andere vertrauliche Applikationen via SSL absichern wollen, wäre eigentlich ein Class 3-Zert unumgänglich.
Aber machen wir uns nichts vor: Die Nutzer schauen, wenn überhaupt, darauf ob “das Schloss in der Fußzeile ist” und damit haben sie genug gecheckt. Traurig, aber wahr. Ein Class 3-Zert ist demnach so gut wie unnötig, so lange man ein Class 1-Zert hat, dessen CA gut unterstützt wird.
matthias
(Fast) Genauso ist es. Class 1 reicht für einfache Anwendungen (evtl. noch für Webmail…). Für Webshops sollte man unbedingt Class 3 nehmen.
Den Usern ist es eh egal, die merken es nicht und kennen wohl auch nicht den Unterschied zwischen Class 1 und Class 3. Höchstens selbstzertifizierte oder abgelaufene Zertifikate, die der Browser anmeckert, werden in ihm Zweifel aufrufen.
Aber eins stimmt nicht ganz: Ein Zugriff auf die Mailbox reicht nicht. Das Zertifikat muss ja auch noch installiert werden auf dem betreffenden Webserver. Also muss der Bösewicht auch noch Zugriff auf den Webserver haben (oder zwischen der Verbindung von Client und Server hocken und dir sein eigenes Zertifikat unterjubeln).
Stevie
Ja, ich weiß. (Aber nach soviel Klugsch… meinerseits hab ich ja auch eine Belehrung verdient)
Es wäre aber z.B. ein DNS-Angriff möglich (Poisoning), der meine Request von http://www.adminlife.net auf einen anderen Server umleitet und mir dies, vor allem durch das installierte Zertifikat, verschleiert wird. (Der Browser prüft ja nur die Übereinstimmung von aufgerufener Adresse und dem CN im Zert).
matthias
Das kann dir aber auch passieren, wenn auf der echten Seite ein Class 3 Zertifikat installiert ist und auf der Fake Seite ein Class 1 Zertifikat. Du prüfst ja nicht bei jedem Seitenaufruf, ob sich das Zertifikat geändert hat, oder?
Also ist somit in dem Fall ein Class 3 Zertifikat nutzlos…
Stevie
Da muss ich dir wiedersprechen, denn: Das Class 3 Zert bekommt ja nur nachgewiesenermaßen der WIRKLICHE Eigentümer der Domain. Sollte mir also auf der von mir besuchten Webseite das C3-Zert angezeigt werden, kann ich davon ausgehen, dass ich wirklich auf der richtigen Seite bin.
Bekomme ich stattdessen das C1-Zert angezeigt, kann ich auf einer Seite sein, die von jemanden, der (zeitweise) Zugriff auf dein Mailkonto hatte, aufgesetzt wurde.
matthias
Wenn der Request auf eine andere IP umgeleitet wird, ist dies doch irrelevant. Vorher war ein Class3 Cert, danach auf der gefälschten Seite ein Class1 Cert. Man würde also nicht unbedingt den Unterschied merken, wenn die Seite komplett gefälscht wäre und sich der Bösewicht die Mühe gemacht hätte, ein Class1 Zertifikat zu beschaffen und zu installieren.
Man würde den Unterschied nur merken, wenn man jedes Mal das Zertifikat überprüft. Aber mal ehrlich: Wer tut das schon?
Stevie
@Wer tut das schon?
Klar, das habe ich ja auch im ersten Comment bereits gesagt. Ich wollte ja mit dem Beispiel ja nur klarstellen, welchen Vorteil ein C3-Zert hätte.
Die Tatsache, dass aber selbst ich bei einem in dieser Form durchgeführtem Angriff hinters Licht geführt werden würde zeigt, dass meine Browser-Einstellungen nicht gut genug sind. Theoretisch müssten man die C1-CA-Zerts rauswerfen, um diese Problematik zu umgehen.
Dann würde ich aber hier zB einen Fehler erhalten.
Alternativ müsste man die Fingerprints pro Site irgendwie freezen können, um bei Veränderungen benachrichtigt zu werden. Gibts da was?
matthias
Class 1 Zertifikate generell als unsicher einzustufen, halte ich für falsch. Schließlich erhöhen sie ja auch die Sicherheit einer Seite: Man weiß, dass die Domain die vorgegeben Domain ist (es sei denn, der Key wurde auf einem geknackten Server eingespielt und mittels eines geknackten Mail Accounts bestätigt worden – das halte ich aber für ziemlich unwahrscheinlich). Und natürlich wird die Client-Server-Kommunikation verschlüsselt.
Jedoch wäre es angebracht, dass SSL Symbol im Browser abzuändern. z.B. verschieden Vertrauenseinstufungen – von hoch (Class3/4) bis niedrig (Class1).
Ein Tool, das diese Aufgabe übernimmt bzw. warnt, wenn sich die Stufe eines Zertifikats ändert, kenne ich auch nicht. Generell wäre soetwas aber als Standardfunktionen in Browsern zu begrüßen.
Stefan
https://bugzilla.mozilla.org/ -> report a bug -> enhancement (müßte gehen, aber du brauchst einen Account)
“request for new feature with ssl” oder so erstellen und dort mal anfragen.
Vielleicht vorher mal suchen, warum das nicht so gemacht wird?!
Cryptronic
Das klingt ja alles schön und gut, aber prinzipiell reicht meiner Ansicht nach auch immer noch CaCert Zertifikate. Das Prinzip von denen ist auch nicht von schlechten Eltern und macht die Website meiner Ansicht nach genauso sicher wie ein Class 1 Zertifikat.
just my 2 cents
Stevie
@Cryptonic:
Das gilt aber nur für den Fall, dass das CA-Zert in deinem Browser als vertrauenswürdige CA installiert ist.
Ist die nicht der Fall, wirft der Browser eine Fehlermeldung á la “gültiges Zert aber fremde CA”. Dann lieber doch Geld für ein Cert von GoDaddy und Co. bezahlen und dafür die User nicht mit einer Fehlermeldung bzw. Abfrage verwirren.
Just my 3 cents
matthias
Ja genau, ich wollte diese nervigen Nag Screens im Browser vermeiden. Nicht viele haben die CaCert Stammzertifikate im Browser installiert. Da hätte ich dann ja fast genauso gut ein stinknormales selbstsigniertes Zertifikat nehmen können.
Daher ein paar Euros für ein Class 1 Zertifikat hingeblättert
Patrick Rauscher
Ich misch mich hier nochma ein… Wie hastes denn eingestellt, dass man von http://www.adminlife.net automatisch auf die ssl-Version umgeleitet wird?
Ich will sowas nähmlich, jetzt wo ich nen CaCert-Zertifikat hab, auch einstelln, hauptsache die Verbindung is verschlüsselt XD
matthias
Für den Apache ist das eine RewriteRule im vHost, der auf Port 80 lauscht:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]
Patrick Rauscher
Wenn du das ganze in einen Block packst, brauchste auch deine RewriteCond net!
<VirtualHost 0.0.0.0:80>
RewriteEngine On
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
</VirtualHost>