2006-11-16 22:49:46 +01:00
|
|
|
[[Kategorie: SILC]]
|
|
|
|
|
|
|
|
== Einleitung ==
|
|
|
|
|
|
|
|
[[SILC]] hat ein paar gute Ideen, die aber zu stark nach dem NIH-Prinzip implementiert wurden.
|
2006-11-16 22:58:38 +01:00
|
|
|
SILC-ng stellt den Versuch da, ein SILC-ähnliches Protokoll zu schaffen, das auf Standards
|
2006-11-16 22:49:46 +01:00
|
|
|
wie SSL und XML basiert.
|
|
|
|
|
|
|
|
== Architektur ==
|
|
|
|
|
|
|
|
Ein Netzwerk besteht aus (beliebig vielen) Servern, von denen jeder ein X.509-Zertifikat besitzt,
|
|
|
|
das seinem FQDN entspricht. Alle Zertifikate sind von einer gemeinsamen CA unterschrieben.
|
|
|
|
|
|
|
|
Jeder Nutzer des Netzwerks hat eigenes X.509-Zertifikat, das ihn eindeutig innerhalb des
|
|
|
|
Netzwerks identifiziert. Es obliegt dem Administrator eines jeden Servers zu entscheiden, ob
|
|
|
|
die Zertifikate der Nutzer geprüft werden. Einem Nutzer werden, wenn er zu einem Server verbunden
|
|
|
|
ist, verschiedene administrative Rollen zugeordnet, von denen die niedrigste "User" ist. Der Server
|
|
|
|
teilt die Nutzer in die Rollen aufgrund ihrer Zertifikate ein. Die höchste Rolle auf einem Server ist
|
|
|
|
"Administrator". Der Administrator kann dem Server, wenn er wie ein normaler Nutzer verbunden ist,
|
|
|
|
Befehle erteilen.
|
|
|
|
|
|
|
|
== Netzwerk-Schicht ==
|
|
|
|
|
|
|
|
=== Server zu Server ===
|
|
|
|
|
|
|
|
Verbindungen zwischen Servern sind ''ad-hoc'', d.h. sie müssen nicht vorkonfiguriert werden. Teilt ein Administrator
|
|
|
|
einem Server (Server A) mit, dass er sich zu einem anderen (Server B) verbinden soll, stellt jener eine
|
|
|
|
SSL-gesicherte, verschlüsselte Verbindung zu B her. A prüft hierbei das Zertifikat von B und bittet B um eine
|
|
|
|
Server-zu-Server Verbindung. B prüft ebenfalls das Zertifikat von A und hinterlässt bei erfolgreicher Überprüfung
|
|
|
|
bei A einen Verbindungs-Cookie. Daraufhin baut B eine weitere Verbindung zu A auf, und zwar zu dem im Zertifikat enthaltenen
|
|
|
|
Common-Name. Ist dieser Verbindungsaufbau erfolgreich, inklusive einer weiteren Überprüfung der Zertifikate,
|
|
|
|
fragt B A über diesen Kanal nach dem Vorher abgelieferten Cookie. Ist dieser identisch mit dem auf dem ersten Kanal
|
|
|
|
übertragenen schließt B diese Verbindung und fährt auf der ersten, von A initiierten Verbindung mit der Kommunikation fort.
|
|
|
|
|
2006-11-16 22:58:38 +01:00
|
|
|
'''Optional:''' A und B merken sich jeweils den gegenüberliegenen Hostnamen (== Common-Name) und optional auch das Zertifikat, nach einem
|
2006-11-16 22:49:46 +01:00
|
|
|
Neustart eines der beiden Server, versucht dieser einen erneuten Verbindungsaufbau.
|
|
|
|
|
2006-11-16 22:58:38 +01:00
|
|
|
'''Optional:''' A und B teilen sich gegenseitig mit, mit welchen anderen Servern sie verbunden sind. Und stellen bei Bedarf weitere Verbindungen
|
2006-11-16 22:49:46 +01:00
|
|
|
zu diesen Servern her.
|
2006-11-16 22:58:38 +01:00
|
|
|
|
|
|
|
=== Client zu Server ===
|
|
|
|
|
|
|
|
Jeder Client muss zunächst das CA-Zertifikat besitzen, bevor er sich zu einem Server verbinden kann. Optional kann der Client dieses beim ersten
|
|
|
|
Verbindungsversuch zu einem Server (NB. diese Verbindung ist zwar verschlüsselt, aber ungesichert!) von diesem herunterladen. Dabei '''muss'''
|
|
|
|
das Client-Programm auf jeden Fall eine Meldung ausgeben, dass dieses Zertifikat ausführlich zu prüfen ist und andernfalls alle weiteren Verbindungen
|
|
|
|
in das Netzwerk als ungesichert betrachtet werden müssen. Mit dem CA-Zertifikat überprüft der Client das vom Server angebotene Zertifikat (dabei kann
|
|
|
|
auch der Common-Name überprüft werden, dies ist aber z.B. bei Round-Robin-Hostnamen nicht sinnvoll). Optional kann der Client dem Server sein eigenes
|
|
|
|
Zertifikat zur Überprüfung anbieten, wenn der Server dieses nicht sowieso verlangt.
|