aha!

Guten Abend zusammen,

mein Host stellt mir in meinem Webspace neben dem httpdoc Ordner httpsdoc zur Verfügung.
Lege ich hier ne index.html rein und versuche diese im Browser aufzurufen, erhalte ich die Nachricht, dass das Zertifikat (von "Plesk") nicht zertifiziert sei (was an sich ja verständlich ist).

Wenn ich das Zertifikat akzeptiere, ist ja die Verbindung verschlüsselt. htaccess Passwörter werden nicht mehr im Klartext übertragen usw. ...
Nur bei einer Sache bin ich mir nicht sicher, eben weil(!) es sich um ein 'unzertifiziertes' Zertifikat handelt:

Kann Person A nun mittels diesem Zertifikats die Verbindung von Person B und dem Server trotzdem irgendwie "abfangen"?
Wie sicher ist denn also die Verbindung mit diesem "Zertifikat"?

Vielen Dank für die beruhigenden Worte im Voraus und weiterhin einen schönen Abend

Mister Ad

Manko10

Verschlüsselung und Authentifizierung sind zwei verschiedene paar Schuhe, die bei SSL leider in einen Topf geworfen wurden, was an sich verständlich ist, andererseits aber auch wieder nicht.
SSL-Verbindungen sind generell abhörsicher, ob das Zertifikat nun verifiziert ist oder nicht. Die Verifizierung dient nur dazu, den letzten Schritt abzusichern. Der Mann in der Mitte ist ja nun außenvor. Jetzt kann es aber noch sein, dass du gar nicht mit dem Server kommunizierst, mit dem du eigentlich kommunizieren willst, sondern zu irgendeinem bösen Buben, der deine Verbindung manipuliert hat und die Anfragen zu seiner Seite weiterleitet, verbunden bist. Durch das Zertifikat wird sichergestellt, das dies nicht passieren kann.
Das ist auch die Argumentation hinter den SSL-Zertifikaten gewesen: verschlüsselt ist der Kram eh, es lässt sich unterwegs also nichts abhören. Es muss allerdings noch sichergestellt werden, dass das gegenüberliegende Ende auch wirklich das ist, mit dem man sich verbinden will.
Das Ganze ist ein guter Gedanke, wird heutzutage aber leider oft ad absurdum geführt, da normale Zertifikate meist ohne Ansehen der Person einfach durch eine E-Mail etc. verifiziert werden, was sich natürlich mit einigem Aufwand manipulieren lässt. Wirklich vertrauen kann man verifizierten Zertifikaten also auch nicht. Wenn die Adressleiste grün wird und der Mensch oder die Firma hinter der Domain verifiziert wurde, wird es schon vertrauenswürdiger.
Mit der Zeit wurden SSL-Zertifikate aber zu einem lohnenswerten Massengeschäft, sodass ein nicht verifiziertes Zertifikat nicht mehr unbedingt heißen muss „Die Seite ist nicht vertrauenswürdig“ sondern „Der Webmaster wollte nicht sein Geld zum Fenster rauswerfen“. Aus diesem Grunde befürworte ich Projekte wie CACert oder alternative Modelle wie GPG.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

aha!

Vielen Dank für deine ausführliche Antwort Manko10.
Wieder ein Stück mehr gelernt, hier.

Mein Problem wäre also, dass ein Besucher ohne seines Wissens (irgendwie) auf eine andere Seite weitergeleitet werden könnte. Die Fremde Seite schaut der eigentlichen sehr ähnlich (fishing), das Zertifikat ist eine Kopie und somit sofort akzeptiert, er gibt seine Daten, Passwörter ein und zack, hat Person A die Daten.

Wenn ich jetzt den max. 10 Besuchern des Forums (das es zu schützen gilt, da sämtlicher Verkehr über eine fremde VPN-Verbindung läuft) ausdrücklich sage, sie sollen immer auf die URL schauen, dass diese auch ja richtig ist ... würde das dementsprechend reichen?

robo47

Die URL ist nicht relevant.
Wenn sich ein Man-in-the-middle einschleust, tut er so als würde er diese domain repräsentieren nur wird dann anstatt dem zertifikat der domain ein anderes genutzt das er manipuliert hat.

Denke das Bild zeigt es schön:
http://www.pburkholder.com/sysadmin/...tm/webmitm.jpg

Die Kommunikation zum MITM verläuft über dessen zertifikat und von dort aus dann mit deinem.

Was man machen kann ist dem User klar zu machen dass er das Zertifikat
1) verifizieren muss
2) akzeptieren

Mit verifizieren ist hier gemeint dass der User bevor er das Zertifikat akzeptiert, schaut ob der sha1/md5-Hash (Diese musst du ihm dann idealerweise auf einem sicheren Weg zukommen lassen) stimmt, denn damit sollte sich das Zertifikat eindeutig erkennen lassen.

Akzeptiert er es dann nachdem er es verifiziert hat, würde er im Browser eine Fehlermeldung bekommen wenn jemals ein anderes Zertifikat für die Verbindung genutzt wird.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Manko10

Bis vor einiger Zeit waren solche Attacken sogar dadurch möglich, dass man den DNS-Cache einfach manipuliert hat (geht bei manchen Servern bestimmt immer noch) und aus dem Mann in der Mitte ein ganz „legitimer“ Mann am Ende der Leitung wurde. Normale Man-in-the-Middle-Attacken, wie robo sie beschrieben hat, funktionieren aber oft so, dass der gesamte Netzwerkverkehr umgeleitet wird, weshalb hier nicht nur die korrekte Domain, sondern auch die korrekte IP kein Vertrauenskriterium sein können.

Ist der Verkehr aber SSL-Verschlüsselt, so kann der MITM mit dem Datenverkehr nichts mehr anfangen, auch wenn er den Handshake abfängt. Der Handshake wird durch ein asynchrones Verschlüsselungsverfahren abgewickelt. Das heißt, der Client ruft den öffentlichen Schlüssel des Servers ab und schickt ihm dann einen von ihm selbst generierten Schlüssel, den er aber natürlich mit dem öffentlichen Zertifikat des Servers verschlüsselt hat. Jetzt kann der Schlüssel nur noch durch eine Entschlüsselung mit dem zum öffentlichen Schlüssel gehörenden privaten Schlüssel entschlüsselt werden und dieser ist im Idealfall nur dem Server bekannt (wenn nicht, ist das Ganze witzlos). Da dieses Verfahren aber sehr rechenintensiv ist, verläuft die ganz normale Kommunikation jetzt über synchrone Verschlüsselungsverfahren, was jetzt möglich ist, da beide Seiten sich auf einen gemeinsamen Schlüssel geeinigt haben, der nur beiden Seiten bekannt ist.
Das Zertifikat regelt nun noch, dass auch nur der Schlüssel des korrekten Servers verwendet wird. Natürlich könnte der MITM den öffentlichen Teil einfach kopieren und selbst anbieten, aber das brächte ihm herzlich wenig, da er dann jede Menge Datenverkehr auf sich umgelenkt hätte, mit dem er nichts anfangen kann, weil er den privaten Schlüssel nicht kennt, um den Handshake zu entschlüsseln.
Solltest du also nicht öffentlich verifizierte Zertifikate nutzen (anhand meiner Ausführungen solltest du die Absurdität einer einfachen E-Mail-Validierung o.ä. durch die großen TrustCenter sehen können), musst du den anderen Usern, wie robo schon schrieb, den korrekten öffentlichen Schlüssel mit korrektem Zertifikat auf einem gesicherten Weg zukommen lassen (also direkt überreichen oder in einer verschlüsselten E-Mail senden oder so).

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”