Sophos Connect: Warum Admins nicht Blogposts jagen sollten

Sophos Connect 2.5 MR1 für Windows ist verfügbar. Auf den ersten Blick wirkt das wie ein kleines Maintenance Release: ein paar behobene Client-Probleme, ein aktualisierter Drittanbieter-Baustein, Download über die Firewall oder direkt von Sophos.

Aber genau hier liegt mein Problem.

Sophos Connect ist kein nettes Hilfsprogramm für gelegentliche Bastelverbindungen. Der Client sitzt auf Windows-Endpoints, baut Remote-Access-VPNs auf und ist für viele Organisationen ein direkter Weg ins interne Netzwerk. Wenn so ein Sicherheitswerkzeug eine relevante kryptografische Bibliothek aktualisiert, sollte die Information nicht in einem Community-Blog versteckt wirken.

Noch störender: OpenSSL 3.3.7 wurde bereits am 7. April 2026 veröffentlicht. Sophos Connect 2.5 MR1 kam am 18. Juni 2026. Das sind gut zehn Wochen. Für eine normale Desktop-App wäre das vielleicht einfach ein späteres Wartungsupdate. Für einen VPN-Client mit kryptografischer Bibliothek fühlt sich diese Zeitspanne deutlich weniger angenehm an.

Soll der einzelne User wirklich Sophos-Blogs lesen, um zu merken, dass sein VPN-Client aktualisiert werden sollte? Soll jeder kleine IT-Admin den Community-Feed abonnieren und hoffen, dass er solche Releases rechtzeitig sieht? Bei einem Tool, das direkt mit Remote Access, Zertifikaten, Authentifizierung und Verschlüsselung zu tun hat, ist das aus meiner Sicht zu wenig.

Was Sophos Connect 2.5 MR1 ändert

Sophos hat Sophos Connect Client 2.5 MR1 für Windows am 18. Juni 2026 angekündigt. Laut Sophos handelt es sich um ein Maintenance Release, das mehrere von der Community gemeldete Probleme behebt.

Die wichtigste technische Änderung ist aber klar benannt:

• OpenSSL wurde auf Version 3.3.7 aktualisiert.

Diese Formulierung klingt klein. Operativ ist sie es nicht. Zwischen dem OpenSSL-Release vom 7. April und der Sophos-Connect-Version vom 18. Juni lagen mehr als zwei Monate. Man kann argumentieren, dass Sophos erst prüfen, integrieren, testen und paketieren muss. Das ist fair. Aber genau deshalb braucht es bei einem Security-Client gute Transparenz: Admins sollten nicht erst aus einem Blogpost ableiten müssen, dass eine Client-Komponente seit Wochen auf ein Security-Patch-Release wartet.

Zusätzlich nennt Sophos mehrere behobene Sophos-Connect-Issues:

• Der Client startete bei zusätzlichen Windows-Benutzern nicht automatisch, wenn er von einem anderen Benutzer installiert wurde.
• Bei SSO-Benutzern konnte der Client nach Internetunterbruch einen falschen VPN-Status anzeigen.
• Credential-Benutzer mit OTP wurden bei der Wiederverbindung unterschiedlich zur Login-Verifikation aufgefordert, je nachdem ob IPsec oder SSL VPN genutzt wurde.
• SSO-Benutzer konnten mit einer Provisioning-Datei keine SSL-VPN-Verbindung aufbauen, wenn Zertifikate Sonderzeichen enthielten.

Das sind keine kosmetischen Kleinigkeiten. Es sind typische Remote-Access-Themen: Startverhalten, Statusanzeige, SSO, OTP, Provisioning und Zertifikate. Also genau die Dinge, bei denen Helpdesk, Admins und Benutzer schnell im Nebel stehen, wenn etwas nicht sauber funktioniert.

Trotzdem ist OpenSSL 3.3.7 der Punkt, der dieses Release für mich besonders wichtig macht.

Warum OpenSSL 3.3.7 relevant ist

OpenSSL 3.3.7 wurde am 7. April 2026 als Security-Patch-Release veröffentlicht. OpenSSL selbst stuft die schwerste darin behobene Schwachstelle als Moderate ein. Das klingt nicht dramatisch. Es ist aber auch kein normales Bugfix-Update.

OpenSSL 3.3.7 behebt unter anderem:

