1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › TLS: Netgear verteilt private…

Es war schon immer ein Fehler ...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Es war schon immer ein Fehler ...

    Autor: phade 21.01.20 - 14:42

    .. Verschlüsselung mit einer Verifizierung zu koppeln. Daran krankt m.M.n. das jetzige CA-Browser-System seit seiner Erfindung.

    Verschlüsselung MUSS nichts mit einem von einer Drittinstanz signiertem Zertifikat zu tun haben.
    Client und Server können auch beim Verbindungsaufbau live ein Schlüsselpaar generieren, austauschen und damit verschlüsseln.

    Signierung ist ein ganz anderes Thema.

    Was interessiert mich bei einem Router ein verifizierbarer Aussteller ? Nichts, ich habe das Gerät gekauft, da steht NetGear drauf. Aber dessen Webinterface würde ich schon gerne verschlüsselt nutzen. Dafür benötige ich aber kein gespeichertes Zertifikat.

  2. Re: Es war schon immer ein Fehler ...

    Autor: Eheran 21.01.20 - 16:39

    >Client und Server können auch beim Verbindungsaufbau live ein Schlüsselpaar generieren, austauschen und damit verschlüsseln.
    Wie kann man damit man-in-the-middle Angriffe verhindern? Ohne PSK?

  3. Re: Es war schon immer ein Fehler ...

    Autor: phade 21.01.20 - 17:23

    Verhindern kannst du die auch nicht mit dem jetzigen System, siehe Pishing-Sites mit gültigem Zertifikat.

    LetsEncrypt ist z.B. nur Website-Validated, da kannst du den Verifizierungsteil gleich ganz vergessen. Bei DV-Zertifikaten gibt es schon ein bisschen mehr Verifizierung, aber auch das könnte alles gefälscht sein. Die DV-Verifizierung kann auch DNS regeln (leider ist aktuell nicht im Client erkennbar, ob es per eMail oder DNS verifiziert wurde), sofern man dem DNS vertrauen kann, was bei einem MITM auch nicht mehr gegeben ist. DNS kann man mit DNSsec noch mehr vertrauen, aber ...

    Um den MITM bei DV-Zertifikaten noch schwieriger zu machen, hat man dann noch CAA erfunden, weil man wusste, dass die DV-Zertifizierung Mumpitz ist. Wenn dein MITM beim DNS schon ansetzt, ist das auch wieder nur Makulatur.

    Irgendjemandem muss man bei der Verifizierung immer vertrauen und an der Stelle kann ein MITM immer ansetzen.

    Verifizierung sollte also anders geregelt werden (habe keine Idee, wie), hat also in dem Verschlüsselungsteil nichts zu suchen.

  4. Re: Es war schon immer ein Fehler ...

    Autor: Eheran 22.01.20 - 10:44

    >Verhindern kannst du die auch nicht mit dem jetzigen System
    Wozu hat man dann eine SIM-Karte? Die kann doch genau das verhindern, oder nicht? Es gibt in dieser schon einen PSK bzw. eine irgendwie geartete Abwandlung davon durch bereits ausgetauschtes Wissen?

    Das ist eine ernsthafte Frage. Ich dachte immer, dass man genau deswegen eine SIM hat. Und dass das kopieren von SIM auch nicht ohne weiteres geht, sondern nur vom Provider her. Sonst kann sich ja jeder beliebig anmelden und sonstwas tun, wenn er nur mal die Anmeldung von wem anders loggt?

  5. Re: Es war schon immer ein Fehler ...

    Autor: phade 22.01.20 - 11:33

    Ich verstehe gerade nicht, was eine SIM-Karte mit einem Web- oder S/MIME-Zertifikat oder mit der Speicherung eines Zertifikats im Router oder einer Verifizierung eines https-Zertifikats zu tun hat ...



    1 mal bearbeitet, zuletzt am 22.01.20 11:34 durch phade.

  6. Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 14:32

    phade schrieb:
    --------------------------------------------------------------------------------
    > .. Verschlüsselung mit einer Verifizierung zu koppeln. Daran krankt m.M.n.
    > das jetzige CA-Browser-System seit seiner Erfindung.
    >
    > Verschlüsselung MUSS nichts mit einem von einer Drittinstanz signiertem
    > Zertifikat zu tun haben.
    > Client und Server können auch beim Verbindungsaufbau live ein Schlüsselpaar
    > generieren, austauschen und damit verschlüsseln.
    >
    > Signierung ist ein ganz anderes Thema.
    >
    > Was interessiert mich bei einem Router ein verifizierbarer Aussteller ?
    > Nichts, ich habe das Gerät gekauft, da steht NetGear drauf. Aber dessen
    > Webinterface würde ich schon gerne verschlüsselt nutzen. Dafür benötige ich
    > aber kein gespeichertes Zertifikat.

    Das ist es ja: es geht darum, zu verifizieren, dass routerlogin.net auf deinen Router zeigt, und nicht woanders hin. Ob das nun verschlüsselt abläuft oder nicht ist eigentlich eher zweitrangig.

  7. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 15:16

    Exakt.

    Hätte man die Verifizierung schon immer von der Verschlüsselung gelöst, wäre NetGear hier gar nichts erst auf die Idee gekommen, die Verifizierung mit einem Zertifikat zu lösen.

    In dem Fall kann man die Verifizierung ja z.B. über die MAC-Addresse lösen, steht auf dem Gerät und/oder der Verpackung, ein Dialog kann die vor der Konfiguration abfragen.

    Die spätere Verschlüsselung halte ich für notwendig, Passworte zum Routerinterface sollte man auch im privaten WLAN nicht unverschlüsselt übertragen. Würden Client und Server das jedoch auch ohne offizielles Zertifikat aushandeln können, braucht man auch keins speichern.

    Da die meisten SSL-Zertifikat ja keine EV-, sondern nur DV-Zertifikate sind, die auch häufig per DNS verifiziert werden, hätte man die ganze Struktur auch allein über DNS regeln können. Der Server erzeugt mit einer privaten oder gar keinen CA ein Zertifikat, dessen public-key wandert in den DNS-Server und den prüft der Client. Den ganzen CA oder LetsEncrypt-Überbau braucht man dann schonmal gar nicht. Und ist kein key vorhanden, ist es ja trotzdem verschlüsselt. Der Browser braucht nicht einmal etwas negatives anzeigen.



    4 mal bearbeitet, zuletzt am 22.01.20 15:29 durch phade.

  8. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 15:28

    phade schrieb:
    --------------------------------------------------------------------------------
    > Exakt.
    >
    > Hätte man die Verifizierung schon immer von der Verschlüsselung gelöst,
    > wäre NetGear hier gar nichts erst auf die Idee gekommen, die Verifizierung
    > mit einem Zertifikat zu lösen.

    Den Gedankengang verstehe ich nicht. Die Verschlüsselung dürfte doch egal sein, trotzdem braucht NetGear die Zertifizierung/Signierung. Wie willst du sonst sicherstellen, dass routerlogin.net nicht einfach auf <böse-IP> zeigt?

    > In dem Fall kann man die Verifizierung ja z.B. über die MAC-Addresse lösen,
    > steh auf dem Gerät und/oder der Verpackung, ein Dialog kann die vor der
    > Konfiguration abfragen.

    Und die Phishing-Webseite sagt dann: jo, passt! Und zwar egal, welche MAC du eingibst :) Also WENN, dann müsste der Dialog eine MAC-Adresse anzeigen, und der Kunde müsste dann selbst gucken, ob das die Gleiche wie auf dem Gehäuse ist. Und er darf dann nur weitermachen, wenn beide übereinstimmen. Und das muss er bei jedem Aufruf machen. Und wenn <böse-IP> diese Dialog-Seite einfach weglässt, dann muss der Kunde selbst merken, dass diese fehlt :) Und letzteres wird er nicht tun, und deswegen funktioniert das so nicht.

    Und Verschlüsselung ohne Verifizierung macht eigentlich wenig Sinn: wenn du nicht sicher bist, dass die Seite bzw. der Dienst, den du verschlüsselt aufrufen möchtest, auch wirklich der ist, den du erreichen möchtest, dann bringt dir auch die Verschlüsselung nix mehr. Es mag zwar in vielen Fällen trotzdem sinnvoll sein, aber das Risiko der falschen Sicherheit ist zu groß!

  9. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 15:36

    Es braucht bloss für die Verifizierung keine CA, siehe oben.
    Auch bei SSH hast du keine Verifizierung über eine CA, da stört sich niemand dran.

    Und: was braucht es eine Verifizierung, wenn die Konfiguration nur über ein lokales TP-Kabel funktioniert ? Pishing ist dann ausgeschlossen. Ohne das CA-System brächte es dann widerum kein Zertifikat im Router, Router und Client würden einfach Schlüssel aushandeln.

    Bei der Erst-Konfiguration über TP-Kabel kann sich der Router die MAC vom Client merken und zukünftig nur von diesem ein zukünftiges Login akzeptieren.



    3 mal bearbeitet, zuletzt am 22.01.20 15:39 durch phade.

  10. Re: Es war schon immer ein Fehler ...

    Autor: Eheran 22.01.20 - 15:57

    Sorry, ich war auf einer anderen Netzwerkebene.

  11. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: Spaghetticode 22.01.20 - 16:09

    phade schrieb:
    --------------------------------------------------------------------------------
    > Bei der Erst-Konfiguration über TP-Kabel kann sich der Router die MAC vom
    > Client merken und zukünftig nur von diesem ein zukünftiges Login
    > akzeptieren.

    Das ist aber nicht sinnvoll. Der ehrliche Nutzer wird ausgesperrt, wenn er keinen Zugriff auf den ursprünglichen Rechner mehr hat. Und die Böslinge fälschen einfach die MAC-Adresse.

  12. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 16:28

    phade schrieb:
    --------------------------------------------------------------------------------
    > Es braucht bloss für die Verifizierung keine CA, siehe oben.
    > Auch bei SSH hast du keine Verifizierung über eine CA, da stört sich
    > niemand dran.
    >
    > Und: was braucht es eine Verifizierung, wenn die Konfiguration nur über ein
    > lokales TP-Kabel funktioniert ? Pishing ist dann ausgeschlossen. Ohne das
    > CA-System brächte es dann widerum kein Zertifikat im Router, Router und
    > Client würden einfach Schlüssel aushandeln.
    >
    > Bei der Erst-Konfiguration über TP-Kabel kann sich der Router die MAC vom
    > Client merken und zukünftig nur von diesem ein zukünftiges Login
    > akzeptieren.

    Der Router mag das ja alles schön richtig machen. Aber woher weiß der Client, dass er sich auch tatsächlich zum Router verbindet? Das ist doch der Knackpunkt.

  13. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 16:38

    Wenn der Nutzer seinen Rechner wechselt, kann er ja wieder das TP-Kabel nehmen.

    Woher soll der MITM denn von Ferne die richtige MAC-Adresse kennen ?
    Dazu müsste er schon im Netz sein, und dann ist doch sowieso schon alles zu spät.

    Es geht doch darum, dass der Angreifer per MITM von ausserhalb deines WLANs die Pishing-Site mit dem richtigen Zertifikat überhelfen könnte und das geht per MAC-Verifizierung von Ferne eben nicht (ausser er schleust dich nicht nur auf eine Pishing-Seite, sondern hilft dir gleich noch einen Trojaner ein).

    Jetzt wird das SSL-Zertifikat wohl zurückgezogen und somit der eigene Router im Browser als unsicher angezeigt. Hätte man anders regeln müssen.



    2 mal bearbeitet, zuletzt am 22.01.20 16:42 durch phade.

  14. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 16:47

    phade schrieb:
    --------------------------------------------------------------------------------
    > Wenn der Nutzer seinen Rechner wechselt, kann er ja wieder das TP-Kabel
    > nehmen.
    >
    > Woher soll der MITM denn von Ferne die richtige MAC-Adresse kennen ?
    > Dazu müsste er schon im Netz sein, und dann ist doch sowieso schon alles zu
    > spät.

    Braucht der MITM (oder die WITM ;) ) doch auch gar nicht.

    > Es geht doch darum, dass der Angreifer per MITM von ausserhalb deines WLANs
    > die Pishing-Site mit dem richtigen Zertifikat überhelfen könnte und das
    > geht per MAC-Verifizierung von Ferne eben nicht (ausser er schleust dich
    > nicht nur auf eine Pishing-Seite, sondern hilft dir gleich noch einen
    > Trojaner ein).

    Aber wieso sollte die Phishing-Seite überhaupt erst nach der MAC fragen?

    > Jetzt wird das SSL-Zertifikat wohl zurückgezogen und somit der eigene
    > Router im Browser als unsicher angezeigt. Hätte man anders regeln müssen.

    Nein, genau so muss das geregelt werden, wenn der Private-Key bekannt wird. Also ja, man hätte das anders regeln müssen: gar kein solches Zertifikat einbauen.

  15. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 16:48

    treysis schrieb:
    --------------------------------------------------------------------------------
    > Der Router mag das ja alles schön richtig machen. Aber woher weiß der
    > Client, dass er sich auch tatsächlich zum Router verbindet? Das ist doch
    > der Knackpunkt.

    Das braucht der Client doch nicht wissen, weil der Router connects von anderen MAC-Adressen gar nicht mehr zulässt. Kommst du mit der Falschen, sagt er: "Bitte nutzen Sie zur Verbindung mit dem Router den Rechner, mit dem Sie den Rechner zuerst konfiguriert werden oder nutzen Sie eine Verbindung mit dem TP-Kabel."

    Faktisch haben die Browser-Hersteller mit der Forcierung durch die "unsichere Webseite"-Symbole und die Verquickung von Verschlüsselung mit Verifizierung dazu geführt, dass Gerätehersteller den key der SSL-Zertifikate im Gerät speichern müssen. Würden die Browser auch Zertifikate von privaten CAs akzeptieren und eine Verifizierung z.B. über DNS (oder eben bei Routern über die MAC) regeln, brächte es das Zertifikat im Router doch gar nicht.

    Dann machen die Browser ein private/public-key-Verfahren zur Verschlüsselung, zeigen die verschlüsselten grün an. Ist es noch per DNS verifiziert, bekommst du im grünen Logo noch einen OK-Haken angezeigt. Ist es nur http, wird es rot.

    Dann verlieren die CAs ihr Business ...



    3 mal bearbeitet, zuletzt am 22.01.20 17:06 durch phade.

  16. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 16:53

    treysis schrieb:
    --------------------------------------------------------------------------------
    > Also ja, man hätte das anders regeln müssen: gar kein solches Zertifikat
    > einbauen.
    Geht ja nicht, wenn http-Verbindungen mittlerweile von jedem Browser als unsicher dargestellt werden. Das ist doch der Haken. Die Browser zwingen zu https und https funktioniert nur mit Zertifikat, weil Verschlüsselung und Verifizierung zusammen ins TLS gebaut wurden.

    Klar, man kann dem Kunden auch wieder ein Program auf CD liefern, das nur über USB läuft und ganz auf die http(s)-Schnittstelle verzichten ...

  17. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 16:56

    phade schrieb:
    --------------------------------------------------------------------------------
    > treysis schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Der Router mag das ja alles schön richtig machen. Aber woher weiß der
    > > Client, dass er sich auch tatsächlich zum Router verbindet? Das ist doch
    > > der Knackpunkt.
    >
    > Das braucht der Client doch nicht wissen, weil der Router connects von
    > anderen MAC-Adressen gar nicht mehr zulässt. Kommst du mit der Falschen,
    > sagt er: "Bitte nutzen Sie zur Verbindung mit dem Router den Rechner, mit
    > dem Sie den Rechner zuerst konfiguriert werden oder nutzen Sie eine
    > Verbindung mit dem TP-Kabel."

    Aber der Client verbindet sich ja gar nicht mit dem eigentlichen Router, weil routerlogin.net ganz woanders hinzeigt :)

  18. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 17:01

    Weil der MITM dir von Ferne andere Nameserver eingeholfen hat ?
    Wie soll denn das gehen ?

  19. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: phade 22.01.20 - 17:08

    Ich sehe gerade, das Firefox und Chrome gar nicht mehr "grün" werden. EV-Zertifikate sind ergo schon jetzt sinnlos (welcher Normaluser guckt sich denn das Zertifikat schon an).

    Das ist einfach nur noch lächerlich und Bedarf eines Neustarts.



    1 mal bearbeitet, zuletzt am 22.01.20 17:08 durch phade.

  20. Re: Aber es geht um Verifizierung, nicht Signierung

    Autor: treysis 22.01.20 - 17:11

    phade schrieb:
    --------------------------------------------------------------------------------
    > treysis schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Also ja, man hätte das anders regeln müssen: gar kein solches Zertifikat
    > > einbauen.
    > Geht ja nicht, wenn http-Verbindungen mittlerweile von jedem Browser als
    > unsicher dargestellt werden. Das ist doch der Haken. Die Browser zwingen zu
    > https und https funktioniert nur mit Zertifikat, weil Verschlüsselung und
    > Verifizierung zusammen ins TLS gebaut wurden.

    Wie gesagt, mein OpenWrt hat auch nur HTTP, und da kommt zwar eine Warnung beim Passwort-Feld, aber die ist eben nicht so prominent wie der Zertifikatsfehler, den man erstmal umgehen muss.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Basler AG, Ahrensburg
  2. SySS GmbH, Tübingen
  3. THD - Technische Hochschule Deggendorf, Pfarrkirchen
  4. Matoki GmbH, Weiterstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. RU7099 70 Zoll (178 cm) für 729,90€ (Vergleich 838€), RU7179 75 Zoll (189 cm) für 889...
  2. (Arthouse Cnma, RTL Crime, StarzPlay jeweils 3 Monate für 0,99€/Monat)
  3. 649,00€ (Vergleichspreise ab 718,99€)
  4. (aktuell u. a. MSI Optik MAG271CP Gaming-Monitor für 279,00€, Corsair Gaming Void Pro 7.1...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Huawei-Gründer Ren Zhengfei: Der Milliardär, der im Regen auf ein Taxi wartet
Huawei-Gründer Ren Zhengfei
Der Milliardär, der im Regen auf ein Taxi wartet

Huawei steht derzeit im Zentrum des Medieninteresses - und so wird auch mehr über den Gründer und Chef Ren Zhengfei bekannt, der sich bisher so gut wie möglich aus der Öffentlichkeit ferngehalten hatte.
Ein Porträt von Achim Sawall

  1. ORAN Open-Source-Mobilfunk ist nicht umweltfreundlich
  2. US-Handelsboykott Ausnahmeregelung für Geschäfte mit Huawei erneut verlängert
  3. "Eindeutiger Beweis" US-Regierung holt ihre "Smoking Gun" gegen Huawei heraus

Energiegewinnung: Zu wenig Magma-Nachschub für die Geothermie
Energiegewinnung
Zu wenig Magma-Nachschub für die Geothermie

Bei Diskussionen über Geothermie klingt es oft so, als könnten vulkanisch aktive Gegenden wie Island den Rest der Welt mit Energie versorgen. Aber ein Blick auf die Zahlen zeigt, dass dieser Eindruck täuscht.
Von Frank Wunderlich-Pfeiffer

  1. E-Truck Nikola Tre wird in Ulm gebaut
  2. Wasserstoff Thyssen-Krupp will Stahlproduktion klimaneutral machen
  3. Energiewende Sonnen vermietet Solaranlagen und Elektroautos

Galaxy Z Flip im Hands-on: Endlich klappt es bei Samsung
Galaxy Z Flip im Hands-on
Endlich klappt es bei Samsung

Beim zweiten Versuch hat Samsung aus seinen Fehlern gelernt: Das Smartphone Galaxy Z Flip mit faltbarem Display ist alltagstauglicher und stabiler als der Vorgänger. Motorolas Razr kann da nicht mithalten.
Ein Hands on von Tobias Költzsch

  1. Isocell Bright HM1 Samsung verwendet neuen 108-MP-Sensor im Galaxy S20 Ultra
  2. Smartphones Samsung schummelt bei Teleobjektiven des Galaxy S20 und S20+
  3. Galaxy Z Flip Samsung stellt faltbares Smartphone im Folder-Design vor

  1. SpaceX: Falcon 9 scheitert am Versuch der 50. Landung
    SpaceX
    Falcon 9 scheitert am Versuch der 50. Landung

    Das Jubiläum fiel buchstäblich ins Wasser. Nach dem Start von 60 weiteren Starlink-Satelliten tat die erste Raketenstufe, was bei anderen Raketen normal ist: Sie landete im Meer.

  2. Microsoft: WSL2 könnte von Windows-Updates getrennt verteilt werden
    Microsoft
    WSL2 könnte von Windows-Updates getrennt verteilt werden

    Neuerungen für das Windows Subsystem für Linux (WSL) gibt es bisher nur mit großen Updates für Windows selbst. Dank der Architektur des neuen WSL2 könnte sich dies aber bald ändern, was einige Nutzer fordern.

  3. Luftfahrt: DLR-Forscher entwerfen elektrisches Regionalflugzeug
    Luftfahrt
    DLR-Forscher entwerfen elektrisches Regionalflugzeug

    Noch können hybrid-elektrische Regionalflugzeuge nicht mit konventionell angetriebenen Flugzeugen konkurrieren. Das wird sich aber ändern. Forscher des DLR und des Vereins Bauhaus Luftfahrt arbeiten bereits am Elektroflugzeug der Zukunft.


  1. 18:11

  2. 17:00

  3. 16:46

  4. 16:22

  5. 14:35

  6. 14:20

  7. 13:05

  8. 12:23