casibu
Anmeldungsdatum: 20. Oktober 2013
Beiträge: 201
|
Hallo,
laut dem Artikel http://www.heise.de/security/meldung/OpenSSL-mit-kaputter-Hintertuer-2072370.html
gab es schon länger eine Hintertür in OpenSSL, die durch ein Zufallszahlengenerator verursacht werden könnte.
OpenSSL wird angewandt um SSL, TLS, und OpenVPN, in Programmen zu implementieren.
Ich finde man sollte hier genau Aufklären, inwieweit WELCHE Progamme davon betroffen sind. Auch wenn die Hintertür
der NSA in OpenSSL nicht direkt angewandt wird, so wie es im Artikel steht, wäre es mir lieber eine Alternative zu
nehmen, bis das Eindeutig geklärt ist. Wie sieht es mit folgenden Tools aus: 1. Thunderbird (SSL,TLS) 2. Firefox für HTTPS Seiten(SSL) 3. OpenVPN
|
nbkr
Anmeldungsdatum: 29. Oktober 2007
Beiträge: 1936
Wohnort: Aschaffenburg
|
OpenSSL hängt in so ziemlich jeder Open Source Software drin die SSL unterstützt. Einzige Alternative ist GnuTLS, aber das kann man nicht einfach austauschen. Die einzelnen Pakete müssen dafür mindestens neu kompiliert und vermutlich auch der Code angepasst werden. Die NSA kann die Hintertür in OpenSSL - genauer in dem entsprechenden Zufallsgenerator nicht nutzen weil der Generator einen Bug hatte und entsprechend nie funktioniert hat.
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Bitte den Artikel richtig lesen. Die Hintertür ist der Algorithmus selbst, weil dieser einfach nur eine begrenzte Menge an Zufallszahlen begrenzt ist. Desweiteren wird dieser Algorithmus nie genutzt, sonst wäre der Bug schon früher aufgefallen. Meine Vermutung üerhaupt, der Algorithmus wurde absichtlich funktionsunfähig gemacht, da er eben nicht als sicher angesehen wurde.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
nbkr schrieb: OpenSSL hängt in so ziemlich jeder Open Source Software drin die SSL unterstützt.
Es gibt z. B. auch noch: https://polarssl.org/ Wird z. B. u. a. auch mit Freetz benutzt: http://svn.freetz.org/trunk/make/libs/polarssl/Config.in nbkr schrieb: Einzige Alternative ist GnuTLS, aber das kann man nicht einfach austauschen. Die einzelnen Pakete müssen dafür mindestens neu kompiliert und vermutlich auch der Code angepasst werden.
Ja, aber "guter" Code ermöglicht beides (alternativ). Z. B. bei lftp:
:~$ ldd $(which lftps) | grep -i ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0x00c02000)
:~$ ldd $(which lftp) | grep -i tls
libgnutls.so.26 => /usr/lib/i386-linux-gnu/libgnutls.so.26 (0x0077a000)
|
nbkr
Anmeldungsdatum: 29. Oktober 2007
Beiträge: 1936
Wohnort: Aschaffenburg
|
nbkr schrieb: Einzige Alternative ist GnuTLS, aber das kann man nicht einfach austauschen. Die einzelnen Pakete müssen dafür mindestens neu kompiliert und vermutlich auch der Code angepasst werden.
Ja, aber "guter" Code ermöglicht beides (alternativ). Z. B. bei lftp:
Ja, wenn die Entwickler daran gedacht das austauschbar zu machen, wunderbar. Aber nur weil die Menschen bei lftp das gemacht haben, heißt das ja nicht dass es immer und überall so einfach geht. Persönlich hab es bei Openldap erlebt. Ich glaube auf Debian war das damals schon gegen GnuTLS gelinkt, bei der Ubuntuvariante (gleiche OpenLDAP Version) noch gegen OpenSSL. Ergebniss war dass die beiden LDAP Server nicht verschlüsselt miteinander reden konnten weil die SSL/TLS Implementierung sich unterschied. Aber wie TheDarkRose schon gesagt hat. Das ganze ist eigentlich müssig, die gefundene Lücke ist keine. Es ist nicht sinnvoll OpenSSL wegen dem was im Heise-Artikel beschrieben ist zu ersetzen.
|
casibu
(Themenstarter)
Anmeldungsdatum: 20. Oktober 2013
Beiträge: 201
|
So wie es aussieht brauch man sich da alos keine Sorgen zu machen, o.k. da wir nun schon bei der Thematik SSL sind... Es gibt ja bekannterweise erfolgreiche Angriffe gegen SSL. D.h. innerhalb eines LANs können per MIM-Angriffe die Zertifikate unbemerkt
ausgetauscht werden, so das Anmeldedaten z.b. eines Mail Accounts welches per HTTPS und Browser auferufen wurde, ersnifft werden. Gibt es dazu spezielle Maßnahmen, die man ergreifen kann, das sowas nicht funktioieren kann. Ich denke daran, ob man z.b. die
Zertifikate im Browser irgendwie "härten" könnte, so dass der Browser alle anderen Zertifikate ablehnt, nur mal so als Idee.
|
nbkr
Anmeldungsdatum: 29. Oktober 2007
Beiträge: 1936
Wohnort: Aschaffenburg
|
Nein, Zertifikate lassen sich nicht unbemerkt austauschen. In jedem Zertifikat steht drin von wem und für wenn es ausgestellt wurde. Wenn das "für wenn" nicht mit der URL übereinstimmt, schlägt der Browser Alarm. Ebenso wenn das "von wem" keiner der Zertifizierungsstellen entspricht welche der Browser vertraut. Problematisch ist hier eher die Frage: Wie sollte der Browser einer Zertifizierungsstelle vertrauen? Überlicherweise ist das mit einer Geldzahlung oder sonstigen Prüfverfahren der Browserhersteller verbunden. Aber das sagt ja noch lange nicht, dass du der gleichen Meinung bist wie der Browserhersteller. Hinzu kommt die Faulheit der Anwender. Prinzipiell müsste man bei jeden Aufruf das Zertifikat händisch kontrollieren um sicher zu stellen dass sich nicht die Zertifizierungsstelle geändert hat. Das macht aber keiner. Die meisten sind ja noch nicht mal besorgt wenn der Browser eine Fehlermeldung wirft, sondern klicken die einfach zu nur weg.
|
casibu
(Themenstarter)
Anmeldungsdatum: 20. Oktober 2013
Beiträge: 201
|
Nein, Zertifikate lassen sich nicht unbemerkt austauschen
hmm, also ich hatte das mal in einem Selbstversuch getestet, und das ging OHNE Browserwarnung. Muss dazu aber sagen, dass
das schon paar Jahre her ist. damit konnte ich dann mein, Web.de, und glaub auch gmail PW auslesen. Ob das aktuell noch so funtkioniert
weiss ich nicht. Aber dein Hinweis, das man es händisch kontrolliert finde ich gut, vorausgesetzt es gibt da noch keine rafinierteren Angriffe.
|
lotharster
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 495
|
nbkr schrieb: Nein, Zertifikate lassen sich nicht unbemerkt austauschen. In jedem Zertifikat steht drin von wem und für wenn es ausgestellt wurde. Wenn das "für wenn" nicht mit der URL übereinstimmt, schlägt der Browser Alarm. Ebenso wenn das "von wem" keiner der Zertifizierungsstellen entspricht welche der Browser vertraut.
Naja, das ist nicht ganz richtig. Wenn ein Zertifikat einer Website durch ein anderes gültiges (von einer Zertifizierungsstelle signertes) Zertifikat ersetzt wird, dann wird das vom Browser akzeptiert. Auf diese Weise wechseln Webseiten ja z. B. auch ihre eigenen Zertifikate aus, wenn diese abgelaufen sind. Das kann auch ein Angreifer machen, wenn er es schafft, eine Zertifizierungsstelle dazu zu bringen, sein Zertifikat zu signieren. Und bei mehreren hundert Zertifizierungsstellen, die von den gängigen Browsern akzeptiert werden, findet sich da für einen Angreifer immer eine Möglichkeit, wenn er ein wenig Geld oder Aufwand inverstiert. Ganz zu schweigen von Polizei/Geheimdiensten, die sich solche Zertifikate ganz einfach ausstellen lassen können. Sich davor zu schützen ist nicht ganz einfach. Eine Möglichkeit ist Certificate Pinning (www.owasp.org/index.php/Certificate_and_Public_Key_Pinning) Firmen betreiben oft eine eigene Zertifizierungsstelle (die Firmenrechner werden dann so konfiguriert, dass sie dieser internen Zertifizierungsstelle ebenfalls vertrauen). Auf diese Weise kann die Firewall dann einen MitM-Angriff auf sämtliche Verbindungen fahrenalle externen SSL-Verbindungen abhören und kontrollieren.
|
casibu
(Themenstarter)
Anmeldungsdatum: 20. Oktober 2013
Beiträge: 201
|
Firmen betreiben oft eine eigene Zertifizierungsstelle (die Firmenrechner werden dann so konfiguriert, dass sie dieser internen Zertifizierungsstelle ebenfalls vertrauen). Auf diese Weise kann die Firewall dann einen MitM-Angriff auf sämtliche Verbindungen fahrenalle externen SSL-Verbindungen abhören und kontrollieren.
Den letzten Satz habe ich jetzt nciht ganz verstanden. Du meinst die Firewall kann dann einen MIM Angriff ausführen?
Sich davor zu schützen ist nicht ganz einfach. Eine Möglichkeit ist Certificate Pinning (www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)
Aber da müsste dann auch der Server mitspielen, die Frage ist was ich als Client alleine machen kann? das händische Prüfen bringt dann wohl auch nichts, oder?
|
lotharster
Anmeldungsdatum: 7. Oktober 2006
Beiträge: 495
|
casibu schrieb: Firmen betreiben oft eine eigene Zertifizierungsstelle (die Firmenrechner werden dann so konfiguriert, dass sie dieser internen Zertifizierungsstelle ebenfalls vertrauen). Auf diese Weise kann die Firewall dann einen MitM-Angriff auf sämtliche Verbindungen fahren und alle externen SSL-Verbindungen abhören und kontrollieren.
Den letzten Satz habe ich jetzt nciht ganz verstanden. Du meinst die Firewall kann dann einen MIM Angriff ausführen?
Ja, genau. Das ist die einzige Möglichkeit, SSL-verschlüsselten Traffic zu scannen.
Sich davor zu schützen ist nicht ganz einfach. Eine Möglichkeit ist Certificate Pinning (www.owasp.org/index.php/Certificate_and_Public_Key_Pinning)
Aber da müsste dann auch der Server mitspielen, die Frage ist was ich als Client alleine machen kann? das händische Prüfen bringt dann wohl auch nichts, oder?
Das Einzige Problem dabei ist, wenn der Serverbetreiber sein Zertifikat austauscht. Solange das nicht passiert, kannst Du ein Zertifikat, dass Du einmal aus vertrauenswürdiger Quelle erhalten hast, weiterverwenden, und sicher sein, dass kein MitM dahintersteckt. Ein Beispiel in der Praxis: Du reist nach Diktatoristan. Vor der Reise lädst Du Dir im sicheren Heimatland das Zertifikat deines Webmail-Anbieters herunter und "pinnst" es. Wenn die Seite später dann in Diktatoristan ein neues Zertifikat präsentiert, hört wahrscheinlich der Geheimdienst mit (oder dein Webmail-Dienst hat selbst das Zertifikat geändert), und Du solltest entsprechend vorsichtig sein.
|
casibu
(Themenstarter)
Anmeldungsdatum: 20. Oktober 2013
Beiträge: 201
|
ich wollte nochmal zum "händischen" Überprüfen kommen. Die Kreissparkasse bietet auf Ihrer Seite,
und auch in ausgedruckter Form (per Post) den Fingerprint zu Überprüfung an.
Wen ich nun per https auf die Seite gehe, und mir den Fingerprint anschaue, und dieser mit dem
übereinstimmt, den ich Zuhause habe, dann kann ich doch sicher sein, das ein MIM Angriff nicht stattgefunden
hat, auch nicht durch Geheindienste. Selbst wenn Ein Dienst für z.b. Verisign Zertifikate ausstellen darf, dann
müsste das neue Zertifikat einen anderen Fingerprint haben. Wenn das so stimmt, dann reicht doch diese Methode der
Überprüfung vollkommen aus, oder nicht?
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Jap, der Fingerprint ist einmalig.
|