• CVE-2026-31790: falsche Fehlerbehandlung bei RSA KEM RSASVE Encapsulation, wodurch unter bestimmten Bedingungen nicht initialisierte Speicherinhalte an einen bösartigen Peer gesendet werden könnten.
• CVE-2026-28387: ein potenzielles Use-after-free-Problem im DANE-Client-Code.
• CVE-2026-28388: eine mögliche NULL-Pointer-Dereferenz bei der Verarbeitung einer Delta-CRL.
• CVE-2026-28389 und CVE-2026-28390: mögliche NULL-Dereferenzen bei der Verarbeitung bestimmter CMS-EnvelopedData-Strukturen.
• CVE-2026-31789: ein Heap-Buffer-Overflow bei hexadezimaler Konvertierung auf 32-Bit-Plattformen.

Nicht jede dieser Schwachstellen ist automatisch in Sophos Connect praktisch ausnutzbar. Das ist wichtig. Man sollte aus einer OpenSSL-CVE-Liste nicht blind ableiten, dass jeder Client in jedem Szenario akut kompromittierbar ist.

Aber genau so falsch wäre die Gegenrichtung: “Moderate” oder “Low” heisst nicht “egal”.

OpenSSL ist eine Basiskomponente. Sie steckt in TLS, Zertifikatsprüfung, kryptografischen Operationen und vielen Programmen, die sichere Verbindungen aufbauen. Wenn ein VPN-Client diese Bibliothek mitbringt, gehört die Pflege dieser Bibliothek zum Sicherheitsmodell des Clients. Besonders dann, wenn der Client auf Notebooks läuft, die unterwegs sind, in fremden Netzen arbeiten und Verbindungen in interne Umgebungen aufbauen.

Warum SSL VPN hier trotzdem relevant ist

Ein weiterer Punkt stört mich an Sophos Connect schon länger: Der Client bringt OpenSSL für SSL VPN mit, egal ob ein Kunde SSL VPN tatsächlich nutzt oder nicht.

Viele Umgebungen setzen mittlerweile stärker auf IPsec. Gründe dafür gibt es genug: oft bessere Performance, klarere Integration in bestehende VPN-Designs und vor allem eine einfachere Verteilung über klassische Softwareverteilung, RMM, Intune oder andere Endpoint-Management-Werkzeuge. Gerade in Unternehmen will man nicht, dass Benutzer sich VPN-Installer manuell aus einem Portal ziehen. Man will ein Paket, eine Version, ein Rollout-Fenster und eine saubere Inventarisierung.

Wenn ein Kunde Sophos Connect aber nur für IPsec nutzt, ist OpenSSL für SSL VPN trotzdem Teil des installierten Clients. Das bedeutet nicht automatisch, dass jede OpenSSL-Schwachstelle in dieser Umgebung praktisch ausnutzbar ist. Aber es bedeutet: Die Bibliothek ist da, sie muss gepflegt werden, sie taucht in Inventar- und Schwachstellenscans auf, und sie erzeugt Patch-Arbeit.

Genau deshalb ist die Update-Logik so wichtig. Wenn ein Produkt Komponenten mitinstalliert, die nicht jeder Kunde aktiv verwendet, dann trägt der Hersteller eine besondere Verantwortung, diese Komponenten schnell und sichtbar zu pflegen. Sonst entsteht ein klassisches Enterprise-Problem: Ein Feature ist technisch vorhanden, wird fachlich nicht genutzt, muss aber trotzdem gepatcht und erklärt werden.

Warum ein eigenes Release dafür sinnvoll ist

Ich finde es richtig, dass Sophos dafür ein Maintenance Release herausbringt.

Ein VPN-Client ist nicht irgendeine Desktop-App. Er ist Teil der Zugriffskontrolle. Wenn dieser Client veraltete Krypto-Bibliotheken nutzt, entsteht ein Betriebsrisiko, auch wenn die konkrete Ausnutzbarkeit im Einzelfall geprüft werden muss.

Bei Security-Komponenten zählen drei Dinge:

• Komponentenpflege: Drittanbieter-Bibliotheken müssen zeitnah aktualisiert werden.
• Nachvollziehbarkeit: Admins müssen sehen können, welche Version ausgerollt ist.
• Verteilung: Der Patch muss zuverlässig auf den Endpoints ankommen.

