Re: [OT] VPN-Technologie

Hallo!

Dirk Wolfgang Glomp schrieb am 18.05.2009:

Solange ich jetzt nichts Gegenteiliges höhre/lese nehme ich jetzt
mal an, das Hamachi und Tunngle auch mit SSH anstelle von VPN
möglicherweise zu realisieren wäre.

Nein.

Bist du sicher?

Ja, er hat recht.

Mit ssh greifst du mit einem Protokoll (ssh halt) auf den entfernten
Rechner zu.

Richtig.

Ja, aber man greift auch *nur* auf den Rechner zu. Man kann Dateien
downloaden die *auf diesem Rechner* für deinen Account freigegeben
sind, Befehle *auf diesem Rechner* ausführen zu denen dein Account die
Berechtigung hat, etc. Mehr kannst du aber nicht machen.

Mit VPN kannst du auf jeden Dienst des Zielrechners zugreifen.
Beispiel: Du arbeitest per RDP auf einem Terminalserver, und dieser
schickt Druckdaten an deinen lokalen Drucker.

Ich kann mir gar nicht vorstellen auf welche Dienste von entfernten
Rechner Hamachi und Tunngle überhaupt zugreifen sollen. Kannst du
das mal genauer erklären?

Das ist ja gerade der Punkt. Hamachi und Co. (und alle anderen VPN
Lösungen, egal ob open oder closed source) greifen auf überhaupt keine
Dienste von entfernten Rechnern zu. Sie schweißen nur die zwei Netze
zusammen.

Und dann kannst *du* *jede Art von Dienst* verwenden die normalerweise
nur in einem lokalen Netz möglich ist. Egal ob die Dienste tatsächlich
nur im lokalen Netz möglich sind oder üblicherweise aus
Sicherheitsgründen so konfiguriert werden, das sie nur vom lokalen Netz
aus verwendet werden können. Sprich: Freigaben von Netzwerklaufwerken
und Druckern in der Firma verwenden, oder umgekehrt, deinen Drucker
freigeben und einen Rechner in der Firma auf deinen Drucker ausgeben
lassen, Zugriff auf den firmeninternen SQL Server, Remote Desktop,
Zugriff auf externe Datenbanken die deiner Firma den Zugriff erlauben
(aber deinem Privatrechner natürlich nicht), usw. Und das alles kannst
du auf *jedem Rechner* innerhalb des externen Netzes machen in das du
dich per VPN eingeklinkt hast. Zumindest auf jedem Rechner auf den du
normal auch Zugriff hast, wenn du in der Firma sitzen würdest. Denn
dank des VPN bist du *Teil des internen Netzes*.

Oder (um zurück zum Thema der Newsgroup zu kommen) eine Runde Doom mit
ein paar Freunden spielen, welches ja schon so alt ist das es noch
weder Master Server zum verbinden von Spielwütigen, noch überhaupt das
TCP/IP Protokoll unterstützt hat. Doom unterstützt nur lokale Netzwerke
mit IPX Protokoll (das alte Novell Netzwerkprotokoll).

Also installiert man eine VPN Lösung wie z.B. Hamachi, installiert das
IPX Netzwerkprotokoll (falls es noch nicht installiert ist) und bindet
es an den Hamachi Netzwerkadapter und schließt dann per Hamachi den
eigenen Rechner mit denen von mehreren Freunden *die alle zu Hause an
ihrem eigenen Rechner sitzen* zu einem VPN (also einem virtuellen
lokalen Netz) zusammen. Und schon kann's losgehen, denn aus der Sicht
von Doom gibt es jetzt mehrere Rechner in einem lokalen Netz auf denen
das Spiel läuft.

