TLS Fehler in SVN
« | 16 Aug 2020 | »Wenn man nach einen Upgrade auf Debian 10 oder Ubuntu 20.04 folgenden Fehler vor die Füße geworfen bekommt
svn: E170013: Unable to connect to a repository at URL ‘https://…’
svn: E120171: Error running context: An error occurred during SSL communication
dann heißt es einmal: “Nicht aufregen und sehr viel tief durchatmen.”
Herr Gott noch mal, bin ich angefressen!
Da bemüht man sich redlich eine vollständige Linux
Build-Umgebung aufzubauen und am Ende hat man dann einen
SVN
TLS Fehler vor sich,
der alles wieder zunichte macht.
Das Problem diesmal: Der SVN Server ist ZU ALT und unterstützt nicht die neuesten SSL/TLS Technologien, womit die Kommunikation mit ihm immer fehlschlägt.
Downgrade oder downgrade?
Nachdem mir Spielereien mit Konfigurationen nicht geholfen haben, bleiben 2 Möglichkeiten:
- Man wechselt zu einem älteren Betriebssystem mit älteren SSL-Anforderungen.
- Man installiert ein älteres SSL-System auf dem neueren Betriebssystem.
Anfangs startete ich mit Punkt 2 und suchte nach Paketen mit OpenSSL
1.1.0 und 1.0.2. Doch deren Installation bewegten svn nicht dazu die ältere
Option zu nutzen.
Am Ende habe ich aufgegeben und den ersten Weg gewählt, weil das Setup von Debian 9 in einer VM auch nur 15 Minuten dauert und ich vorher schon Stunden mit Paket-Installationen verbraten hatte.
In sofern kann ich für Testzwecke und Build-Systeme diesen Weg empfehlen. Es ist nach meiner Erfahrung leichter ein älteres System mit neuen Compilern auszustatten, als ein neueres System mit älteren Sicherheits-Funktionen.
Wie es trotzdem funktionieren könnte
Ich habe diesen Weg zwar nicht weiter überprüft, aber vermute, dass man durch
das Kompilieren einer älteren OpenSSL Version und deren Installation
per make install Script gefolgt von ldconfig -v eine kompatiblere
SSL-Version verfügbar hätte.
Womöglich ist es auch noch erforderlich svn neu zu kompilieren, denn auch
dessen Sourcen sind im Netz zu finden.
Parallel habe ich einige Hinweise gefunden, die verlangten die Option
disable-tls1_1 aus den Build-Rules zu entfernen.
Bei den original Sourcen der Distribution hatte ich damit zwar keinen Erfolg
aber vielleicht wäre der Weg zum Ziel nicht mehr weit gewesen.
Fazit
Wie auch immer … ich hasse es, wertvolle Lebenszeit mit solchen dummen
Protokollspielereien zu vergeuden.
Viele Software-Features altern und werden standardmäßig deaktiviert.
Doch diese lassen sich per Kommandozeile meistens wiederbeleben.
Warum SSL hier eine Ausnahme macht, verstehe ich nicht. Hmm … gut, eigentlich verstehe ich es schon: Man möchte bewusst die alten SSL/TLS Standards aussterben lassen.
Aber im industriellen Bereich und leider auch an meinem Arbeitsplatz gehört das Arbeiten mit alten Systemen zum Alltag.
Und da sind solche “Störungen” eben kein Vergnügen.