Der erste Punkt ist hier erfüllt: Sophos aktualisiert OpenSSL. Der zweite Punkt ist immerhin teilweise erfüllt: Release Notes und Blogpost nennen die Version. Beim dritten Punkt wird es aus meiner Sicht spannend.

Sophos schreibt, dass der aktuelle Client-Installer über ein Up2Date-Paket auf SFOS-Firewalls verteilt wird und danach aus WebAdmin oder VPN-Portal heruntergeladen werden kann. Das ist nützlich, weil die Firewall damit zum lokalen Bezugspunkt für den Installer wird.

Aber das ist nicht dasselbe wie ein sauberer, sichtbarer Auto-Update-Prozess auf jedem Windows-Endpoint.

Wenn ein Benutzer den Client irgendwann installiert hat und danach nie wieder aktiv aktualisiert, ist die Firewall-seitige Verfügbarkeit des Installers nur die halbe Strecke. Irgendjemand muss den Rollout trotzdem auslösen, überwachen und abschliessen.

Der eigentliche Kritikpunkt: Sichtbarkeit

Meine Kritik richtet sich deshalb weniger gegen das Release selbst. Das Release ist sinnvoll.

Meine Kritik richtet sich gegen die Sichtbarkeit und Erwartungshaltung.

Ein modernes Security-Tool sollte aus meiner Sicht mindestens eine dieser Möglichkeiten bieten:

• eine klare Update-Benachrichtigung im Client,
• eine zentrale Sicht in Sophos Central oder auf der Firewall, welche Client-Versionen noch alt sind,
• einen offiziellen, gut dokumentierten Auto-Update-Mechanismus,
• oder wenigstens eine Admin-Warnung, wenn ein sicherheitsrelevanter Client-Stand veraltet ist.

Am liebsten wäre mir bei Sophos Connect ein optionaler, sauber steuerbarer Auto-Update-Mechanismus. Nicht heimlich, nicht unkontrolliert, nicht gegen Unternehmensrichtlinien. Aber so, dass ein Admin entscheiden kann: Sicherheitsrelevante Client-Updates dürfen automatisch oder zumindest halbautomatisch in definierten Gruppen ausgerollt werden. Kleine Teams hätten damit weniger blinde Flecken, grössere Teams könnten es in ihren Change-Prozess einbauen.

Vielleicht gibt es in einzelnen Umgebungen bereits Deployment-Wege über GPO, RMM, Intune oder Softwareverteilung. Natürlich. Gute Admins können das lösen. Aber das ändert nichts am Produktpunkt: Bei Remote-Access-Clients sollte der Hersteller die Update-Kommunikation nicht dem Zufall überlassen.

Gerade Sophos weiss doch, wie wichtig Update-Automatisierung ist. Bei Firewalls gibt es Pattern Updates, Hotfixes, Firmware-Hinweise und Central-Sichtbarkeit. Bei Endpoint-Produkten erwartet man sowieso automatische Aktualisierung. Warum fühlt sich ausgerechnet ein VPN-Client an manchen Stellen noch so manuell an?

Das ist kein Luxusproblem. Es ist genau der Bereich, in dem kleine Lücken lange liegen bleiben.

Was Admins jetzt tun sollten

Für Admins ist die praktische Konsequenz relativ klar.

Zuerst: Prüft, ob eure Sophos Firewall den neuen Sophos-Connect-Installer bereits erhalten hat. Sophos schreibt, dass der Installer über Up2Date-Pakete an SFOS-Firewalls verteilt wird und danach im WebAdmin oder VPN-Portal verfügbar ist.

Zweitens: Prüft eure installierten Sophos-Connect-Versionen auf den Windows-Clients. Wenn ihr kein zentrales Inventar habt, ist genau das der eigentliche Schmerzpunkt. Dann braucht ihr mindestens über RMM, Intune, GPO, Endpoint Management oder ein Script eine Übersicht.

Drittens: Testet den neuen Client nicht nur mit einem Standardbenutzer. Testet die realen Szenarien:

• SSL VPN mit Benutzername, Passwort und MFA
• IPsec mit OTP, falls genutzt
• Microsoft Entra ID SSO
• Provisioning-Dateien
• Zertifikate mit Sonderzeichen im Namen oder in relevanten Feldern
• Wiederverbindung nach Internetunterbruch
• mehrere Windows-Benutzer auf demselben Gerät, falls das bei euch vorkommt

