Ohrenschmalz
Aktives Mitglied
- Mitglied seit
- 19 Apr 2006
- Beiträge
- 840
- Punkte für Reaktionen
- 32
- Punkte
- 28
[Problem] VPN Datei wird nicht angenommen
- Ersteller geohei
- Erstellt am
-
- Schlagworte
- fritzbos 7490 vpn vps fritz!box
Hash Wert des PSK vs. Verschlüsselung desselben. Klar, mit entsprechend langem PSK auch schwierig.
Was ich mir noch von AVM wünschen würde: IKE V2.
Was ich mir noch von AVM wünschen würde: IKE V2.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Mit zwei FRITZ!Boxen mag der Main-Mode sogar noch funktionieren (habe ich nie probiert) ... gegen andere Implementierungen dürfte das schwierig werden, weil die Identität des Clients irgendwie "geprüft" werden müßte, damit man im Main-Mode mit PSK (Zertifikate funktionieren ja offiziell nicht mehr, obwohl sie wohl mal in Verbindung von AVM Access Server und KEN! verwendet werden konnten: https://avm.de/fileadmin/user_uploa...kte/Serverprodukte/Handbuch_Access_Server.pdf, S. 101) auch den korrekten PSK findet und nicht nur durch "Probieren" einer Dekodierung auf den richtigen Schlüssel schließt.
Daher erfordert der Main-Mode eben irgendein "festes" Kriterium für den "anklopfenden" Client ... das kann von der festen IP-Adresse bis zum bereits erwähnten Zertifikat gehen, mit dem sich der Client (wenn er keine feste Adresse hat) auch ausweisen könnte. Im Main-Mode wird jedenfalls erst im fünften Schritt der PSK dann wirklich zur Authentifizierung herangezogen und zu diesem Zeitpunkt muß die Identität des anfragenden Clients bereits bekannt sein. Daher gilt es als Faustregel, daß beim Main-Mode mindestens einer der beiden Beteiligten eine statische IP-Adresse haben muß (bzw. sollte).
Hat der Client hingegen keine feste Adresse, kommt wieder der Aggressive-Mode zum Einsatz ... zusammen mit der passenden ID für P1 sendet der Client einen Hash-Wert über den PSK und erst wenn der unter der ID gefundene PSK (bzw. dessen Hash) mit dem gesendeten übereinstimmt, geht es überhaupt weiter.
Die Anfälligkeit des Aggressive-Mode bei ungeeignetem PSK ist seit über 15 Jahren bekannt (selbst der Artikel von M. Thumann (der ja auch zu den Autoren des oben verlinkten PDF gehört) in der c't ist so alt: https://heise.de/-270592) und die meisten Anleitungen, die vor diesem Mode warnen, stammen auch aus dieser Zeit. Dabei beschreibt er selbst schon richtig, daß es mit einem ordentlichen Hash-Algorithmus (damals waren noch RC4 (Arcfour) und MD5 Usus) und einem ebenso sorgsam gewählten PSK auch Jahre dauern würde, den passenden Key zu berechnen. Denn dafür bräuchte es nicht nur eine Kollision (die für SHA-1 schon gezeigt wurde von Google, wenn auch mit hohem Aufwand), sondern eine erfolgreiche Preimage-Attacke ... also die Herleitung des Keys aus dem Hash und nicht nur das Finden einer zweiten Zeichenkette mit demselben Hash, weil da ja beim Austausch noch ein weitere Daten (ID und Nonce) dynamisch in den Hash-Wert einbezogen werden. Einzig die "Identität" (also der "Selektor", mit dem der Responder in seiner Key-Database nach dem richtigen PSK suchen muß) ist hier "unverschlüsselt" und das kann (z.B. bei User-FQDN mit einer gültigen Mail-Adresse) ein Problem sein ... darum betone ich auch immer wieder, daß diese IDs für P1 alles mögliche sein können, solange das Format paßt und es sich weder um den eigenen DynDNS-Namen handeln muß noch um eine "eingetragene" Domain.
Im Main-Mode mit PSK-Authentifizierung braucht also mind. eine Seite eine bekannte IP-Adresse ... das kann man zwar über DynDNS-Adressen auch realisieren, dann muß aber jede Seite immer wieder diese Adressen abfragen und bei einer Änderung diesen "Selektor" ersetzen. Gut möglich, daß AVM bei der Verbindung zweier FRITZ!Boxen tatsächlich so arbeitet, wenn irgendeine Seite den "main mode" verwenden will (ist ja alles "closed source") und es gab auch früher Ansätze unter Linux, das mit einer Aktualisierung der "key database" zu machen ( ... aber zwischen Produkten verschiedener Hersteller dürfte das eher schwierig werden und daher sollte man es bei der Faustformel: "Beide Seite ohne feste IP-Adresse => Aggressive-Mode benutzen" belassen (anstatt in den VPN-Konfigurationen zu ändern) und lieber dafür sorgen, daß man mind. SHA1 als Hash-Algorithmus und einen "ordentlichen" PSK (darunter verstehe ich tatsächlich mind. 32 Zeichen Zufall mit ausreichender Entropie) verwendet.
Es gibt also nicht wirklich große Probleme, wenn man bei der eigenen VPN-Verbindung die Einstellung auf "aggressive mode" beläßt, solange man sich darum bemüht, daß die anderen Einstellungen "passen". Zwar hat AVM auch immer noch MD5 als Hash "im Angebot", aber beide Peers sollten sich ja auf die jeweils stärksten Algorithmen einigen und auch bei MD5 sind (selbst wenn es lange "deprecated" ist) keine "echten" Preimage-Attacken bekannt, sonst wäre auch die Signatur von AVM für die Firmware-Images schon "geknackt".
Man darf also durchaus auch den "aggressive mode" mit dem AVM-VPN verwenden ... aber wer das mit dem Kennwort "test1234" macht, muß sich auch nicht wundern, wer da plötzlich an seiner Stelle die Verbindung herstellt. Daher habe ich auch etwas andere "Wünsche" an AVM und die beeinhalten u.a. auch die Aufforderung, mit schwachen PSK gar keine Einrichtung einer Verbindung zuzulassen und sich Gedanken darüber zu machen, wie man die Daten für die Einrichtung einer VPN-Verbindung ansonsten noch sicher zwischen zwei Peers austauschen kann. Bei allen solchen "Schlüsselaustauschverfahren" kann ja auch eine "out-of-band"-Übermittlung dieser (durchaus wichtigen) Daten erfolgen.
-------------------------------------------------------------------------------------------------------------
Was ich mir von AVM also eher wünschen würde, wäre eine "automatische Einrichtung" einer VPN-Verbindung zwischen zwei LANs ... man gibt in der einen Box im GUI die (DynDNS-)Adresse der anderen Box an (in der zumindest für diese Zeit der Fernzugriff angeschaltet wird) und einen Benutzernamen (mit Admin-Rechten) samt passendem Kennwort auf der anderen Box und die beiden richten damit (am besten sogar noch mit der Möglichkeit, zwischen "Initiator" und "Responder" zu unterscheiden, weil dann auch die Box am DS-Lite-Anschluß eine andere mit öffentlicher IPv4 kontaktieren kann) die Verbindung (mit starkem PSK) selbst ein. Danach kann man ja getrost auf der entfernten Box den Fernzugang wieder abschalten (wenn man ihn nicht anderweitig braucht) ... aber so wäre auch eine "bequeme" Einrichtung einer sicheren Verbindung möglich.
Wenn das (jemandem) zu kompliziert ist, wäre immer noch der Export der passenden VPN-Konfiguration für den Peer (natürlich mit einem starken Kennwort verschlüsselt) eine nette Option ... den kann man dann per E-Mail durch die Gegend schicken (möglichst das Kennwort nicht auch noch in dieselbe E-Mail schreiben) oder sogar die VPN-Konfigurationsdatei über die NAS-Services der FRITZ!Box für den Peer freigeben, damit der sich die dort selbst holen kann.
Geht man bei der Verschlüsselung sogar hin und nimmt den Public-Key aus der anderen Box für die Verschlüsselung (den pustet sie selbst schließlich auch ständig durch die Gegend, wenn der Fernzugriff aktiviert ist und auch jede AVM-App speichert den Public-Key (anstelle des "self-signed certificate") für die Box, an der sie angemeldet ist), dann kann auch wieder nur diese eine Box mit der verschlüsselten Datei etwas anfangen. Notfalls kann der Besitzer der Box bei der Gegenstelle deren Zertifikat sogar exportieren und man kann es - ganz offen - per E-Mail versenden ... dann braucht man den Fernzugriff nicht einmal (auch nicht temporär) zu aktivieren.
Das sind auch (zumindest in meiner Vorstellung) keine so komplizierten Vorgänge, daß der "Durchschnittsbenutzer" damit nicht klarkommen sollte ... jede Push-Mail-Einrichtung ist da komplizierter, solange für diese VPN-Konfiguration die passenden GUI-Seiten bereitstehen.
Da gäbe es also noch ein weites Betätigungsfeld für AVM, auch jenseits der Implementierung von IKEv2 - das stünde vor ähnlichen Problemen und würde nur die direkte VPN-Verbindung von ein paar weiteren Systemen (in erster Linie die neueren Windows-OS) ohne zusätzliche Software ermöglichen.
-------------------------------------------------------------------------------------------------------------
Die Liste der Proposal-Sets von 2007 ist schon seit 06.2x nicht mehr aktuell ... welche wirklich verwendet werden können, findet man am ehesten mit einem "grep 'name=' filename" über die "ipsec.cfg" in der eigenen Firmware heraus und wer auch noch wissen will, was in welchem dieser Sätze erlaubt ist, der schaut sich die Einstellungen genau an und verzichtet auf das "grep".
Daher erfordert der Main-Mode eben irgendein "festes" Kriterium für den "anklopfenden" Client ... das kann von der festen IP-Adresse bis zum bereits erwähnten Zertifikat gehen, mit dem sich der Client (wenn er keine feste Adresse hat) auch ausweisen könnte. Im Main-Mode wird jedenfalls erst im fünften Schritt der PSK dann wirklich zur Authentifizierung herangezogen und zu diesem Zeitpunkt muß die Identität des anfragenden Clients bereits bekannt sein. Daher gilt es als Faustregel, daß beim Main-Mode mindestens einer der beiden Beteiligten eine statische IP-Adresse haben muß (bzw. sollte).
Hat der Client hingegen keine feste Adresse, kommt wieder der Aggressive-Mode zum Einsatz ... zusammen mit der passenden ID für P1 sendet der Client einen Hash-Wert über den PSK und erst wenn der unter der ID gefundene PSK (bzw. dessen Hash) mit dem gesendeten übereinstimmt, geht es überhaupt weiter.
Die Anfälligkeit des Aggressive-Mode bei ungeeignetem PSK ist seit über 15 Jahren bekannt (selbst der Artikel von M. Thumann (der ja auch zu den Autoren des oben verlinkten PDF gehört) in der c't ist so alt: https://heise.de/-270592) und die meisten Anleitungen, die vor diesem Mode warnen, stammen auch aus dieser Zeit. Dabei beschreibt er selbst schon richtig, daß es mit einem ordentlichen Hash-Algorithmus (damals waren noch RC4 (Arcfour) und MD5 Usus) und einem ebenso sorgsam gewählten PSK auch Jahre dauern würde, den passenden Key zu berechnen. Denn dafür bräuchte es nicht nur eine Kollision (die für SHA-1 schon gezeigt wurde von Google, wenn auch mit hohem Aufwand), sondern eine erfolgreiche Preimage-Attacke ... also die Herleitung des Keys aus dem Hash und nicht nur das Finden einer zweiten Zeichenkette mit demselben Hash, weil da ja beim Austausch noch ein weitere Daten (ID und Nonce) dynamisch in den Hash-Wert einbezogen werden. Einzig die "Identität" (also der "Selektor", mit dem der Responder in seiner Key-Database nach dem richtigen PSK suchen muß) ist hier "unverschlüsselt" und das kann (z.B. bei User-FQDN mit einer gültigen Mail-Adresse) ein Problem sein ... darum betone ich auch immer wieder, daß diese IDs für P1 alles mögliche sein können, solange das Format paßt und es sich weder um den eigenen DynDNS-Namen handeln muß noch um eine "eingetragene" Domain.
Im Main-Mode mit PSK-Authentifizierung braucht also mind. eine Seite eine bekannte IP-Adresse ... das kann man zwar über DynDNS-Adressen auch realisieren, dann muß aber jede Seite immer wieder diese Adressen abfragen und bei einer Änderung diesen "Selektor" ersetzen. Gut möglich, daß AVM bei der Verbindung zweier FRITZ!Boxen tatsächlich so arbeitet, wenn irgendeine Seite den "main mode" verwenden will (ist ja alles "closed source") und es gab auch früher Ansätze unter Linux, das mit einer Aktualisierung der "key database" zu machen ( ... aber zwischen Produkten verschiedener Hersteller dürfte das eher schwierig werden und daher sollte man es bei der Faustformel: "Beide Seite ohne feste IP-Adresse => Aggressive-Mode benutzen" belassen (anstatt in den VPN-Konfigurationen zu ändern) und lieber dafür sorgen, daß man mind. SHA1 als Hash-Algorithmus und einen "ordentlichen" PSK (darunter verstehe ich tatsächlich mind. 32 Zeichen Zufall mit ausreichender Entropie) verwendet.
Es gibt also nicht wirklich große Probleme, wenn man bei der eigenen VPN-Verbindung die Einstellung auf "aggressive mode" beläßt, solange man sich darum bemüht, daß die anderen Einstellungen "passen". Zwar hat AVM auch immer noch MD5 als Hash "im Angebot", aber beide Peers sollten sich ja auf die jeweils stärksten Algorithmen einigen und auch bei MD5 sind (selbst wenn es lange "deprecated" ist) keine "echten" Preimage-Attacken bekannt, sonst wäre auch die Signatur von AVM für die Firmware-Images schon "geknackt".
Man darf also durchaus auch den "aggressive mode" mit dem AVM-VPN verwenden ... aber wer das mit dem Kennwort "test1234" macht, muß sich auch nicht wundern, wer da plötzlich an seiner Stelle die Verbindung herstellt. Daher habe ich auch etwas andere "Wünsche" an AVM und die beeinhalten u.a. auch die Aufforderung, mit schwachen PSK gar keine Einrichtung einer Verbindung zuzulassen und sich Gedanken darüber zu machen, wie man die Daten für die Einrichtung einer VPN-Verbindung ansonsten noch sicher zwischen zwei Peers austauschen kann. Bei allen solchen "Schlüsselaustauschverfahren" kann ja auch eine "out-of-band"-Übermittlung dieser (durchaus wichtigen) Daten erfolgen.
-------------------------------------------------------------------------------------------------------------
Was ich mir von AVM also eher wünschen würde, wäre eine "automatische Einrichtung" einer VPN-Verbindung zwischen zwei LANs ... man gibt in der einen Box im GUI die (DynDNS-)Adresse der anderen Box an (in der zumindest für diese Zeit der Fernzugriff angeschaltet wird) und einen Benutzernamen (mit Admin-Rechten) samt passendem Kennwort auf der anderen Box und die beiden richten damit (am besten sogar noch mit der Möglichkeit, zwischen "Initiator" und "Responder" zu unterscheiden, weil dann auch die Box am DS-Lite-Anschluß eine andere mit öffentlicher IPv4 kontaktieren kann) die Verbindung (mit starkem PSK) selbst ein. Danach kann man ja getrost auf der entfernten Box den Fernzugang wieder abschalten (wenn man ihn nicht anderweitig braucht) ... aber so wäre auch eine "bequeme" Einrichtung einer sicheren Verbindung möglich.
Wenn das (jemandem) zu kompliziert ist, wäre immer noch der Export der passenden VPN-Konfiguration für den Peer (natürlich mit einem starken Kennwort verschlüsselt) eine nette Option ... den kann man dann per E-Mail durch die Gegend schicken (möglichst das Kennwort nicht auch noch in dieselbe E-Mail schreiben) oder sogar die VPN-Konfigurationsdatei über die NAS-Services der FRITZ!Box für den Peer freigeben, damit der sich die dort selbst holen kann.
Geht man bei der Verschlüsselung sogar hin und nimmt den Public-Key aus der anderen Box für die Verschlüsselung (den pustet sie selbst schließlich auch ständig durch die Gegend, wenn der Fernzugriff aktiviert ist und auch jede AVM-App speichert den Public-Key (anstelle des "self-signed certificate") für die Box, an der sie angemeldet ist), dann kann auch wieder nur diese eine Box mit der verschlüsselten Datei etwas anfangen. Notfalls kann der Besitzer der Box bei der Gegenstelle deren Zertifikat sogar exportieren und man kann es - ganz offen - per E-Mail versenden ... dann braucht man den Fernzugriff nicht einmal (auch nicht temporär) zu aktivieren.
Das sind auch (zumindest in meiner Vorstellung) keine so komplizierten Vorgänge, daß der "Durchschnittsbenutzer" damit nicht klarkommen sollte ... jede Push-Mail-Einrichtung ist da komplizierter, solange für diese VPN-Konfiguration die passenden GUI-Seiten bereitstehen.
Da gäbe es also noch ein weites Betätigungsfeld für AVM, auch jenseits der Implementierung von IKEv2 - das stünde vor ähnlichen Problemen und würde nur die direkte VPN-Verbindung von ein paar weiteren Systemen (in erster Linie die neueren Windows-OS) ohne zusätzliche Software ermöglichen.
-------------------------------------------------------------------------------------------------------------
Die Liste der Proposal-Sets von 2007 ist schon seit 06.2x nicht mehr aktuell ... welche wirklich verwendet werden können, findet man am ehesten mit einem "grep 'name=' filename" über die "ipsec.cfg" in der eigenen Firmware heraus und wer auch noch wissen will, was in welchem dieser Sätze erlaubt ist, der schaut sich die Einstellungen genau an und verzichtet auf das "grep".
Neueste Beiträge
-
Plain White Screen and Freezing Issues on Avaya J100 SIP Phones
- Letzte: evelynfreya
-
[Problem] Tonwahl beim T48S- Letzte: NDiIPP
-
[Frage] Dect-WS500S Verbindungen an Compact 4000
- Letzte: oezi