Und das das tatsächlich funktioniert ist keine Theorie sondern gelebte
Praxis. Mit Doom hab ich das zwar noch nicht gemacht (das Spiel is ja
schon etwas alt), aber ich spiele ziemlich regelmäßig Battle for Middle
Earth über Hamachi. Das ist zwar neu genug das es Master Server zum
Vermitteln von Spielern kennt, aber die hat EA, die Firma mit dem
schlechtesten Kundenservice überhaupt, bereits ca. 2 Jahre nach Release
der Spiele abgedreht! :-( Und die einzig andere Option die bleibt ist
spielen im lokalen Netz, die Möglichkeit eine IP einzugeben mit der man
spielen möchte kennt das Spiel nicht. Und da kommt eben Hamachi ins
Spiel.

Ist das VPN-Protokoll nicht etwas anfälliger was die
Datensicherheit betrifft und ist es wirklich sinnvoll VPN für
Firmennetze zu verwenden oder eher fahrlässig und ist hier SSH
nicht um einiges sicherer?

Es ist nicht anfälliger und ja, es ist sinnvoll. Und nein, SSH
wäre nicht sicherer.

Ich lese gerade auf:
http://www.heise.de/security/VPN-Knigge--/artikel/71967/6

"Der Advanced Encryption Standard (AES) ist der
Nachfolgeverschlüsselungsstandard von DES (Data Encryption System).
3DES mit 128 Bit gilt zwar immer noch als sicher, ist aber wegen der
Dreifachverschlüsselung um Faktoren langsamer als AES. AES
unterstützt 128, 192 und 256 Bit lange Schlüssel."

Aber mit "ssh-keygen -b 2048 -t rsa" wird ein SSH Schlüssel mit 2048
bit nach dem Verschlüsselungsverfahren RSA erzeugt.

Wie kannst du also behaupten SSH(mit 2048 Bit Schlüssellänge) wäre
nicht sicherer als VPN(mit 256 Bit Schlüssellänge)?

Uh, oh, das war jetzt aber eine gesunde Portion Halbwissen. :-)

Dirk, alles was jetzt folgt ist speziell für dich. Alle anderen denen
die technischen Hintergründe piepegal sind, bitte weiterblättern, es
gibt nichts mehr zu sehen. Wer zumindest ein wenig Interesse an der
Technik hat die dahintersteht ist herzlich eingeladen weiterzulesen.
Ich versuche mich mit zu vielen Details zurückzuhalten.

Also, Dirk, du vergleichst hier gerade Äpfel (symmetrische
Verschlüsselung, das heißt der Key zum Verschlüsseln und Entschlüsseln
ist ident, wie z.B. bei AES) mit Birnen (asymmetrische Verschlüsselung,
die zwei Keys sind unterschiedlich, häufig als Public Key (zum
Verschlüsseln und Signatur prüfen) und Secret Key (zum Entschlüsseln
und Signieren) bezeichnet, wie z.B. bei RSA).

Diese zwei Klassen von Verschlüsselungsverfahren haben jede ihre
eigenen Vor- und Nachteile.

Symmetrische Verschlüsselung:

Vorteile:
*) Vergleichsweise geringer Rechenaufwand (da symmetrische Verfahren
eine geringere Komplexität haben)
*) Hohe kryptographische Sicherheit (Das heißt, man braucht Keys mit
geringerer Länge als bei asymmetrischen Verfahren um die selbe
Sicherheit gegen Kryptoanalyse zu erreichen.).
*) Aus den letzten beiden Punkten (weniger komplexe Mathematik mit
geringeren Schlüssellängen bei der selben Sicherheit) folgt: Die
Berechnungen gehen im Vergleich zur asymmetischen Verschlüsselung sehr
schnell und mit wenig CPU Aufwand.

Nachteile:
*) Wer eine Verbindung bereits bei der Verbindungsaufnahme abhört
bekommt den Schlüssel mit und kann daher die gesamte Verbindung trivial
entschlüsseln.
*) Eine Identifizierung findet nicht statt, das heißt sie ist anfällig
für Man in the Middle Attacken.


Asymmetrische Verschlüsselung:

