Mal wieder Freitag und mal wieder ein Problem zum Thema Email. Mails kommen prinzipiell an, aber irgendwie nicht alle. Vermutlich gibt es ein Problem bei der verschlüsselten Übertragung. Das klingt nach einer netten, kleinen Abwechslung. Ich liebe Freitage! (mehr …)
Wer kennt das nicht? Irgendeine alte Software die betriebsnotwendig ist und schon seit geraumer Zeit keine Updates mehr bekommen hat. Und die dümpelt halt so vor sich hin. So lange alle Clients sich noch verbinden bzw. die Verbindungen zu anderen Servern aufgebaut werden können scheint ja alles wunderbar zu sein. Es scheint so. Bis irgendeiner meint seine TLS-Einstellungen zu aktualisieren...Und das ist gar nicht so unwahrscheinlich wenn man zum Beispiel den Empfehlungen des BSI folgen mag.Von SSL ist da schon lange keine Rede mehr und sogar TLSv1.1 fehlt neuerdings. Weitere Infos dazu siehe hier:
Besonders prekär ist es, wenn die Anwendung noch gegen openssl 0.9.x verlinkt ist. Damit geht maximal TLSv1.0. Ihr seht schon, das Unheil nimmt seinen Lauf sobald diese alte Software versucht verschlüsselte Verbindungen aufzubauen bzw. über verschlüsselte Verbindungen erreicht werden soll. Die Verbindung startet zwar, wird aber gleich wieder beendet. Meist sind die Fehlermeldungen im Log dazu wenig aussagekräftig.
Und wie kann man das lösen? Ein Update der Software wäre möglich. Nur gibt es leider viele Gründe warum dies noch nicht passiert ist bzw. die nächsten Tage ebenfalls nicht passieren wird. Sind wir ehrlich zueinander: Das Verständnis dafür mag sich als Admin in Grenzen halten. Dennoch kennen wir alle die Situation. Die gibt es oft. Zu oft. Mit zu vielen Gründen.
Also gut, das geht so nicht. Also was tun wenn guter Rat teuer ist? Es gibt da so ein altes Sprichwort: "Wenn der Prophet nicht zum Berg kommt, dann kommt halt der Berg zum Propheten" (frei nach Francis Bacon 1625). Ein Update der Software ist nicht möglich, die Sicherheitseinstellungen der gegenüber liegenden Seite wird man wohl kaum reduzieren wollen. Bleibt also der Weg durch die goldene Mitte: Ein Proxy muss her! Der macht aus Klartext aktuelle Verschlüsselung, aus zu alter Verschlüsselung aktuelle Verschlüsselung oder, und das soll es ebenfalls geben: Aus alter Verschlüsselung gar keine Verschlüsselung. Auch hierfür gibt es Fälle wo das völlig ausreichend ist.
Für solche Dinge nehme ich gerne stunnel (https://www.stunnel.org/). Der ist klein und schlank und läuft unter aller gängigen Unix/Linux Systemen als auch unter Windows. Das Tool gibt es bereits seit über 20 Jahren und wird immer noch aktiv entwickelt. Hut ab!
Ok, als ich das erste Mal mit stunnel zu tun hatte waren meine Beweggründe eher anders herum: Viele Webfrontends damals kannten noch gar keine Verschlüsselung. Also fix stunnel davor geschaltet und schon war die Seite via https anstatt http zu erreichen. Die Richtung ist aber genau genommen völlig egal - es gibt ein Grundprinzip welches man bei stunnel immer im Hinterkopf behalten muss: Auf der einen Seite ist verschlüsselt, auf der anderen Seite ist Klartext. Wer aus alter Verschlüsselung neue machen will braucht somit zwei stunnel: Einen der übers Netz alte Verschlüsselung an nimmt und Klartext nach localhost leitet. Auf localhost geht ein stunnel ran der Klartext nach aktueller Verschlüsselung umwandelt. Reicht eine der beiden Richtungen reicht logischerweise auch nur ein stunnel.
Kein Platz stunnel irgendwo mit drauf zu packen? stunnel kann zwar drauf funktioniert aber nicht wie erhofft da am Installationsort eine völlig veraltete openSSL Bibliothek installiert ist? Für sowas nehme ich ganz gerne alpine Linux. Klein, sehr, sehr schlank und bringt stunnel in den zusätzlichen Paketen mit. Egal ob als Mini-VM oder als Container: läuft 🙂
Infos zu alpine? Gibt es hier: https://alpinelinux.org/
Genug der großen Reden, ein paar Beispiele müssen her! Die Konfig ist simpel: Zuerst ein paar globale Einstellungen und im Anschluss daran die jeweiligen Proxys. Das Format sollte jedem bekannt sein: Ini lässt grüßen.
;debug = info ;foreground = yes ;options = -NO_SSLv3 sslVersion = all ciphers = ALL [stls2pop3] protocol = pop3 client = no accept = 10110 connect = pop.gehirn-mag.net:110 cert = /etc/stunnel/stunnel.pem
Im globalen Abschnitt kann z.B. stunnel dazu gebracht werden im Vordergrund zu starten. Perfekt für Diagnose. Ansonsten habe ich hier nur sichergestellt, dass alles was "alte" Verschlüsselung ist verbinden darf.
Zum Proxy stls2pop3 selbst: Mir ist einmal eine Software begegnet die konnte POP3 und POP3S. Ok, POP3S ist raus. Nur wurde bei POP3, sobald angeobten, STLS (STARTTLS) verwendet. Logisch, ohne Schalter zum abstellen. Versteht sich. Oder auch nicht.
client auf no gestellt, es sollen eingehende Verbindungen verschlüsselt angenommen werden. Das soll für den Moment reichen, mehr Wissen braucht es zum client Schalter im Moment noch gar nicht. Mit accept wird der Port auf 10110 gestellt. Und via connect wird angegeben wohin stunnel sich bei eingehenden Anfragen letztendlich verbinden soll. In dem Beispiel steht ein ganz normaler Server welcher via POP3 angesprochen werden soll. Nur Moment, damit das funktioniert muss man beachten, dass bei POP3 für STARTTLS nur die Kurzform STLS verwendet werden muss. Das sollte man wissen. Und somit sollte auch stunnel darüber Bescheid wissen. Deswegen noch fix protocol auf pop3 gestellt. In der manpage zu stunnel.conf sind die Protokolle aufgelistet welche stunnel versteht: Eine ordentliche Menge. Die manpage kann hier nachgelesen werden: https://www.stunnel.org/static/stunnel.html#SERVICE-LEVEL-OPTIONS. Im Bereich "Service Level Options" einfach mal nach "protocol" suchen. Infos zum POP3 Protokoll uns STLS: https://de.wikipedia.org/wiki/Post_Office_Protocol#Verschl%C3%BCsselung.
Zu guter Letzt: Das Zertifikat via cert: Bei vielen Distributionen wird beim installieren bereits ein passendes angelegt. Das Zertifikat fehlt oder soll durch ein anderes ersetzt werden? Siehe stunnel HowTo im Abschnitt "Generating the stunnel certificate and private key (pem)": https://www.stunnel.org/howto.html.
Jetzt noch in der Anwendung rasch angegeben, dass der zu erreichende POP3 Server unter der IP-Adresse xxx.xxx.xxx.xxx bzw. folgendem DNS-Namen ... auf Port 10110 erreichbar ist. Und sehe wie die Anwendung über das hoffnungslos veraltete POP3 STARTTLS wieder verbindet. Ok, im Klartext auf das Ziel. Mag Situationen geben wo das reicht. Falls nicht lies einfach im nächsten Abschnitt weiter. In dem wird durch einen zweiten Proxy die Verschlüsselung auf neu getrimmt.
So, ein Proxy reicht also nicht. Dann halt mit zwei: Aus https alt mach http Klartext welches nur über localhost sich verbindet. Und zwar auf einen zweiten Proxy welcher aus Klartext https neu macht.
;debug = info ;foreground = yes ;options = -NO_SSLv3 sslVersion = all ciphers = ALL [https_in] client = no accept = 10443 connect = localhost:54321 cert = /etc/stunnel/stunnel.pem [https_out] client = yes accept = localhost:54321 connect = www.gehirn-mag.net:443 cert = /etc/stunnel/stunnel.pem
Das Prinzip Konfig wie gehabt. Zuerst der Kopf und dann der erste Proxy. Hier mit dem Namen https_in. Wie in Lösung 1 beschrieben macht der aus https Klartext http. Und verbindet sich als Ziel auf localhost:54321. An der Adresse lauscht der zweite Proxy https_out. Ein Unterschied gibt es: Hier steht client auf yes. Bei yes geht stunnel der Annahme, dass das Verbindungsziel Verschlüsselung benötigt. Somit ist der eingehende Teil die Klartextseite. Bei no ist das gerade anders herum (siehe manpage). Der Rest, oh Wunder, ist wie gehabt und bereits bekannt.
Noch fix das Ziel in der Anwendung geändert auf die Adresse des Proxyservers mit Port 10443 und schon wird aus https ganz arg alt https ganz arg neu gemacht.
Und wieder mal die Welt gerettet. Dank einem kleinen, schlanken Tool. Das trotz seines Alters alles andere als ins Alter gekommen ist. Es ist kein Fehler in einem ruhigen Moment mal die Webseite und die Beispiele etwas genauer zu betrachten. So viele Dinge die man darüber hinaus mit stunnel noch machen kann. Es lohnt sich.
