Hallo,
ich möchte für ein Android Gerät einen VPN Einwahlzugang in mein Netz schaffen.
Das geht bequem mit einem Assistenten, dann IKEv1.
Oder manuell, dann geht auch IKEv2.
Ist IKEv1 ein Sicherheitsmangel, den man vermeiden sollte?
Der Schlüssel an sich wäre zufallsgeneriert und sicher. Sehr sicher.
Router ist Lancom 1781A, da ich keine feste IP besitze, läuft es über einen deutschen Anbieter von dynamischem DNS.
Hallo,
anscheinend geht es um IPSec …
Nein, eigentlich nicht. Es geht ja ohnehin „nur“ um einen Schlüsselaustausch. Der wurde unter IKEv2 vor allem weniger komplex gestaltet. Komplexität ist ja ohnehin das Problem von IPSec …
Sebastian
Das scheint eher cooler mit IKEv2 zu sein …
IKEv2 ist in vielen Dingen weniger komplex als IKEv1 ohne jedoch grundlegend unsicherer zu sein. Es schwebt oftmals der Bleichenbacher Angriff im Raum, wenn man über die Unsicherheiten bei IKEv1 liest. Meines Wissens gibt es aber noch keinen realen Fall, wo dies erfolgreich durchgeführt wurde, sondern nur Labortests.
In einem professionellen Umfeld sollte solch ein Angriff auf jeden Fall zu einem Security Alert führen. Bei Deinem Router zu Hause wohl eher nicht.
Wichtig ist auf jeden Fall ein sicheres Passwort, wenn Du ohne Zertifikate arbeitest.
Ansonsten würde ich in Deinem Szenario mit IKEv2 arbeiten, wenn beide Geräte das unterstützen. In meinem letzten Projekt vor zwei Jahren konnten leider nicht alle Geräte IKEv2, so dass ich gezwungenermaßen mit IKEv1 arbeiten musste, kann ich jedoch nicht empfehlen.
Viele Grüße
Alexander
Es handelt sich dabei um einen Lancom 1781A, sicher kein üblicher Heimrouter.
Ich habe mal beide Varianten durchgespielt, IKEv1 war easy dank Assistent, IKEv2 habe ich wohl irgendwas falsch gemacht. Also ist es IKEv1 geworden.
Ist 8so=YWbq.0;kvG=E sicher genug?
Nein.
Nimm 8so=YWbq10;k$G=E, da ist 25% mehr Entropie drinne!
SCNR
So sehen Passwörter aus, die von einem Hardware-Zufallsgenerator ausgegeben werden.
Wo ich einen Hardware-Zufallszahlengenerator her habe? Der ist im Router eingebaut. Wie gesagt, eher KEIN Heimrouter.
Okay.
Zufallsgeneratoren oder vielmehr die Pseudozufallsgeneratoren (PRNG) sind ein nicht triviales Thema. gerade auf „kleiner“ Hardware („Router“ ) neigen sie dazu, zu wenig Entropie zu haben und eher vorhersehbare Ergebnisse zu liefern.
Auf einem „richtigen Rechner“, der Tastatur, Festplatte und ähnliches als zusätzliche Vergrößerung des Entropie-Pools hat würde ich eher sowas nutzen
head /dev/random | tr -dc A-Za-z0-9 | head -c10
und dann die Ergebnisse in die Konfiguration der Verbindung übertragen.
oder „pwgen“ (aus sicherer Quelle!) benutzen.
Kommt eben auf Deinen Paranoia-Level an 
Gruß & HTH,
Sebastian
Echt nur unter Einbeziehen von Widerstandsrauschen. Ich bezweifele, dass das Lancon-Ding das macht, weiss es aber nicht.
Bei den Implementierungen von Zufallszahlengeneratoren ist allerdings schon einiges schief gegangen …
Wenn man sich auf dieser Plattform schon auf diesem Niveau unterhält, sollte man anstatt „/dev/random“ „/dev/urandom“ verwenden. Es sind übrigens beides "PRNG"s.
Nein.
Ja.
Und /dev/urandom geht immer, auch wenn der Entropie-Pool eigentlich schon leer ist.
Ich finde, hier ist es die falsche Plattform für die Diskussion, würde auch nicht in den Thread gehören. Ich verweise auf die diversen Fachabhandlungen, die u.A. auch im Internet zu finden sind.
Ich finde, nur weil man falsch liegt, kann man das ruhig zugeben und muss dann nicht die Diskussion für off topic erklären.
Sinnvoll ist es hingegen, die Dinge richtigzustellen.
Danke für Dein Verständnis hierfür.
Würden dir der Linux Source Code als Referenz genügen?
The two other interfaces are two character devices /dev/random and
/dev/urandom. /dev/random is suitable for use when very high
quality randomness is desired (for example, for key generation or
one-time pads), as it will only return a maximum of the number of
bits of randomness (as estimated by the random number generator)
contained in the entropy pool.
The /dev/urandom device does not have this limit, and will return
as many bytes as are requested. As more and more random bytes are
requested without giving time for the entropy pool to recharge,
this will result in random numbers that are merely cryptographically
strong. For many applications, however, this is acceptable.
(Via https://github.com/torvalds/linux/blob/master/drivers/char/random.c )
die entsprechend relevanten Codebestandteile von *BSD zu suchen, zu lesen und zu verstehen überlasse ich dem geneigten Leser als Übung.
Sebastian
Schlechte Empfehlung
Warning: /dev/urandom is not recommended for the generation of long-term cryptographic keys.
Quelle https://wiki.archlinux.org/index.php/Random_number_generation
Und dass hier um „long-term cryptographic keys“ geht ist wohl unumstritten. Oder?
Da müsste man mal nachfragen.
Teuer genug dafür sind diese Kisten ja allemal, Listenpreis war mal bei 700€, real bezahlt man über 500€ für ein Neugerät.
Andererseits:
Ich schreibe mir alle Passwörter auf. Auf Papier.
Und ich füge bei allen diesen Passwörtern immer weitere Zeichen hinzu, immer an den selben Stellen, immer die selben Zeichen, ohne diese aufzuschreiben. Wem meine Liste in die Hände fällt, dem fehlen diese Zeichen. Und diese Zusatzzeichen sorgen dafür, dass man bei einem schlechten Generator auf dessen erzeugte Werte schließen kann - aber nicht auf meine Zusatzzeichen.