Wie sicher ist https ?

[Black Eagle]

Wir wissen alle, daß es in unserer eigenen Verantwortung liegt, ob wir z.B. https Fernwartung Nutzen oder nicht. (Dies sei gesagt, um Vorwürfen gegenüber AVM zuvorzukommen.Denn ich denke die Fernwartungsfunktion ist eine tolle Funktion, auf die schon viele warteten. Auch wir.)

Ich möchte dennoch folgenden utopischen Gedankengang angehen:

Wir wissen auch, daß rein statistisch, jede Verschlüsselung knackbar ist. (es mag natürlich mehrere 1 000 Jahre dauern)

Wie verwundbar ist https, wenn wir auf der anderen Seite der Welt einen Angreifer haben, der den entsprechenden dyndns Account bzw. die IP Adresse der Fritz Box kennt und sie knacken möchte ?

Ein Schwachpunkt, vermute ich, ist die lesbare Übertragung des Sitzungsschlüssels, der ja meines Wissens unverschlüsselt erfolgt.

Also um es kurz zu machen:
Wenn wir eine Gruppe (z.B. 3) von Hackern hätten, die mit den notwendigen Rechnern ausgestattet sind, wie lange bräuchten diese rein statistisch, um sich trotz https auf die FritzBox Oberfläche zu hacken (Nehmen wir folgende Voraussetzung an: Der richtige Anwender verbindet sich 2 Mal täglich mit der Fritz Box, der Sitzungsschlüssel würde also 2 Mal täglich ausgetauscht. Es handele sich um ein gutes 8 stelliges Passwort.)

Gibts hier im Forum Experten, die da eine einigermaßen präzise Aussage wagen ?

 

[Chatty]

Es gibt nur einen Angriff: Man-In-The-Middle. Den schließt du aus, wenn du das SSL-Zertifkat bei dir "installierst" (dein Browser trägt es an entsprechender Stelle in der Registry ein). Damit ist SSL "unverwundbar".

Wenn du das nicht verstanden hast, google dich schlau.

 

[gandalf94305]

https sagt zunächst mal gar nichts über die Sicherheit einer Anwendung aus.

https mit einem Serverzertifikat bedeutet, daß ein Client die Verbindung zum Server so verschlüsseln kann, daß nur der Server die Daten entschlüsselt bekommt (mit 128 bit SSL ist das ein vertretbarer Aufwand für Sicherheit, denn realistisch kann man das nicht als Normalbürger knacken).

https mit einem Clientzertifikat authentisiert auch den Client, so daß Server nicht auf passwortbasierte Sicherheit zurückgreifen müssen. Dies ist auch bei ssh die bevorzugte Option.

https (serverseitige Zertifikate) kann von jedem genutzt werden. Die Anwendung dahinter ist nicht mehr oder weniger gegen Einbruch gesichert als zuvor. Man kann nur das Mithören im Transit ausschließen, d.h. das Ausspähen von Credentials. Mit anderen Worten: ich kann auch per https eine Brute-Force-Attack starten, um Passworte durchzuprobieren.

https mit clientseitigen Zertifikaten wäre der Weg, eine Verbindung deutlich sicherer herzustellen, denn nun muss sich der Client mit Zertifikat authentisieren. Dies verwende ich generell für alle VPN- und ssh-Verbindungen auf meine Server.

--gandalf.

 

[MReimer]

Es gibt nur einen Angriff: Man-In-The-Middle. Den schließt du aus, wenn du das SSL-Zertifkat bei dir "installierst" (dein Browser trägt es an entsprechender Stelle in der Registry ein). Damit ist SSL "unverwundbar".

Weder SeaMonkey noch Firefox tragen irgendwas in irgendwelche Registries ein.

 

[Chatty]

Weder SeaMonkey noch Firefox tragen irgendwas in irgendwelche Registries ein.

Ob das richtig ist, muss jeder für sich selbst entscheiden. Windows beherbergt extra einen Zertifikatsspeicher mit standardisierter Schnittstelle.

 

[voipd]

@Gandalf

Kannst du dieses Thema noch ein wenig weiter aufbroeseln?
Ein wenig Praxisorientiert bitte.
Deine Ausfuehrungen haben mich verwirrt insbesondere im Bezug auf ssh.

Danke.

voipd.

 

[MReimer]

Ob das richtig ist, muss jeder für sich selbst entscheiden. Windows beherbergt extra einen Zertifikatsspeicher mit standardisierter Schnittstelle.

Warum? Es ist Fakt, dass SeaMonkey und Firefox eine "cert8.db" zum Verwalten der Zertifikate nutzen. Diese befindet sich im jeweiligen Profilverzeichnis. AFAIK ist das eine SQLite Datenbank.

Ganz davon abgesehen, dass ich alles, was von Microsoft kommt, grundsätzlich mit Vorsicht mit "Standard" bezeichnen würde. SeaMonkey und Firefox sollen nahezu unverändert auch auf freien Systemen laufen. Dort gibt es die Microsoft-"Standards" nicht.

 

