1751 VPN und Möglichkeiten / Zertifikate

[Kosta]

Hallo,

Da meine Firma den 1751-er abgelöst hat, habe ich unlängst den Router bei mir zu Hause installiert (besser als Asus RT-N66U...).
Die Gründe für den LANCOM sind mehrfach, aber grundsätzlich: mehrere Netzwerke, VPN...

Daher die Fragen zum VPN (und bitte, grundlegend kenne ich mich damit aus, aber eher neu auf dem Gebiet):

Meine Anforderung besteht darin mein iPhone und mein Notebook ins Haus-Netz einzubinden.
Meine Anforderung besteht ebenso darin kein Advanced VPN Client zu verwenden.

Bisher:
iPhone klappt mit der Einrichtung von myVPN und auch manuell nach der Anleitung auf der LANCOM Homepage. Allerdings wenn ich es richtig verstehe passiert der Schlüsselaustausch nicht über dem Zertifikat sondern via Preshared Key -> weniger sicher, wie ich nachlese.
Notebook geht mittlerweile nur mit dem Shrewsoft VPN Access Manager und auch PSK.

Ich verbinde ich mich in mein Heimnetz aus diversen Hotels mit öffentlichen WLANs und sehr viel über HSDPA (mobiler Hotspot am Handy) da ich sehr oft unterwegs bin.

Die Preimse für das ganze heisst sich möglichst gut zu sichern. Daher glaube ich wäre die Verwendung von Zertifikaten wohl sehr sinnvoll...

LANCOM schreibt bei deren Anleitung dass man die Zertifikate mit Hilfe von Tool "XCA" erstellen kann, nur schon nach mehreren Versuchen und Tagen bekomme ich es nicht hin. Auch nicht mit dem Shrewsoft VPN.

Weitere Frage ist, habe ich die Chancen mit den Windows7 Boardmitteln, ohne Shrewsoft? Ich habe bereits gelesen dass mit LCOS 8.x definitiv nein (kein L2TP over IPsec und kein IKEv2 am LANCOM), aber möchte mal auf die Nummer sicher gehen.

Habt ihr für mich Tipps wie es funktionieren soll, gibt es irgendwo vielleicht eine Anleitung hierzu? Soll es funktionieren wie von LANCOM beschrieben?
https://www2.lancom.de/kb.nsf/1275/55EB ... enDocument

[Dr.Einstein]

Hallo Kosta,

mit Win7 Boardmitteln geht es theoretisch, es gab hier auch mal eine Anleitung, allerdings kannste das faktisch vergessen. Der Aufwand ist unglaublich hoch.

Mit Zertifikaten sollte eigentlich gehen, du legst mit XCA eine neue CA an. Basierend darauf erzeugst du für den Lancom ein Zertifikat. Dieses spielst du in den Lancom als pcx12 Container ein inkl der Zertifikatskette. Zusätzlich erzeugst du für die Clients ebenfalls Zertifikate basierend auf der CA. Die kommen dann in die Clients. Im Lancom stellst du die Client Verbindung von Aggressive Mode auf Main Mode + Zertifikatsproposols um, in der Schlüsseltabelle änderst den Typ auf ASN.1 und fügst dort den RFC String vom Lancom / Client ein (CN=...; Email=..usw).

[GrandDixence]

Empfehlungen für die sichere IPSec-VPN-Konfiguration gibt in Deutschland die Technische Richtlinie BSI TR-02102-3:

https://www.bsi.bund.de/SharedDocs/Down ... 3_pdf.html

In dieser Technischen Richtlinie wird der Einsatz von Preshared Key nicht empfohlen. Gemäss dieser Technischen Richtlinie sind folgende LCOS-Einstellungen für einen sicheren IPSec-VPN-Betrieb mit LANCOM-Geräten notwendig:

Code: Alles auswählen

IKE-Exchange                                         Main Mode
Vereinfachte Einwahl mit Zertifikaten aktiviert      Aus
PFS-Gruppe                                           14 (MODP-2048), 15 (MODP-3072), 16 (MODP-4096)
IKE-Gruppe                                           14 (MODP-2048), 15 (MODP-3072), 16 (MODP-4096)
Verschlüsselung                                      AES-CBC
Schlüssel-Länge                                      128, 256
Hash                                                 SHA2-256, SHA2-384, SHA2-512
Gültigkeitsdauer                                     8000
Authentifizierung                                    RSA-Signature
Flexibler-ID-Vergleich                               nein
Modus                                                Tunnel
Authentifizierung (ESP-Proposal)                     HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512
Authentifizierung (AH-Proposal)                      Kein AH