Wenn ihr ausschliesslich IPsec verwendet, würde ich das Update trotzdem nicht ignorieren. Prüft dann besonders, ob der Client im Alltag sauber startet, ob Profile wie erwartet verteilt werden und ob euer Inventar die neue Version korrekt erkennt. OpenSSL ist in diesem Fall vielleicht nicht die aktiv genutzte VPN-Schiene, aber die Bibliothek ist trotzdem Bestandteil des installierten Clients.

Viertens: Rollt das Update geplant aus. Nicht als Panikaktion, aber auch nicht irgendwann. OpenSSL 3.3.7 ist ein Security-Patch-Release. Ein VPN-Client mit OpenSSL ist kein Kandidat für “machen wir beim nächsten Notebook-Wechsel”.

Fünftens: Kommuniziert es sauber. Benutzer müssen nicht wissen, was RSASVE, DANE oder CMS KeyAgreeRecipientInfo bedeutet. Sie müssen wissen, dass der VPN-Client aktualisiert wird, dass Verbindungen danach getestet werden sollen und wo sie sich melden, wenn SSO, OTP oder Provisioning nicht sauber funktionieren.

Was Sophos besser machen sollte

Ich wünsche mir bei Sophos Connect drei Dinge.

Erstens: eine eindeutige Client-interne Update-Information. Wenn ein neuer sicherheitsrelevanter Client verfügbar ist, sollte der Benutzer oder zumindest der lokale Admin das sehen. Noch besser wäre ein steuerbarer Auto-Update-Pfad für Umgebungen, die das bewusst zulassen.

Zweitens: eine zentrale Admin-Sicht. In Sophos Central oder auf der Firewall sollte erkennbar sein, welche Sophos-Connect-Versionen in einer Umgebung bekannt sind und welche veraltet sind. Wenn der Client nicht zentral verwaltet wird, wäre wenigstens eine klare Empfehlung für Inventarisierung und Rollout hilfreich.

Drittens: bessere Release-Kommunikation. Ein Community-Blogpost ist okay als Ankündigung. Aber für Security-relevante Client-Komponenten reicht “Blog lesen und Installer herunterladen” nicht als Betriebsmodell, schon gar nicht wenn die zugrunde liegende OpenSSL-Version bereits seit April verfügbar ist.

Ich will Sophos hier nicht schlechtreden. Im Gegenteil: Dass OpenSSL aktualisiert wird, ist positiv. Dass die Release Notes die Version nennen, ist positiv. Dass der Installer über die Firewall verteilt wird, ist praktisch.

Aber 2026 sollte ein Security-Hersteller bei Remote-Access-Clients mehr leisten.

Mein Fazit

Sophos Connect 2.5 MR1 ist kein glamouröses Release. Genau deshalb ist es interessant.

Es zeigt, wie Security-Betrieb wirklich aussieht: nicht nur grosse neue Features, sondern Komponentenpflege, kleine Client-Fixes, Zertifikatsdetails, SSO-Verhalten, OTP-Wiederverbindungen und die Frage, ob ein Update tatsächlich auf jedem Endpoint landet.

OpenSSL 3.3.7 ist ein Security-Patch-Release. Sophos tut gut daran, diese Version in Sophos Connect zu integrieren. Admins tun gut daran, das Update nicht zu ignorieren. Aber die Zeitspanne von April bis Juni ist lang genug, dass man nach der Update-Geschwindigkeit und der Sichtbarkeit fragen darf.

Zusätzlich bleibt der Architekturpunkt: Sophos Connect installiert SSL-VPN-Komponenten mit OpenSSL auch dann, wenn eine Umgebung hauptsächlich oder ausschliesslich IPsec nutzt. Das kann technisch sinnvoll sein, weil Sophos einen kombinierten Client bereitstellt. Operativ bedeutet es aber zusätzliche Verantwortung. Was mitinstalliert wird, muss auch zuverlässig aktualisiert werden.

Aber Sophos sollte sich die unbequeme Frage gefallen lassen: Warum muss ein Admin bei einem VPN-Client überhaupt aktiv einem Blogpost folgen, um so ein Update sauber mitzubekommen?

Bei einem Sicherheitstool, das den Zugang ins interne Netzwerk absichert, ist das zu wenig.

Bis zum nächsten Mal,
Euer Joe

FAQ