Vorteile:
*) Die Identifizierung ist gesichert. Nimmt man mit einem Server
Verbindung mit Hilfe seines Public Keys auf (der aber aus einer
zuverlässigen Quelle stammen muß!), kann das nur der Server mit dem
zugehörigen Secret Key entschlüsseln. Man in the Middle Attacken kann
man daher (nahezu) ausschließen.
*) Betreits die Verbindungsaufnahme ist (mit dem Public Key)
verschlüsselt und nur der richtige Server kann das entschlüsseln. Ein
triviales Entschlüsseln der Verbindung ist daher nicht möglich, selbst
wenn man die Verbindung von Anfang an belauscht.

Nachteile:
*) Hoher Rechenaufwand (Die Mathematik hinter asymmetrischer
Verschlüsselung ist sehr komplex. Nein, ich werde jetzt nicht beginnen
über Mathematik in Restklassenringen modulo extrem hoher Primzahlen zu
referieren, wie sie in RSA verwendet wird. ;-) )
*) Geringere kryptografische Sicherheit (Man benötigt viel längere
Schlüssel um die selbe Sicherheit gegen Kryptoanalyse zu erreichen als
bei symmetrischer Verschlüsselung.)
*) Aus den letzten beiden Punkten (komplexe Mathematik mit größeren
Schlüssellängen) folgt: Die Berechnungen sind im Vergleich zur
symmetischen Verschlüsselung ziemlich langsam und benötigen einen hohen
CPU Aufwand.


Was wird daher in der Praxis gemacht? Man verbindet die Vorteile beider
Methoden und schaltet deren Nachteile aus, in dem man die erste
Verbindungsaufnahme mit asymmetrischer Verschlüsselung macht und macht
danach mit symmetrischer Verschlüsselung weiter.

Der Client nimmt mit Hilfe des Public Keys des Servers Verbindung mit
dem Server auf und schickt über die asymmtrisch verschlüsselte
Verbindung ein Passwort oder identifiziert sich ebenfalls mit Hilfe
eines Keys (falls der Server den Public Key des Clients kennt ist das
möglich). Die Identifizierung ist damit gesichert und niemand kann sich
als Mittelsmann zwischen Sender und Empfänger drängen. Auch Lauschen
nützt wenig.

Ist diese Phase abgeschlossen einigen sich der Client und der Server
darauf welche *symmetrische* Verschlüsselung sie weiterhin verwenden
wollen (z.B. AES), mit welcher Bitlänge (z.B. 128) und dann generiert
der Server einen zufälligen Key mit eben dieser Länge und teilt diesen
(über die immer noch asymmetrisch verschlüsselte Verbindung, damit
niemand mithören kann) dem Client mit. Danach wird auf der Verbindung
nur mehr symmetrisch verschlüsselt, mit eben jenem ausgemachten
Verfahren und dem zufälligen Key (das außer dem Server und dem Client
niemand kennen kann, er wurde ja verschlüsselt übertragen).

Geniale Idee, findest du nicht?


