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:
Wer stunnel bis zur Version 3.* einsetzt, kann diesen Dienst wie folgt
starten:
stunnel -c -d 4711 -r mg.mud.de:4712
Wer stunnel ab Version 4.* einsetzt, der muss vorab eine kleine
Konfigurationsdatei mit ungefähr folgendem Inhalt anlegen:
--
; * 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.
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).
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:
--
Die Option verifyPeer 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).
[mg]
CApath = certs
CAfile = certs/trusted.pem
; Unter Windows muss man ggf auch einen kompletten Pfad angeben:
; CAfile = C:\Program Files (x86)\stunnel\certs\trusted.pem
verifyPeer = yes
checkHost = mg.mud.de
--
$ cat trusted.pem peer-mg.pem > mgchain.pem
und statt verifyPeer VerifyChain setzen.
--
[mg]
CApath = certs
CAfile = certs/mgchain.pem
verifyChain = 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.
Man kann clientseitig ebenfalls das KeepAlive (also eine Art Ping zum Erhalt der Verbindung, für manche Router notwendig) einschalten. Dazu muss man unter Linux unter den Global Options folgendes einfügen:
--
socket = r:SO_KEEPALIVE=yes
; Die Default-Werte unter Linux sind deutlich zu hoch
; Achtung: diese Parameter funktionieren unter Win nicht, s.u.
socket = r:TCP_KEEPIDLE=200
socket = r:TCP_KEEPINTVL=60
[mg]
[...]
--
Unter Windows kann man zwar KeepAlive für einen Socket mit dem ersten Parameter prinzipiell einschalten, allerdings ist (beim derzeitigen stunnel, Version 5.26) der Default-Wert nur global über die Registry veränderbar:
Dazu in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters einen Wert KeepAliveTime vom Typ REG_DWORD erstellen und mit einem sinnvollen Wert (Millisekunden) setzen. D.h. falls wirklich alle 60s ein KeepAlive notwendig ist: 60000. Das gilt dann natürlich für alle IPv4-TCP-Verbindungen des Rechners!
(Achtung: Unter Windows10 konnte ich keine Wirkung beobachten. Die Dokumentation der entsprechenden Werte gilt auch nur für ältere Versionen.)