Re: [OT] VPN-Technologie

Am Mon, 18 May 2009 18:45:42 +0200 schrieb Ano Nym:

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.

Sollte das nicht für Hamachi und Tunngle völlig ausreichen, oder was
fehlt noch?

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.

Na prima, dann verstehe ich nicht warum Hamchi und Tunngle sich nicht
ebenso mit SSH realisieren lassen.

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.

Hamachi und Tunngle brauchen aber keinerlei Dateifreigaben, oder ein
Remote-Zugriff um damit einen Lan-Spiele-Server über das Internet verbinden
zu können.

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*.

Alle diese Dinge kann man ebenso mit SSH machen.

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).

Ich sehe immer noch keinen Grund dafür warum Hamachi und Tunngle nicht
möglicherweise mit SSH zu realisieren wäre.

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 warum sollte es mit SSH nicht ebenso realisierbar sein?

Und das das tatsächlich funktioniert ist keine Theorie sondern gelebte
Praxis.

(Das ist mir nicht völlig fremd.)

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.

Du beschreibt hier leider nur mir bekannte Dinge und konntest mir leider
nicht erklären, warum sowas alles nicht mit SSH zu realisieren sein sollte.

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. :-)

Deswegen Frage ich ja auch.

Dirk, alles was jetzt folgt ist speziell für dich.

Ich fühle mich geehrt.

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.

Ah prima.

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).

OK, die Schlüssellänge kann man bei verschiedenen Verschlüsselung-
Verfahren also nicht miteineander vergeleichen um lediglich nur daraus
eine höhere Sicherheit abzuleiten, weil die Verfahren doch zu verschieden
sind.

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.

Mein Rechner ist wohl stark genug dafür.

Nein, ich werde jetzt nicht beginnen
über Mathematik in Restklassenringen modulo extrem hoher Primzahlen zu
referieren, wie sie in RSA verwendet wird. ;-) )

Gut, denn damit wäre ich vermutlich überfordert.

*) 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.

Einfach prima diese geballte Zusammenfassung der Vor- und Nachteile.

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.

Aha.

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?

Na klar das ist super.

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.

Achso, das wußte ich nicht.

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,

Das kommt mir bekannt vor.

sowie
sogar *unverschlüsselte* Übertragung. Letzteres wird aber als "not
recommended" bezeichnet.

Verständlich.

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

Da werde ich gleich mal reinschauen.

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).

Ich verstehe.

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.

Diese voreiligen Vergleiche lasse ich dann zukünftig doch lieber sein.

*) 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?

Das wußte ich nicht.

Aber wenn man den Sinn/Unsinn dabei einmal ausser Betracht läßt,
kann ich immer noch nicht erkennen warum es dann nicht möglich sein soll,
Hamachi/Tunngle mit einem SSH-ähnlichen Anbau zu versehen.

So, das war's für's erste.

Das hat mir schon enorm geholfen meine falschen Vermutungen als solche auch
zu erkennen, vielen herzlichen Dank.

Ich geh mir jetzt mal meine Fingerchen
kühlen, die ich mir wund geschrieben habe. ;-)

Oh, dann puste ich lieber gleich 3x mal.

Dirk
.

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. ... Hamachi und Co. (und alle anderen VPN ... bekommt den Schlüssel mit und kann daher die gesamte Verbindung trivial ...
    (de.rec.spiele.computer.action)
  • [XP Home SP2] Gedenkpause kurz nach Einwahl ins Internet
    ... Es geht um den Rechner eines Freundes. ... und anschließend zum Einspielen aller Updates war der Rechner per LAN ... Verbindung mit dem Internet, per Einwahl-Verbindung. ...
    (microsoft.public.de.german.windowsxp.networking)
  • Re: Fritz!Box Firewall
    ... sozusagen in Form eines Minikommunikationsprofils - ganz bewusst frei ... Wenn ich an einem Rechner sitze, der am LAN hängt und eine HTTP Anfrage ... Ein Anbieten eines Dienstes ist für mich, ... Programm versucht eine Verbindung von innen nach aussen aufzubauen. ...
    (de.comp.security.firewall)
  • Re: SSH-Zugriff von =?ISO-8859-1?Q?=22au=DFen=22?= auf Rechner hinter Router
    ... Rechner sieht man dann aber natürlich weiterhin den SSH-Server). ... Verbindungen aufzubauen - bzw. es nur zu versuchen, ... wird SSH für den klopfenden Rechner ... Verbindungsversuch auf Port 6680 schaltet SSH für den anfragenden ...
    (de.comp.sys.mac.internet)
  • Re: Rechner "schiesst" Router ab?
    ... Server, dann Windows Workstations, dann Windows 9X). ... die Verbindung zum Switch (der ja durchaus hinter dem WLAN-Accesspoint ... Masterbrowser plötzlich weg und es wird eine neue Auswahl erzwungen. ... > Rechner befinden sich in derselben Arbeitsgruppe. ...
    (microsoft.public.de.german.windowsxp.networking)