Da LANCOM-Geräte mit dem Betriebsystem LCOS bis und mit v9.00 nur IKEv1 unterstützt, aber die meisten Betriebssysteme nur einen IKEv2-Client mitliefern, sind sichere und stabile VPN-Verbindungen von einem Nicht-LANCOM-Gerät zu einem LANCOM-Geräte eine knifflige Aufgabe.

Mit OpenSSL können die entsprechenden Zertifikate für den IPSec-VPN-Betrieb erstellt werden. Von OpenSSL sollten auch einige Windows-Clients verfügbar sein. Ich persönlich habe ein entsprechende Zertifikatsstruktur für die Anmeldung am HTTPS-Webinterface und die Anmeldung im WLAN (EAP-TLS, WPA2-Enterprise) mit OpenSSL unter Linux erstellt und betreibe diese erfolgreich auf mehreren LANCOM-Geräten.

Heikel beim Erstellen von Zertifikaten ist die Quelle der Zufallszahlen. Es muss ein guter Zufallszahlengenerator für die Zertifikatserstellung genutzt werden. Deshalb sollten Zertifikate ausschliesslich auf dem eigenen PC erstellt werden.

[Kosta]

Hallo Kosta,

mit Win7 Boardmitteln geht es theoretisch, es gab hier auch mal eine Anleitung, allerdings kannste das faktisch vergessen. Der Aufwand ist unglaublich hoch.

Mit Zertifikaten sollte eigentlich gehen, du legst mit XCA eine neue CA an. Basierend darauf erzeugst du für den Lancom ein Zertifikat. Dieses spielst du in den Lancom als pcx12 Container ein inkl der Zertifikatskette. Zusätzlich erzeugst du für die Clients ebenfalls Zertifikate basierend auf der CA. Die kommen dann in die Clients. Im Lancom stellst du die Client Verbindung von Aggressive Mode auf Main Mode + Zertifikatsproposols um, in der Schlüsseltabelle änderst den Typ auf ASN.1 und fügst dort den RFC String vom Lancom / Client ein (CN=...; Email=..usw).

Es ließt sich nicht anders als was ich bisher gemacht habe. Nun wenn ich mir paar Fragen hierzu erlauben darf:
1) Kannst du bitte den Satz "Basierend darauf erzeugst du für den Lancom ein Zertifikat." näher elaborieren? Auf der LANCOM Seite gibt es darüber nichts. Dort wird nur die Erstellung von CA und dessen Export erwähnt, wie ich es verstehe.
2) Beim Export, wähle ich CA oder Server-Zertifikat aus?
3) Das mit dem RFC String ist mir etwas unklar: nehme ich einfach den ganzen RFC 2253 String wie er in dem Zertifikat abzulesen ist? Und dann zum "lokale Identität" wohl RFC vom Zertifikat der auf dem LANCOM eingespielt wurde und bei "entfernte Identität" den vom Client-Zertifikat?

[Dr.Einstein]

1) Kannst du bitte den Satz "Basierend darauf erzeugst du für den Lancom ein Zertifikat." näher elaborieren? Auf der LANCOM Seite gibt es darüber nichts. Dort wird nur die Erstellung von CA und dessen Export erwähnt, wie ich es verstehe.

Naja, du erstellst eine CA in deinem XCA. Danach legst du ein neues Zertifikat an für den Lancom Router mit "verwende dieses Zertifikat zum Unterschreiben" -> die CA, die du zuvor erstellt hast. Das gleiche machst du mit dem Client

2) Beim Export, wähle ich CA oder Server-Zertifikat aus?

Beim Export gibst du doch den Typ des Zertifikats an, also ob als Container, oder öffentlicher Schlüssel etc. verstehe die Frage nicht. Die CA selbst exportierst du nicht.

3) Das mit dem RFC String ist mir etwas unklar: nehme ich einfach den ganzen RFC 2253 String wie er in dem Zertifikat abzulesen ist? Und dann zum "lokale Identität" wohl RFC vom Zertifikat der auf dem LANCOM eingespielt wurde und bei "entfernte Identität" den vom Client-Zertifikat?

Genau, und am Client genau über Kreuz.

@GrandDixence: Ich denke, Mainmode PSK geht man nur davon aus das es unsicher ist, weil der Weg der Übertragung des Schlüssels als normalerweise unsicher eingestuft wird. Hast du zwei verschiedene Firmen die vernetzt werden, kann es passieren, dass Emails oder Telefon dafür genutzt wird. IKEv1 Mainmode PSK an sich ist soweit ich weiß überhaupt nicht unsicher.

