Skip to content

Sichere Kommunikation ...

Sichere Kommunikation ist toll. Darunter verstehe ich neben anderen Punkten vor allem, dass die Kommunikationswege verschlüsselt sind. Als Grundlage für eine Diskussion kann dieser Artikel von Kristian Köhntopp dienen. Um die richtigen Kanäle auszuwählen, sucht man sich am besten die, die auf einem "S" enden: HTTPS, IMAPS, POP3S, SSH (ja, ok, das "S" ist vorne), FTPS, SMTPS ...

Wobei ich aber nahezu einen Herzklappenabriss bekomme, wenn den Zertifikaten keine Aufmerksamkeit gezollt wird (oder wenn aus irgendwelchen fadenscheinigen Gründen nicht die Standard-Ports der Dienste verwendet werden, aber das ist ein anderes Thema).

Es ist nicht sinnvoll, nein, schärfer, es ist falsch zu verschlüsseln, wenn die Zertifikate nicht in Ordnung sind. Auch, wenn es bitter ist, selbst-signierte Zertifikate helfen genauso wenig, wie Zertifikate von nicht anerkannten Zertifizierungsstelle (wie leider auch CAcert) oder abgelaufene Zertifikate. Die User bekommen in diesem Fall eine Routine, die Fehler-Meldungen einfach wegzuklicken und sich keine Gedanken darüber zu machen. Das ist nicht gut.

Nehmen wir einmal an, ich würde in einer Bank arbeiten, ich würde die Proxies so konfigurieren, dass sie Datenverkehr mit falschen oder fehlerhaften Zertifikaten gar nicht erst zulassen.

Sie haben Ihr Ziel nicht erreicht!

Ach ja, ich komme darauf, weil das Zertifikat bei Diaspora gerade abgelaufen ist.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Sebastian am :

*Woher bekommt man denn so ein Zertifikat und was kostet das?
Denn für viele Personen und Projekte wird es wohl schon daran scheitern.

Dirk Deimeke am :

*Wenn es daran scheitert, dann sollten sie es weglassen. Ein nicht vertrauenswürdiges selbst erstelltes Zertifikat trägt nur zur Verunsicherung bei und nicht zur Sicherheit.

Wir nutzen derzeit StartSSL, die mittlerweile auch nicht mehr den besten Ruf haben. GoDaddy liegt bei 50 EUR pro Jahr.

Stefan am :

*Das Problem der im Unternehmensproxy gesperrten selbst signierten Zertifikate kenne ich aus Anwendersicht leider nur zu gut. Daher war ich gezwungen, mir für meine eigene Website ein "echtes" Zertifikat zuzulegen.

Ich habe gute Erfahrungen mit RapidSSL gemacht: ca. 14 EUR pro Jahr für ein gültiges, in allen aktuellen Browsern (und insb. vom Proxy!) akzeptiertes Zertifikat. Für eine private Website absolut ausreichend.

Chris am :

*Danke für den Hinweis!

besser noch TLS (also SSL nach 3.0) verwenden, denn alle älteren Versionen haben bekannte Sicherheitslücken, die mindestens theoretisch ausgenutzt werden können.

Was jetzt nur noch fehlt ist ein Header für HTTP, IMAP, ..., der automatisch dem Client-Programm die Verwendung einer TLS-basierten Verbindung empfiehlt, wenn sie denn verfügbar ist.

Dirk Deimeke am :

*Das ist eine gute Idee, bei SMTP klappt das ja schon (je nach Mailserver), der gibt an, welche Verfahren er beherrscht.

Chris am :

*btw: Ich kann auf diese Seite mit keinem meiner Browser von meinem Ubuntu 11.10 amd64 zugreifen. Die Browser mit Fehlermeldungen:

Chromium 17.0 Beta
„Fehler 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL-Protokollfehler“

Epiphany 3.2.0:
„SSL handshake failed.“

Firefox 9 Beta1:
„SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat.
(Fehlercode: ssl_error_rx_record_too_long)“

Opera 11.52 (stable):
„Sichere Verbindung: Schwerer Fehler (552)“

Chris am :

*Deine: https://www.deimeke.net/...

Dirk Deimeke am :

*deimeke.net bietet kein SSL, das sollte ich mal dem Webserver sagen.

Danke für den Hinweis.

Chris am :

*Ok, ich hab deinen Kommentar zu #1 falsch verstanden ...

Dirk Deimeke am :

*Wir nutzen die Zertifikate für unsere Verwaltungsdomain, über die Webmail, phpMyAdmin und derlei mehr laufen.

