Wer möchte, kann seine Kommunikation zwischen dem Morgengrauen und seinem Rechner verschlüsseln. Dazu bieten wir einen Dienst an, mittels dem die Datenpakete über eine durch SSL-verschlüsselte Verbindung zwischen Morgengrauen und Spieler hin und her geschickt werden.
Als Voraussetzung, um diesen Dienst nutzen zu können, muss man das Paket stunnel installieren. Dieses gibt es für Linux, FreeBSD und Windows:
Unter Linux und ähnlichen Betriebsystemen startet man stunnel wie folgt:
Vorab muss eine kleine Konfigurationsdatei mit ungefähr folgendem Inhalt
angelegt werden:
--
; * Global options
[...]
foreground = yes
[mg]
client = yes
connect = mg.mud.de:4712
accept = 127.0.0.1:4711
; accept = localhost:4711 // bindet auf IPv6 gern an ::1 anstatt 127.0.0.1
--
Dann lässt sich stunnel wie folgt starten:
stunnel <konfigurationsdatei>
Nach der Installation durch Aufruf des Installationsprogrammes (Version 4.*) muss man die Datei stunnel.conf editieren und folgende Zeilen hinzufügen:
--
[mg]
client = yes
connect = mg.mud.de:4712
accept = 127.0.0.1:4711
; accept = localhost:4711 // bindet auf IPv6 gern an ::1 anstatt 127.0.0.1
--
Dann lässt sich stunnel starten (man kann stunnel auch als "Dienst" einrichten, dies ist zur Funktionsfähigkeit aber nicht nötig). Nach dem Start erscheint ein Symbol in der Taskleiste, dort findet sich dann auch das Log.
Sobald der stunnel läuft, kann man sich im Morgengrauen beispielsweise
über Telnet anmelden:
telnet localhost 4711 oder
telnet 127.0.0.1 4711
Für andere Clients muss man dann entsprechend als Mud-Adresse "localhost" und als Port 4711 eintragen (Zmud, Putty, etc.)
Je nach Client kann es sein, dass die üblichen Skripte und Anpassungen nicht verfügbar sind, da der Client nun mit dem Mud auf localhost und nicht mehr auf mg.mud.de verbunden ist. Ggf. muss man also ein paar Anpassungen vornehmen (z.B. einen Link einfügen).
Kurzversion für Ungeduldige weiter unten.
Zuerst das Zertifikat von Morgengrauen besorgen und anschauen. Stunnel bietet dafür direkt "Save Peer Certificate" wenn man verbunden ist. Unter Windows muss man ggf Stunnel als Admin neu starten, da der Speicherort ausgerechnet im Programmverzeichnis liegt.
Man kann auch mit openssl das Zertifikat und ein paar Extrainformationen holen:
$ openssl s_client -showcerts -connect mg.mud.de:4712
CONNECTED(00000004)
depth=0 CN = mg.mud.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = mg.mud.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=mg.mud.de
i:/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
-----BEGIN CERTIFICATE-----
MIIHST [...]
-----END CERTIFICATE-----
[...]
Alles mit und zwischen BEGIN/END CERTIFICATE kann man kopieren und in eine Datei schreiben. Hier zB peer-mg.pem.
Oben deutet sich an den verify-Fehlern an, dass allein das Zertifikat von MG auf dem Testrechner nicht ausreicht.
Prüfen mit:
$ openssl verify peer-mg.pem
(Möglicherweise tritt der Fehler bei nicht auf, falls die
CACert-Zertifikate schon lokal installiert sind und mit -CApath angegeben
werden.)
peer-mg.pem: CN = mg.mud.de
error 20 at 0 depth lookup:unable to get local issuer certificate
Es fehlen konkret das Class 3 und Root-Zertifikat der Certification Authority,
hier von CACert. Einfach dort direkt in PEM-Format herunterladen und zusammen
in eine Datei packen:
$ cat root.crt class3.crt > trusted.pem
Falls man das MG-Zertifikat lokal noch hat, kann man jetzt noch einmal prüfen:
$ openssl.exe verify -CAfile trusted.pem peer-mg.pem
peer-mg.pem: OK
Diese Datei dann an entsprechenden Ort legen und in der stunnel-Konfigurationsdatei vermerken:
--
[mg]
CAfile = certs/trusted.pem
; Unter Windows ist der Basispfad der config-Ordner im stunnel
Programmverzeichnis.
; Möchte man einen anderen Pfad verwenden, muss man ggf auch einen kompletten Pfad angeben:
; CAfile = C:\Program Files (x86)\stunnel\certs\trusted.pem
verifyChain = yes
checkHost = mg.mud.de
--
Die Option verifyChain steht hier dafür, dass Zertifikate benötigt und verifiziert werden. Das MG-Zertifikat wird also vom Server gelesen und gegen die lokalen und vertrauten Zertifikate in trusted.pem geprüft. Damit schließen wir prinzipiell MITM-Attacken aus.
Mit checkHost grenzen wir die zu prüfenden Zertifikate weiter ein (das kann man mit checkIP noch weiter treiben, ab Version 5.15/openSSL 1.0.2 möglich).
Wenn aber die CA potentiell kompromittiert ist, kann man jede Verbindung gegen ein konkret vertrautes
MG-Zertifikat prüfen. Dazu das MG-Zertifikat (siehe oben, oder persönlich zum Server gehen)
in die Datei mit hinein legen:
$ cat trusted.pem peer-mg.pem > mgchain.pem
und statt verifyChain VerifyPeer setzen.
--
[mg]
CAfile = certs/mgchain.pem
verifyPeer = yes
;checkHost = mg.mud.de // (unnütz bei so genauem Zertifikatscheck)
--
Allerdings muss man sich jetzt nach jedem Wechsel (zB durch Expire) dieses Zertifikat auch neu holen, weil die Verbindung sofort abgebrochen wird. Die Prüfung mittels verifyChain und checkHost ist im Normalfall sicher genug und durch den geringeren Wartungsaufwand tauglicher im Alltag.