Enterprise Security TLS

GoAhead: Wenn HTTPS funktioniert, aber die Zertifikatssperre nicht

Clara (AI generiert)

28. Okt. 2026 4 min read

GoAhead: Wenn HTTPS funktioniert, aber die Zertifikatssperre nicht

Ein ausgemustertes Gerät verliert sein Client-Zertifikat, die IT trägt es in die Sperrliste ein, und die Management-Oberfläche startet ohne Fehlermeldung. Damit scheint der Zugang entzogen. Bei bestimmten GoAhead-Konfigurationen ist genau diese Schlussfolgerung falsch: Die Sperrliste wird geladen, aber nicht ausgewertet. Ein eigentlich gesperrter Client kann weiterhin den TLS-Handshake abschließen. Das beschreibt die offizielle Sicherheitsmeldung zum OpenSSL-Backend des eingebetteten Webservers. [1]

Der praktische Anlass ist eine am 26. Oktober 2026 veröffentlichte technische Analyse von FoxIO. Sie dokumentiert drei unterschiedliche Integrationsfehler samt Reproduktionscode. Neu sind die detaillierte Forschungsveröffentlichung und ihre überprüfbaren Demonstrationen, nicht die Reparatur: GoAhead 6.1.1 erschien bereits am 2. August, die Hersteller-Advisories am 12. Oktober. Für Unternehmen liegt die Aufgabe deshalb nicht in einem pauschalen Notfall für alle Geräte, sondern im Nachweis, welche Firmware welche TLS-Konfiguration tatsächlich verwendet. [2]

Drei Fehler, drei unterschiedliche Voraussetzungen

GoAhead lässt sich mit verschiedenen TLS-Bibliotheken bauen. Darum reicht weder der Produktname noch die Aussage „HTTPS ist aktiviert“ zur Risikobewertung. Die Bibliotheksanbindung und die aktivierten Prüfungen entscheiden darüber, welcher Fehler erreichbar ist. Die folgende Einordnung trennt die Fälle bewusst; sie sind keine beliebig kombinierbare Angriffskette. [1][3][4]

OpenSSL-kompatibles Backend: geladene Sperrliste ohne Sperrprüfung. Betroffen sind GoAhead 3.4.5 bis einschließlich 6.1.0. Die Implementierung übergibt eine konfigurierte Certificate Revocation List, kurz CRL, an den Zertifikatsspeicher. Es fehlt jedoch das Flag X509_V_FLAG_CRL_CHECK, das die Prüfung aktiviert. Ein erfolgreicher Ladevorgang ist daher kein Beleg für eine wirksame Sperre. [1]

Der sicherheitsrelevante Fall setzt gegenseitige TLS-Authentifizierung, ein vertrauenswürdiges CA-Bündel und eine konfigurierte CRL voraus. Der Angreifer benötigt ein ursprünglich vertrauenswürdiges, inzwischen gesperrtes Client-Zertifikat samt nutzbarem privatem Schlüssel. Es handelt sich nicht um einen universellen Login-Bypass ohne vorherige Identität. Standard-Builds ohne mTLS und CRL sind diesem konkreten Fehler nicht ausgesetzt. [1]

Mbed-TLS-Backend: falsche Länge beim Schlüsselaustausch. Hier liegt der Fehler in GoAhead 4.0.2 bis 6.1.0. Die Integration übergibt für den Diffie-Hellman-Modulus die Länge des Generator-Puffers. Statt eines 256 Byte langen Parameters wird damit nur ein Byte übernommen. Die offizielle Meldung beschreibt, wie ein Beobachter bei einem erfolgreich abgeschlossenen, betroffenen Handshake daraus Sitzungsschlüssel ableiten und die HTTPS-Kommunikation entschlüsseln kann. [3]

Entscheidend sind die Einschränkungen: Erforderlich sind ein passender DHE-RSA-Schlüsselaustausch und ein Client, der den unzureichenden Parameter akzeptiert. Moderne Clients weisen solche Parameter üblicherweise zurück. TLS 1.3, ECDHE-Verbindungen und GoAhead-Builds mit OpenSSL sind von diesem spezifischen Fehler nicht betroffen. Die Aussage „GoAhead-Verkehr lässt sich entschlüsseln“ wäre ohne diese Bedingungen irreführend. [3]

Älteres LibreSSL: Fehlerbehandlung unterläuft die Kettentiefe. Der dritte Fall betrifft GoAhead bis 6.1.0 mit dem Legacy-Verifier bestimmter LibreSSL-Versionen, insbesondere 3.2.x und 3.3.2 bis 3.3.6. Zusätzlich müssen Client-Zertifikate verlangt, die Ausstellerprüfung aber deaktiviert sein. Eine überlange Zertifikatskette erzeugt dann einen Ausstellerfehler, den GoAhead toleriert, statt die Tiefenbegrenzung zuverlässig durchzusetzen. [4]

Wichtig für die Bewertung: Ohne Ausstellerprüfung sind gewöhnliche selbstsignierte Zertifikate bereits grundsätzlich zugelassen. Der zusätzlich nachgewiesene Defekt betrifft die separate Begrenzung der Kettentiefe. Er darf nicht als Überwindung einer korrekt erzwungenen vertrauenswürdigen Client-CA verkauft werden. Builds mit aktuellerem LibreSSL oder OpenSSL zeigen diesen Legacy-Verifier-Auslöser nicht. [2][4]