Christian am :

*Ein sehr schöner Blog :-) allerdings muss ich jetzt doch mal eine Frage los lassen.

Wieso sind selbstausgestellte Zertifikate ("schwachsinn") alles andere als Sicher??

Ich selbst habe mir jetzt einen kleinen Server zusammengestellt um daran immer mal runzuspielen, ein zentrales Datenlager und ein Wiki laufen zu lassen. Alles über Virtualisierung (www.Proxmox.com). Wenn ich jetzt per https bzw. ssh auf den Server bzw. das WebFrontend zugreifen will wäre ja ein Zertifikat recht praktisch. Nun stellt sich mir die Frage, nachdem ich das hier gelesen habe. Macht nun so ein Zertifikat für meine Anforderungen sinn oder eher nicht?

Dirk Deimeke am :

*Ein Zertifikat hat zwei Nutzen. Der eine ist die Verschlüsselung zwischen Client und Server. Und der andere ist, die Authentizität der Gegenstelle sicherzustellen.

Wenn Du nun genötigt bist, bei der Nutzung des Zertifikats eine Warnmeldung wegzuklicken, wird das zur Gewohnheit und die kann dazu führen, dass Du gar nicht mitbekommst, dass jemand anderes das Zertifikat austauscht und damit sind beide Nutzen hinfällig.

Es könnte sich ja einfach jemand in die Mitte stellen und Deinen Datentransfer belauschen, bevor er ihn weiterleitet.

Christian am :

*Ja, die Menschen sind Gewohnheitstiere, das leuchtet ein.
Stellt sich mir nur die Frage, wieso ist es überhaupt nötig eine solche Warnmeldung wegzuklicken? Was beinhaltet die Warnmeldung?
Ich dachte eigentlich immer das eine solche Warnmeldung eben nur dann kommt wenn das Zertifikat veraltet ist oder so.

Dirk Deimeke am :

*Siehst Du? Genau das ist das Problem. Du liest noch nicht einmal die Warnung. Ein besseres Beispiel hätte ich nicht finden können.

Oft ist die Meldung, dass nicht sichergestellt werden kann, dass auf der anderen Seite tatsächlich der gewollte Geprächspartner ist.

Christian am :

*Alles was ich hier sage ist reine Spekulation. Ich habe mich damit noch so gut wie gar nicht befasst. Ich bin einfach davon ausgegangen das bei solchen Situationen, so eine Warnmeldung kommt.

Wenn das Stimmt was du sagst kommt es so rüber als seien alle Arten von Zertifikate quatsch.
Worin unterscheiden sich den die 2 Zertifikate (eigenes vs. Zertifizierungsstelle) wenn eins von der Zertifizierungsstelle eine solche Warnmeldung nicht bringt? Oder verstehe ich das jetzt alles Falsch? Ich werde mich bei Zeiten mal damit belesen, aber erstmal gehen die Prüfungen vor! :-)

Dirk Deimeke am :

*Nein, nicht alle Zertifikate sind falsch ;-)

Bei denen einer Zertifizierungsstelle unterschreibt (signiert) sie mit ihrem Schlüssel, dass sie dem Zertifikat vertraut. Du kannst diese Signatur prüfen und wenn Du der Zertifizierungsstelle und der richtigen Signatur vertraust, vertraust Du auch dem Zertifikat.

In Deinem Browser sind eine Reihe von Zertifizierungsstellen bereits "eingebaut" und wenn diese Zertifikate signieren, vertraust Dein Browser den so unterschriebenen Zertifikaten.

Wenn eine Zertifizierungsstelle Mist baut, kannst Du sie aus der Browserliste entfernen (die nennen sich CAs).

Christian am :

*Und das was du gerade ansprichst geht nicht mit eigenen Zertifikatsstellen?

Natürlich ist mal dann selbst für die Zertifikatsstelle Verantwortlich und muss selbst merken wenn diese unterwandert worden ist. Aber vom Prinzip her ist es doch dann genau so sicher wie bei einer anderen Zertifikatsstelle. Oder ist es so einfach möglich eine Zertifikatsstelle "Punkt" genau nachzubauen.

Ich wünsche dir, Dirk, und den restlichen Lesern noch ein Gesunden Start in das neue Jahr.

Dirk Deimeke am :

*Das wünsche ich Dir auch.

Wenn Du eine eigene Stelle aufbaust, ist die nicht automatisch in allen Browsern enthalten. Und genau darum geht es, Nutzer klicken gedankenlos auf "aktzeptieren".

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen