pantsoff Geschrieben 21. März 2012 Teilen Geschrieben 21. März 2012 Mahlzeit zusammen, wie im Titel beschrieben habe ich einige Fragen bzgl. der genannten Stichworte und insbesondere ihrer "Wechselwirkungen". Habe heute in einer Testumgebung einen Login/Authentifizierung im OWA (logischerweise https) ohne passendes/installiertes Root CA Zertifikat durchgeführt und das ganze "gewiresharked". Zuvor natürlich die Browser Warnung "Laden der Website fortsetzen" bestätigt (Browser sagt, Ihre Verbindung ist unverschlüsselt->da kein passendes Zertifikat). Im Wireshark konnte ich die Authentifizierungsdaten nicht im Klartext sehen! Daraufhin war ich jedoch verwundert, denn ohne passendes Zertifikat keine Verschlüsselung->Datenfluss im Klartext. Deshalb meine Frage: - Https verschlüsselt ja mit SSL, ist eine Verschlüsselung auch ohne Zertifikat von Haus aus vorhanden, da ich den Login nicht sniffen konnte? Ich dachte bisher, die Authentifizierung selbst verlaufe ohne Verschlüsselung, nach erfolgtem Login würde jedoch eine Encryption/Decryption stattfinden, ähnlich wie bei (je nach Konfiguration) bekannten VPN Protokollen (PPTP, L2TP). Vorab mal danke für eure Denkanstöße! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 21. März 2012 Teilen Geschrieben 21. März 2012 Dein Browser hat dich darauf hingewiesen, das das Zertifikat nicht vertrauenswürdig ist, da es von keiner der ihm bekannten Root-CAs signiert wurde. Das hat aber auf die Verschlüsselung keinen Einfluss! Die Verschlüsselung wird im Rahmen des SSL-Handshakes ausgehandelt. Abhängig vom Server und den Einstellungen im Browser können dann jeweils unterschiedliche Cipher benutzt werden. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 22. März 2012 Autor Teilen Geschrieben 22. März 2012 Moin, wieso zeigt der Browser dann an, dass die Verbindung nicht verschlüsselt ist? Ich dachte erst wenn das root Zert auch installiert ist, vertratut der Client dem Server dahigehend, die Verbindung zu verschlüsseln... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 22. März 2012 Teilen Geschrieben 22. März 2012 Welchen Browser benutzt du? Mach bitte einen Screenshot von der vollständigen Meldungen. Es macht überhaupt keinen Sinn, die Verschlüsselung aufgrund des Zertifikats zu aktivieren oder zu deaktivieren. Bei nicht vertrauenswürdigen Zertifikaten wird die Verbindung ohne Bestätigung nicht hergestellt, um das senden wichtiger Daten (z.B. Passwörter) zu verhindern. Wenn du dein Passwort verschlüsselt an einen falschen Server schickst, ist es trotzdem hinfällig... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 22. März 2012 Autor Teilen Geschrieben 22. März 2012 Moin nochmal, okay fassen wir zusammen: Https ist immer verschlüsselt, egal ob entsprechende Zerts installiert sind oder nicht. Die Verschlüsselung mit SSL ist also unabhängig von den Zertifikate, Sie dienen nur der gegenseitigen Identifizierung. Drehen wir das Rädchen etwas weiter: Exchange->ActiveSync. Ein Iphone schert sich einen feuchten, ob es ein Root CA installiert hat oder nicht. Ein Windows Phone/Mobile dagegen muss das entsprechende Root CA Zert installiert haben, sonst ist eine Verbindung mit activesync nicht möglich. Die Verschlüsselung und Sicherheit der Datenkommunikation ist jedoch sowohl auf dem Iphone als auch auf dem Windows Endgerät vollkommen gleichwertig? Letzter Punkt: Gehen wir weg von Https/SSL und kommen zu X.509 Zerts hinsichtlich z. B. VPN. Hier erfolgt die Verschlüsselung zertifikatabhängig oder nicht? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 22. März 2012 Teilen Geschrieben 22. März 2012 Moin nochmal, okay fassen wir zusammen: Https ist immer verschlüsselt, egal ob entsprechende Zerts installiert sind oder nicht. Die Verschlüsselung mit SSL ist also unabhängig von den Zertifikate, Sie dienen nur der gegenseitigen Identifizierung. Richtig. Das Zertifikat erlaubt, die Gegenseite eindeutig zu identifizieren. Drehen wir das Rädchen etwas weiter: Exchange->ActiveSync. Ein Iphone schert sich einen feuchten, ob es ein Root CA installiert hat oder nicht. Ein Windows Phone/Mobile dagegen muss das entsprechende Root CA Zert installiert haben, sonst ist eine Verbindung mit activesync nicht möglich. Die Verschlüsselung und Sicherheit der Datenkommunikation ist jedoch sowohl auf dem Iphone als auch auf dem Windows Endgerät vollkommen gleichwertig? Keine Ahnung, ich arbeite nicht mit ActiveSync. Letzter Punkt: Gehen wir weg von Https/SSL und kommen zu X.509 Zerts hinsichtlich z. B. VPN. Hier erfolgt die Verschlüsselung zertifikatabhängig oder nicht? Du hast es doch vorhin erkannt: Zertifikate sind zur Authentifizierung gedacht. Die Verschlüsselung ist davon unabhängig. Das gilt auch für SSL/IPSec-VPNs. Das Zertifikat verifiziert die Gegenstelle, die Verschlüsselung ist dann abhängig von Hard/Software (unterstützte Cipher, Konfiguration, etc) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 23. März 2012 Autor Teilen Geschrieben 23. März 2012 Sorry, da geh ich nicht mit dir konform. Nach meinen Informationen: Bei X.509 VPN wird zur Verschlüsselung ein Hauptschlüssel erzeugt, der sich aus den Informationen des Public Keys der Root CA und des privaten Schlüssels des privaten Zertifikats zusammensetzt. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SilentDemise Geschrieben 23. März 2012 Teilen Geschrieben 23. März 2012 Und was hat das eine nun mit dem anderen zu tun? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
afo Geschrieben 23. März 2012 Teilen Geschrieben 23. März 2012 Lesen, nachmachen, verstehen: Moserware: The First Few Milliseconds of an HTTPS Connection Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 23. März 2012 Autor Teilen Geschrieben 23. März 2012 Und was hat das eine nun mit dem anderen zu tun? Einfach nochmal von oben komplett lesen! @afo Der sieht aufschlussreich aus, für die Abarbeitung brauch ich aber eine Weile! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SilentDemise Geschrieben 23. März 2012 Teilen Geschrieben 23. März 2012 es hat schlicht einfach nichts miteinander zu tun. Google mal nach CSR Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 23. März 2012 Autor Teilen Geschrieben 23. März 2012 Soooo....nach afos Link und etlichem googlen hat es bei mir geklingelt . Leider durchschaute niemand mein eigentliches Verständnisproblem, macht aber nichts. @SilentDemise Jetzt erschließt sich mir dein Kommentar. @Rest Ich dachte die Verschlüsselung wird durch eine Kombination aus dem installierten Root CA Zert auf dem Client sowie aus Serverzertifikat erzeugt. Das das installierte Root CA Zert dafür nicht notwendig ist, war mir nicht bewusst. Insbesondere die seltener verwendeten Client Zertifikate ließen mich annehmen, eine Verschlüsselung entstehe desweiteren durch Client Zert. und dem für den den Server ausgestellten Zert. Hintergrund meiner Fragen ist im Übrigen die Zugriffskontrolle auf offene/genattete Https Ports: Wie handlet ihr das? Beschwert sich niemand bei den Administratoren, das jeder X-beliebige Surfer, womöglich sogar durch einen Tippfehler im Browser, auf irgendwelchen Firmen OWA Seiten landen kann, und damit das Frontend einer möglichen Attacke ausgeliefert ist. Implementiert Ihr bspw. Reverse Proxys? Was haltet ihr davon, solche Webseiten zusätzlich mit CLientzertifikaten abzusichern, dass jeder CLient ohne ein solches erst gar keinen Zugriff auf die Webseite bekommt? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
axxis Geschrieben 24. März 2012 Teilen Geschrieben 24. März 2012 Dafür ist OWA ja gedacht Es würde meiner Meinung nach keinen Vorteil bringen, wenn man das Frontend erst via VPN-Tunnel erreichen kann. Abgefangen wird das bei uns mit zeitnahen Updates und einer Web Application Firewall (Reverse Proxy). Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Guybrush Threepwood Geschrieben 29. März 2012 Teilen Geschrieben 29. März 2012 Ein Iphone schert sich einen feuchten, ob es ein Root CA installiert hat oder nicht. Ein Windows Phone/Mobile dagegen muss das entsprechende Root CA Zert installiert haben, sonst ist eine Verbindung mit activesync nicht möglich. Die Verschlüsselung und Sicherheit der Datenkommunikation ist jedoch sowohl auf dem Iphone als auch auf dem Windows Endgerät vollkommen gleichwertig? Wenn das so stimmt wie du es schreibst dann nein ist es nicht. Wie du ja schon gemerkt hast dient das Zertifikat dazu zu beweisen das der Server wirklich der ist der er vorgibt zu sein. Das heißt wenn du jetzt zum Beispiel auf deine Homebanking Seite gehst hat diese ein Zertifikat das für diesen Server ausgestellt wurde. Dieses Zertifikat ist von einer Zertifizierungsstelle, welche in den meisten System als vertrauenswürde Stammzertifizierungsstelle eingetragen ist, ausgestellt worden so das du dir (ziemlich) sicher sein kannst das du wirklich mit dem richtigen Server redest. Ohne dieses Zertifikat könnte sich nämlich mit recht einfachen Mitteln ein anderer Server als der Bankserver ausgeben und deine Daten abgreifen und irgendwas damit machen. Das heißt dann auch weitergedacht wenn du auf deine Homebankingseite gehst und da kommt irgendein Zertifikatsfehler das da irgendwas nicht stimmt (siehe zum Beispiel Mann-in-the-Middle Attacke). Wenn es auf dem IPhone jetzt wirklich so wäre das es sich nicht darum kümmert ob ein Zertifikat von einer vertrauenswürdigen Stelle kommt oder nicht könnte man diesen ganzen Sicherheitsmechanismus komplett vergessen. Das würde bedeuten jeder IPhone Benutzer wäre sehr leicht angreifbar und das kann ich mir nicht so wirklich vorstellen. Leider ist aber den meisten Leuten gar nicht bewusst was es mit diesen technischen Mechanismen auf sich hat wodurch dann in den meisten Fällen bei so einem Zertifikatsfehler einfach auf ignorieren und "ja ich weiß was ich tue!!!" geklickt wird obwohl man es (verständlicherweise) eben nicht weiß und man sich so einfach einem Angriff aussetzt. Genau das selbe ist mit der schönen Meldung auf einer https Seite das da auch nicht vertrauenswürdige/zertifizierte (oder was auch immer für) Inhalte existieren die nicht mitgeladen wurden, welche man aber einfach per Klick nachladen kann. Das dadurch einfach Javascript Code nachgeladen werden kann der dann einfach die ansonsten verschlüsselt übertragenen Daten ausspioniert wissen wahrscheinlich auch die wenigsten. Meistens wird dadurch ja die Seite nicht richtig dargestellt also klickt man drauf damit es schön aussieht... Was ich mit dem ganzen geleiere sagen will ist das korrekte Zertifikate sehr wichtig sind und wenn man da auf Fehler- oder Warnmeldungen trifft sollte man sich aus eigenem Interesse genauer damit auseinandersetzten was das bedeutet und was da passieren kann. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 29. März 2012 Autor Teilen Geschrieben 29. März 2012 Wenn das so stimmt wie du es schreibst dann nein ist es nicht. Wie du ja schon gemerkt hast dient das Zertifikat dazu zu beweisen das der Server wirklich der ist der er vorgibt zu sein. Das heißt wenn du jetzt zum Beispiel auf deine Homebanking Seite gehst hat diese ein Zertifikat das für diesen Server ausgestellt wurde. Dieses Zertifikat ist von einer Zertifizierungsstelle, welche in den meisten System als vertrauenswürde Stammzertifizierungsstelle eingetragen ist, ausgestellt worden so das du dir (ziemlich) sicher sein kannst das du wirklich mit dem richtigen Server redest. Ohne dieses Zertifikat könnte sich nämlich mit recht einfachen Mitteln ein anderer Server als der Bankserver ausgeben und deine Daten abgreifen und irgendwas damit machen. Das heißt dann auch weitergedacht wenn du auf deine Homebankingseite gehst und da kommt irgendein Zertifikatsfehler das da irgendwas nicht stimmt (siehe zum Beispiel Mann-in-the-Middle Attacke). Wenn es auf dem IPhone jetzt wirklich so wäre das es sich nicht darum kümmert ob ein Zertifikat von einer vertrauenswürdigen Stelle kommt oder nicht könnte man diesen ganzen Sicherheitsmechanismus komplett vergessen. Das würde bedeuten jeder IPhone Benutzer wäre sehr leicht angreifbar und das kann ich mir nicht so wirklich vorstellen. Leider ist aber den meisten Leuten gar nicht bewusst was es mit diesen technischen Mechanismen auf sich hat wodurch dann in den meisten Fällen bei so einem Zertifikatsfehler einfach auf ignorieren und "ja ich weiß was ich tue!!!" geklickt wird obwohl man es (verständlicherweise) eben nicht weiß und man sich so einfach einem Angriff aussetzt. Genau das selbe ist mit der schönen Meldung auf einer https Seite das da auch nicht vertrauenswürdige/zertifizierte (oder was auch immer für) Inhalte existieren die nicht mitgeladen wurden, welche man aber einfach per Klick nachladen kann. Das dadurch einfach Javascript Code nachgeladen werden kann der dann einfach die ansonsten verschlüsselt übertragenen Daten ausspioniert wissen wahrscheinlich auch die wenigsten. Meistens wird dadurch ja die Seite nicht richtig dargestellt also klickt man drauf damit es schön aussieht... Was ich mit dem ganzen geleiere sagen will ist das korrekte Zertifikate sehr wichtig sind und wenn man da auf Fehler- oder Warnmeldungen trifft sollte man sich aus eigenem Interesse genauer damit auseinandersetzten was das bedeutet und was da passieren kann. Mahlzeit, danke für deinen Beitrag. Prinzipiell war mir das alles bereits bewusst, ich dachte lediglich dass die Verschlüsselung mit dem installierten Root Cert zusammenhängt. Natürlich hast du bzgl des Umgangs mit Webseiten insbesondere unaufmerksamen Benutzerverhalten Recht. Finde es nur irgendwie interessant, wieviel Mehrarbeit bei ActiveSync & Co. herauskommt, die NICHT mit der Verschlüsselung zusammenhängt, sondern lediglich für die "Sicherheit" des Clients getan werden muss. Irgendwo aber natürlich auch nachvollziehbar. Normalerweise steht bei mir der Schutz der Server im Vordergrund, womit das Beispiel umkehrbar ist: Wie kann ich erreichen, dass meine durch offene Ports angreifbaren Server vor unauthorisierten Zugriffen geschützt werden...Wobei wir wieder bei den Clientzertifikaten wären die vorausgesetzt sind, dass jemand mit dem Server sprechen darf.... Wundert mich etwas, dass niemand Erfahrungen teilen kann, bei denen Firmen die die folgende Anforderung stellen: DIe Serverports müssen für ActiveSync/Webserver offen sein, aber niemand Fremdes soll von extern einfach so auf meiner Firmen-OWA-Login-Seite (tolles Wort) kommen. Naja, meine Fragen sind aber beantwortet, danke an den Rest, hier können wir closen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SilentDemise Geschrieben 30. März 2012 Teilen Geschrieben 30. März 2012 Wundert mich etwas, dass niemand Erfahrungen teilen kann, bei denen Firmen die die folgende Anforderung stellen: DIe Serverports müssen für ActiveSync/Webserver offen sein, aber niemand Fremdes soll von extern einfach so auf meiner Firmen-OWA-Login-Seite (tolles Wort) kommen. Naja, meine Fragen sind aber beantwortet, danke an den Rest, hier können wir closen. diese anforderung bildet man über VPN ab. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 3. Mai 2012 Autor Teilen Geschrieben 3. Mai 2012 Ich muss das nochmal aufgreifen, VPN macht hier keinen Sinn, es geht um offene HTTPS Ports... Sobald der Port offen ist, ist er offen, da macht VPN keinen Unterschied. Sollen Dienste, die HTTPS benötigen, von außen nicht erreichbar sein, dann kommt VPN ins Spiel. Soll ActiveSync genutzt werden, muss 443 nach außen offen sein, damit ist automatisch OWA etc. offen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pantsoff Geschrieben 3. Mai 2012 Autor Teilen Geschrieben 3. Mai 2012 Oder meinst du nach VPN Einwahl auf die internen HTTPS Adressen verbinden? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.