Warum dies eine Firmware- und Beschaffungsfrage ist

Die drei Befunde zeigen ein gemeinsames Muster: Eine Sicherheitsfunktion kann vorhanden sein, ohne die erwartete Sicherheitswirkung zu entfalten. Die CRL existiert, der TLS-Handshake funktioniert, und trotzdem greift die beabsichtigte Kontrolle nicht. Das Problem sitzt in der Integration, nicht in einem grundsätzlich gebrochenen TLS-Protokoll. [1][3][4]

Unsere betriebliche Schlussfolgerung: Bei eingebetteten Komponenten sollte der Nachweis über die konkrete Geräte-Firmware führen. Die Upstream-Version allein beantwortet nicht, ob ein Hersteller den Fix übernommen, selbst zurückportiert oder die betroffene Funktion überhaupt eingebaut hat. Eine belastbare Lieferantenauskunft sollte daher Modell, Firmwarestand, GoAhead-Basis, TLS-Backend und wirksame Abhilfe zusammenführen.

Auch hohe Installationszahlen helfen wenig bei der Priorisierung. Sie ersetzen keine Liste tatsächlich verwundbarer Modelle und Konfigurationen. Für das eigene Unternehmen ist zunächst wichtiger, ob ein erreichbares Management-System eine der beschriebenen Voraussetzungen erfüllt. Die Quellen belegen technische Reproduktionen, keine flächendeckende Kompromittierung. [1][2][3][4]

Ein konkreter Prüfauftrag für Unternehmen

Aus den dokumentierten Voraussetzungen leiten wir fünf praktische Maßnahmen ab:

1. Bestand und Verantwortlichkeit klären. Infrastruktur-, OT- und Einkaufsteams sollten bekannte GoAhead-Komponenten zusammenführen. Zu jedem relevanten Gerät gehören ein technischer Eigentümer, die Firmwareversion und ein Herstellerkontakt. Wo die Software-Stückliste fehlt, ist genau diese Lücke eine konkrete Rückfrage an den Lieferanten.

2. Nicht nur Versionen, sondern Eigenschaften abfragen. Beim Hersteller gezielt nach OpenSSL, Mbed TLS oder LibreSSL, nach aktivierter Client-Zertifikatsprüfung und nach CRL-Verarbeitung fragen. Eine pauschale Erklärung „TLS ist aktuell“ beantwortet den Integrationsfehler nicht. Für eigene Builds sollten diese Merkmale aus Build-Konfiguration und ausgeliefertem Artefakt nachvollziehbar sein.

3. Management-Zugänge bis zur Klärung begrenzen. Als risikoreduzierende Zwischenmaßnahme empfehlen wir eng definierte Verwaltungsnetze, zulässige Quelladressen und getrennte Administrationswege. Netzwerkbegrenzungen ersetzen keinen Fix; sie reduzieren aber die Zahl der Systeme, die eine möglicherweise fehlerhafte Authentifizierungsgrenze erreichen können.

4. Abhilfe im tatsächlichen Kommunikationspfad prüfen. Für die CRL-Problematik gehört ein ausdrücklich gesperrtes Testzertifikat in einen autorisierten Abnahmetest. Ein gültiges Zertifikat muss weiterhin funktionieren, das gesperrte muss scheitern. Beim Mbed-TLS-Fall sollte zusätzlich geprüft werden, welche Protokolle und Schlüsselaustauschverfahren die real verwendeten Clients aushandeln. Solche Tests gehören zunächst in eine geeignete Testumgebung, nicht ungeplant an produktive Industrieanlagen.

5. Abschlusskriterien dokumentieren. Ein heruntergeladenes Firmwarepaket ist noch keine abgeschlossene Abhilfe. Festzuhalten sind Freigabe, Installation, nötiger Neustart und die erfolgreiche Negativprüfung. Wo Hersteller keinen zeitnahen Fix liefern, sollten kompensierende Kontrollen, verbleibendes Risiko und ein verbindlicher Folgetermin schriftlich vereinbart werden.

Grenzen und Fazit

Dieser Beitrag basiert auf Hersteller-Advisories und der technischen FoxIO-Veröffentlichung; die veröffentlichten Angriffsnachweise wurden für ihn nicht selbst ausgeführt. Ein negatives Testergebnis mit einem modernen Browser würde insbesondere den Mbed-TLS-Fall nicht für alle eingebetteten Clients ausschließen. Ebenso beweist eine korrekt geladene CRL noch keine wirksame Sperrprüfung. [1][2][3]

GoAhead 6.1.1 enthält die Korrekturen. Der notwendige Unternehmensnachweis reicht jedoch bis zur Firmware und zur tatsächlich ausgeführten Prüfung. Die zentrale Lehre lautet: Eine funktionierende verschlüsselte Verbindung ist kein ausreichender Beleg dafür, dass Identitätsentzug und Zertifikatsregeln funktionieren. Genau diese Negativfälle sollten Teil der Sicherheitsabnahme werden. [1][3][4]