[RalfFriedl]

@MReimer
Die Aussage zu SeaMonkey, Firefox und Registries ist in der Form vermutlich falsch.

Und auf jeden Fall haben diese Browser die Möglichkeit, Zertifikate als vertrauenswürdig zu speichern. Ob dafür die Windows Registry oder ein anders genannter Speicher genutzt wird, ändert am Prinzip nichts.

@Black Eagle
Mit HTTPS werden die Daten verschlüsselt übertragen. Es spielt dabei keine Rolle, ob der richtige Anwender sich einmal am Tag oder einmal pro Sekunde anmeldet.

HTTPS schützt allerdings nicht davor, daß ein Angreifer mögliche Paßwörter durchprobiert. Das hat aber nichts damit zu tun, ob oder wie oft sich der richtige Anwender anmeldet.

Der einzig aussichtsreiche Angriff ist der so genannte Man-In-The-Middle Angriff. Dieser setzt voraus, daß ein Angreifer aktiv in die Netzwerk-Verbindung eingreifen kann. Der Schutz dagegen ist ein Zertifikat, mit dem sich er Server gegenüber dem Client ausweisen kann. Ich weiß nicht, wie es mit dem Zertifikat beim HTTPS-Zugang der Box aussieht, aber wenn das vernünftig gemacht ist, besteht auch da keine Gefahr.

 

[MReimer]

@MReimer
Die Aussage zu SeaMonkey, Firefox und Registries ist in der Form vermutlich falsch.

Mit "Registry" verbinde ich in erster Linie die Windows-Datenmüllhalde, die von Microsoft auf diesen Namen getauft wurde. Der einzige Browser, der dort tatsächlich Zertifikate ablegt, dürfte der Internet Explorer sein.

HTTPS schützt allerdings nicht davor, daß ein Angreifer mögliche Paßwörter durchprobiert. Das hat aber nichts damit zu tun, ob oder wie oft sich der richtige Anwender anmeldet.

Stimmt. Das kann man, wie bereits von Gandalf angemerkt, durch Client-Zertifikate lösen. Allerdings habe ich selber noch nie eine solche Konfiguration erstellt. Vielleicht hat ja jemand einen Link, wo die Einrichtung erklärt wird?

Alternativ: Login nach X Versuchen für Y Minuten sperren.

@Gandalf
Kannst du dieses Thema noch ein wenig weiter aufbroeseln?
Ein wenig Praxisorientiert bitte.
Deine Ausfuehrungen haben mich verwirrt insbesondere im Bezug auf ssh.

http://linuxproblem.org/art_9.html

 

[RalfFriedl]

SSH ist im Prinzip das Gleiche wie HTTPS, im Detail aber anders und folglich nicht kompatibel. Man kann Zertifikate verwenden, um den Server oder den Client zu identifizieren, wobei es beim Client optional ist, beim Server ist es notwendig.

Das war aber nicht die ursprüngliche Frage.

Ein Schwachpunkt, vermute ich, ist die lesbare Übertragung des Sitzungsschlüssels, der ja meines Wissens unverschlüsselt erfolgt.

Dies ist natürlich nicht der Fall, sonst könnte man sich ja die ganze Verschlüsselung sparen, wenn man vorher für alle sichtbar den Schlüssel sendet.

Kurz gesagt, HTTPS ist dafür ausgelegt, daß ein Angreifer volle Kontrolle über die Netzwerkverbindung zwischen Client und Server haben kann (mithören, abfangen und ändern von Paketen) und die Übertragung trotzdem sicher ist.

 

[gandalf94305]

@voipd: habe ich meinen letzten Satz zu verkürzt wiedergegeben? ;-) Was ich meinte: Angriffe gibt es nicht nur in Form des Mithörens, sondern auch mit einer Brute-Force-Methode, um das FBF-Passwort zu knacken. Also hilft hier SSL nicht. Hier helfen nur Clientzertifikate, die dazu dienen, Clients zu identifizieren und damit zu authentisieren. Aus diesem Grund würde ich ssh-Zugriffe auch nicht per Username und Passwort erlauben, sondern nur Zugriffe per Clientzertifikat, das im Server bekannt ist.

--gandalf.

PS: Konkretisiere mal den Punkt, den Du praxisnäher ausgedrückt haben möchtest.

 

[DPR]

Ein Schwachpunkt, vermute ich, ist die lesbare Übertragung des Sitzungsschlüssels, der ja meines Wissens unverschlüsselt erfolgt.

Was meinst du denn mit "Sitzungsschlüssel" ? Das "MasterSecret" oder das "PreMasterSecret" ?

Wie auch immer, das ist falsch ! Der Client sendet dem Server das "PreMasterSecret" verschlüsselt mit dem Public-Key des Servers. Nur die zusätzlichen Zufalls-Zahlen die Client und Server vorher austauschen sind im Klartext, als Schutz gegen Replay-Attacken.

