TLS Fehler in SVN

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:

  1. Man wechselt zu einem älteren Betriebssystem mit älteren SSL-Anforderungen.
  2. 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.