Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
3
Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann
Ganz wie früher mit telnet *freu*


@Tom
Ich habe deinen Link aufgeruft und bin mit stunnel sehr.zufrieden
Alternativ könnte man auch stunnel verwenden (http://www.stunnel.org/)… Dann verbindet man sich mit telnet auf den stunnel-Port und stunnel übernimmt das den kryptografischen Rest.