Und warum glaubst du habe ich geschrieben: "Was wird daher in der
Praxis gemacht?" ? Die Methode habe ich mir nicht aus den Fingern
gesaugt, sondern sie wird praktisch in allen Onlineverschlüsselungen
eingesetzt, ganz gleich ob bei SSL (Secure Socket Layer, wird gern auch
über Webbrowser eingesetzt, erkennbar am https:// statt http://), VPN
Verschlüsselung (die eh häufig auch über SSL oder IPSec gemacht wird)
*und natürlich auch bei SSH*. Dein 2KB langer RSA Schlüssel wird nur
für die Identifizierung und Ausmachung einer symmetrischen
Verschlüsselungsmethode, sowie Übertragung des Keys dafür verwendet.
*Danach geht es mit AES 128 Bit weiter*. Zumindest ist das die
Empfehlung des SSH Standards.

Möglich wären noch ein paar andere Verschlüsselungsverfahren. Außer AES
unterstützt SSH noch Twofish, Blowfish, Serpent, 3des, arcfour, idea
und cast, mit Keylängen von min. 128 Bit bis maximal 256 Bit, sowie
sogar *unverschlüsselte* Übertragung. Letzteres wird aber als "not
recommended" bezeichnet.

Alles nachzulesen in der SSH Spezifikation.
http://tools.ietf.org/html/rfc4253#section-6.3


Also, um mit deinen zwei großen Mißverständnissen in der Kryptographie
aufzuräumen:

*) Mehr Bits im Key heißt nicht automatisch mehr Sicherheit. Es hängt
davon ab um welche Klasse von Verfahren die Rede ist (asymmetrische
oder symmetrische Verschlüsselung) und von welchem Verfahren genau
(selbst innerhalb einer Klasse gibt es bessere, also sicherere, und
schlechtere Verfahren, die zumeist älter sind aber aus
Kompatibilitätsgründen noch unterstützt werden). Ein Vergleich zwischen
verschiedenen Verfahren oder gar zwischen Verfahren unterschiedlicher
Klassen ist für einen Normalsterblichen unmöglich, dazu bräuchte man
mehr als nur fortgeschrittene Kenntnisse in Mathematik und
Kryptographie auf Universitätslevel. Mit anderen Worten, das können nur
Kryptographieexperten. Du kannst also nicht einfach einen RSA 2048 Bit
Key mit einem AES 256 Bit Key rein anhand der Bitlänge vergleichen. Das
wäre Nonsens hoch 10.

*) Selbst dein heißgeliebtes SSH verwendet genau die selben
symmetrischen Verschlüsselungsverfahren wie sie auch zum Verschlüsseln
von VPN Verbindungen verwendet werden und kann daher auch gar nicht
sicherer sein als diese. Wie sollte es das auch sein, wenn beide auf
genau die selbe Art verschlüsseln?


So, das war's für's erste. Ich geh mir jetzt mal meine Fingerchen
kühlen, die ich mir wund geschrieben habe. ;-)

Ciao!
.

Relevant Pages

  • Re: [OT] VPN-Technologie
    ... das Hamachi und Tunngle auch mit SSH anstelle von VPN ... aber man greift auch *nur* auf den Rechner zu. ... bekommt den Schlüssel mit und kann daher die gesamte Verbindung trivial ...
    (de.rec.spiele.computer.action)
  • Re: Meldregister Panne: Welche Strafen sind zu erwarten?
    ... Ein Fehler der jeden WLAN Betreiber in den Knast bringen kann. ... Die Rechner waren weltweitfrei erreichbar. ... ein VPN ö.ae. war ... Verbindung und den Java-Sandkasten... ...
    (de.soc.datenschutz)
  • VPN zwischen Windows XP Clients
    ... Windows XP Rechner - jeweils hinter einem Linux NAT Router sollen sich mit Boardmitteln gegenseitig via VPN verbinden können (1 Verbindung genügt, deswegen wird auch kein VPN Server aufgesetzt, weder auf einem der Linux Router, noch auf einem der Windows Clients) ...
    (microsoft.public.de.german.windowsxp.sonstiges)
  • Remote Desktop aus anderem Subnetz geht nicht
    ... mich per VPN ein erhalte ich eine Adresse aus einem anderen Subnetz ... dann erhalte ich keine Verbindung. ... Ich kann von meiner VPN IP aus auf andere Rechner per RDP ...
    (microsoft.public.de.german.windowsxp.networking)
  • VPn und routing problem
    ... ich habe ein problem mit meinen VPN Zugang. ... Die Verbindung wird immer ohne Probleme ... Zu hause habe ich den IP Kreis 192.168.20.0 mit Gateway 192.168.20.81 ... meinem Rechner zu einer die Dynamischen IP umsetzt wird zwar die VPN ...
    (microsoft.public.de.german.windowsxp.networking)