Wenn du dich ein bisschen mit Kryptographie auskennst, stellt sich diese Frage onehin nicht. Die größte Schwachstelle ist nicht etwa SSL sondern die Passwort-Authentifizierung der Fritz!Box Oberfläche. Der Suchraum ist dort deutlich kleiner und man kann Techniken wie Wörterbuchattacken usw. anwenden. Abgesehen von potentiellen Sicherheitslücken in der Oberfläche.

Wie auch schon andere angemerkt haben, brauchst du für echte Sicherheit HTTPS Client-Authentifizierung.

Das kann man übrigens per Stunnel machen, ist standardgemäß im Client-Modus aber nicht aktiv ! Ich weiß nicht genau, was da AVM in den neuen Firmwares gemacht hat ...

Wer ein momentan sicheren Zugang zur Oberfläche haben will, sollte HTTPS mit Client-Authentifizierung verwenden und das ganze am Besten nicht auf dem Standard-Port laufen lassen, was zumindest schonmal Script-Kiddies fernhält

 

[Feuerwehr]

HTTPS schützt allerdings nicht davor, daß ein Angreifer mögliche Paßwörter durchprobiert.

Ist ja auch kein Thema, wenn man lange kryptische PW verwendet. Und wer sich die nicht merken kann/will, nimmt einen USB Stick mit Passwortmanager mit auf Reisen.

Seitens AVM könnte man jede Falscheingabe mit einer 10-Sekunden-Einwahlsperre quittieren. Macht für Bruteforce oder Wörterbuch-Attacken dann 6 Versuche pro Minute, könnte etwas dauern...

 

[gandalf94305]

könnte... wollte... hätte... sollte...

Ist aber nicht... und da ist der Haken :hehe:

SCNR,
--gandalf.

 

[MReimer]

Seitens AVM könnte man jede Falscheingabe mit einer 10-Sekunden-Einwahlsperre quittieren. Macht für Bruteforce oder Wörterbuch-Attacken dann 6 Versuche pro Minute, könnte etwas dauern...

Seitens AVM ist der externe Zugriff nicht unterstützt.

Könnte man dieses Plus an Sicherheit nicht selbst reinmodden? Ein "sleep 3" vor der Überprüfung des Passworts würde den Login-Vorgang schonmal künstlich zäher machen.

 

[RalfFriedl]

Nicht solange mehrere Verbindungen parallel möglich sind.

 

[MReimer]

Stimmt. Das hatte ich nicht bedacht. Man müsste also die Anzahl der Verbindungen zusätzlich drosseln. Das könnte man doch via "ps -A" erreichen. Wenn das CGI für's Login mehr als z.B. zwei mal gefunden wird, dann direkt aussteigen.

 

[RalfFriedl]

Bevor man sich da groß Gedanken dazu macht:
Hat schon jemand einen Brute-Force Angriff auf das Remote-Paßwort der Box beobachtet?
Die Zahl der Versuche ist vermutlich schon durch die geringe Rechenleistung der Box beschränkt. Irgendwo wurde darüber diskutiert, daß Anmelde-Versuche auf SSH die Box wegen CPU-Last zum Absturz gebracht haben.

 

[Black Eagle]

Wie dem auch sei, ich möchte mal etwas fernab von der Sache sagen:

Ich bin froh, daß AVM diese Fernwartungs Funktion integriert hat. (Wir u Bekannte von uns warten jedoch auch noch auf die Freigabe dieser Firmware für die 7170 Annex A Schweiz/Österreich)

Bezüglich der Sicherheit haben wir hier wohl keine "präzisen " Antworten, das scheint mir aber wohl u.a. daran zu liegen, daß es sooo unsicher wohl nicht ist... (Kllingt zwar dämlich einfach, aber, ist meine persönliche Laien-Schlußfolgerung...)

Und wie gesagt, niemand MUSS es einschalten...

Danke für eure Feedbacks...

 

[bholmer]

Bevor man sich da groß Gedanken dazu macht:
Hat schon jemand einen Brute-Force Angriff auf das Remote-Paßwort der Box beobachtet?
Die Zahl der Versuche ist vermutlich schon durch die geringe Rechenleistung der Box beschränkt. Irgendwo wurde darüber diskutiert, daß Anmelde-Versuche auf SSH die Box wegen CPU-Last zum Absturz gebracht haben.

Auf das Passwort zwar nicht, aber mein FTP-Server auf dem PC hinter der Box beobachtet fast täglich Zugriffsversuche von chinesischen IP's aus mit dem Username "administrator".
Die Sache mit der Verzögerung ist sicher eine gute Idee, solche Brute-force Angriffe zu verhindern.
Insofern wäre es durchaus denkbar, dass jemand es versucht.
Wird ein nicht erfolgreicher Zugriffsversuch auf die Box denn überhaupt protokolliert, so dass man es mitbekommt ?
Bert