[Kosta]

Super, es funktioniert!

Ich habe hier einige Fehler gemacht, unter anderem auch dass ich kein Server-Zertifikat erstellt habe, und CA-export (mit dem Client) hat beim LANCOM natürlich nicht funktioniert. Die Erstellung des "HTTPS_Server" unter CA hat gefunkt, inkl. ich musste auch im Shrewsoft auf "Main" umstellen. Auch die RFC-Strings waren mir unklar...

So, jetzt klickt's ohne Murks, und kann PSK endlich abschaffen

Es nervt ein wenig dass man immer wieder P12 Passwort eingeben muss, aber das ist wohl die Sicherheitssache... ist gut so...

[GrandDixence]

Beim Ausstellen und Beglaubigen von Zertifikaten sind einige Grundregeln zu beachten, damit die Zertifikate "sicher" sind. Empfehlungen für die sichere Zertifikats-Nutzung gibt in Deutschland die Technische Richtlinie BSI TR-02102 und leichter verständlich BSI TR-02102-2:

https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Insbesondere möchte ich darauf hinweisen, dass SHA-1 und MD5 für die Signaturerstellung unsicher sind. Es sollte mindestens SHA-256 für die Signaturerstellung eingesetzt werden.

[GrandDixence]

Ich denke, Mainmode PSK geht man nur davon aus das es unsicher ist, weil der Weg der Übertragung des Schlüssels als normalerweise unsicher eingestuft wird. Hast du zwei verschiedene Firmen die vernetzt werden, kann es passieren, dass Emails oder Telefon dafür genutzt wird. IKEv1 Mainmode PSK an sich ist soweit ich weiß überhaupt nicht unsicher.

Eine Aussage das IKEv1 Mainmode PSK in der Anwendung unsicher ist, habe ich auch noch nie gehört. Jedoch weist der heise VPN-Knigge:

http://www.heise.de/security/artikel/VP ... 70796.html

auf einige Nachteile von Mainmode PSK hin. Die Nutzung von Zertifikaten statt Preshared Key (PSK) hat den Vorteil, dass immer wieder neues Schlüsselmaterial eingesetzt wird. Mainmode PSK bietet kein Perfect Forward Secrecy:

https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy

Alle 8000 Sekunden werden die alten Schlüsseln durch neue Schlüsseln ausgetauscht (LCOS-Konfiguration: Gültigkeit). Ein Angriff auf einen Schlüssel welcher nur 8000 Sekunden lang eingesetzt wurde, macht keinen Sinn. Da ist ein Angriff auf einen Preshared Key, welcher jahrelang eingesetzt wird/wurde, schon viel einfacher und lohnenswerter.

Wegen Perfect Forward Secrecy bietet das WLAN-Anmeldeverfahren EAP-TLS/WPA2-Enterprise (Zertifikat-basiert) die bessere Sicherheit als WPA2-PSK/WPA2-Personal (Preshared Key). Im Zeitalter der totalen Überwachung durch Geheimdienste erachte ich Perfect Forward Secrecy als zwingend notwendig.

[Kosta]

Ich habe gerade versucht mit Signatur Algorithm SHA-256 anstatt SHA-1, und das funktioniert auch. Kann ich irgendwie überprüfen was tatsächlich verwendet wird, interessenshalber?

[GrandDixence]

Ja, in Windows oder im Webbrowser einfach auf das Zertifikat (doppel-)klicken. In den Zertifikat-Details bzw. Zertifikat-Eigenschaften zur Eigenschaft "Zertifikatsunterzeichnungs-Algorithmus" wechseln. Siehe auch beiliegender Firefox-Screenshot.

[Kosta]

Habe folgendes gemacht:
Über certmgr in Windows den Client1 Zertifikat im Format P12 importiert, und hier habe ich dann CA + Client1 Zertfikate bekommen. CA ist SHA1, Client1 ist SHA256.
Ist das korrekt oder muss ich den Weg von Anfang angehen und neue CA erstellen + beiden Server und Client Zertifikate, alle mit SHA256?

EDIT:
Vergiss es. Habe gerade CA auf SHA256 umgestellt, sowie auch die Zertifikate, funkt ohne Probleme.

Ich würd sagen das war's dann, ich möchte mich nun für die Hilfe herzlichst bedanken!