Zusammenfassung

  • wolfSSL 5.9.2 meldete eine hoch eingestufte Schwachstelle in RPK-fähigen Builds: Ein nicht ausgehandelter Raw Public Key konnte statt X.509 angenommen werden und die Kettenprüfung umgehen. Der Fix erwartet ohne ausdrückliche Alternative X.509 und verwirft Formabweichungen.
  • RFC 7250 definiert RPK als eigenständigen, ausdrücklich auszuhandelnden TLS-Zertifikatstyp mit genau einer DER-codierten SubjectPublicKeyInfo. Der Handshake kann den Besitz des privaten Schlüssels beweisen, nicht aber Aussteller, Identitätsnamen, Laufzeit oder Geschäftsrolle liefern.
  • Sichere Annahme braucht zwei getrennte Laufzeitbelege: Der RPK-Typ wurde tatsächlich gewählt, und eine aktuelle externe Instanz bindet diese SPKI an den vorgesehenen Host, Dienst, das Gerät oder die Rolle. Ein grüner Verbindungsstatus reicht nicht.

Ein gültiges Objekt aktivierte das falsche Verfahren

Die Release Notes von wolfSSL 5.9.2 beschreiben CVE-2026-55960 als High. War HAVE_RPK aktiviert, konnte ein Peer einen Rohschlüssel liefern, obwohl dieser Zertifikatstyp nicht ausgehandelt worden war. Weil der RPK-Pfad keine X.509-Kette vorfindet, führte er die für das erwartete Zertifikat vorgesehene Vertrauensprüfung nicht aus.

Der Umfang bleibt begrenzt. Im eigenständigen Standard-Build ist RPK aus, mit --enable-all aber enthalten. Die Quellen nennen weder Ausnutzung noch Anzahl betroffener Installationen oder eine vollständige Versionsspanne. Belastbar ist der Kontrollfehler: Die empfangene Darstellung durfte nachträglich das Prüfregime bestimmen.

Der Fix setzt die Reihenfolge zurück. Fehlt eine alternative Aushandlung, gilt X.509 als erwartet. Der Client vergleicht die empfangene Serverform mit der Auswahl; der Server prüft entsprechend das Client-Credential. Jede Abweichung, auch ein nicht ausgehandelter Rohschlüssel, endet mit UNSUPPORTED_CERTIFICATE. PR 10702 ergänzt Regressionstests für beide Rollen.

Das ist keine bloße Parserhärtung. Aus der Fähigkeit, SPKI zu lesen, folgt keine Befugnis, ihren Vertrauensweg zu wählen. Erst legt der Handshake den Vertrag fest; anschließend darf nur die passende Form in dessen Prüfer gelangen.

Was Raw Public Key genau bedeutet

RFC 7250 registriert Raw Public Key als CertificateType 2 und führt client_certificate_type sowie server_certificate_type ein. Endpunkte geben an, was sie liefern oder verarbeiten können; aus der Schnittmenge wird gewählt. Ohne gemeinsamen Typ darf die Implementierung nicht still improvisieren.

Nach der RPK-Auswahl enthält Certificate eine einzige DER-SubjectPublicKeyInfo: Algorithmuskennung, optionale Parameter und Schlüsselbits. Dieselbe Struktur steckt in X.509, jedoch ohne den übrigen signierten Zertifikatskörper.

TLS 1.3 behält das Modell. RFC 8446 enthält RawPublicKey(2) und erlaubt nach dessen Auswahl höchstens einen SPKI-Eintrag. Zugleich formuliert der Standard den Default: Der Typ muss X.509v3 sein, sofern nicht ausdrücklich etwas anderes ausgehandelt wurde.

Darum ist eine fehlende Kette im richtigen RPK-Pfad kein Fehler. Im X.509-Pfad ist eine syntaktisch korrekte SPKI aber kein Ersatz. Lesbarkeit und Zulässigkeit sind getrennte Eigenschaften.

Schlüsselbesitz ist noch kein Gerätename

CertificateVerify bindet die Signatur an den TLS-Transcript und belegt, dass der Peer den passenden privaten Schlüssel kontrolliert. Finished bestätigt den Handshake-Zustand. Damit steht eine starke, aber enge Aussage: Der Gegenüber besitzt diesen Schlüssel in dieser Verbindung.

RFC 5280 zeigt, welche Semantik nicht mitkommt. Die CA-Signatur bestätigt die Bindung von Schlüsselmaterial und Zertifikatssubjekt. Der signierte Körper trägt Aussteller, Subjekt, Seriennummer, Gültigkeitszeitraum und Erweiterungen. Auch X.509 muss durch Pfad-, Namens- und Policyprüfung wirksam werden und vergibt keine Anwendungsrechte automatisch. Die nackte SPKI transportiert diese signierten Aussagen jedoch gar nicht.

RFC 7250 verlangt deshalb eine Out-of-Band-Bindung zwischen Schlüssel und vorlegendem Subjekt sowie eine Statusprüfung dieser Bindung. Ein bei der Herstellung gespeicherter Fingerprint, ein TLSA-Eintrag oder ein beim Erstkontakt gemerkter Schlüssel ist nur zu einem Zeitpunkt richtig. Rotation, Kompromittierung, Neuzuordnung oder Stilllegung können ihn entwerten.

Das externe Register braucht Identität und Rolle, Host-/Dienstumfang, exakte SPKI, autorisierenden Eigentümer, Wirk- und Endzeit, Vorgänger und Nachfolger, Rücknahmestatus, Verteilpfad und Ablehnungsnachweise der alten Generation.

Bibliotheksfunktionen machen die externe Entscheidung sichtbar

wolfSSL verlangt explizite RPK-Aktivierung, Typpräferenzen und einen Callback, der den empfangenen Schlüssel außerhalb von TLS authentisiert. Das TLS-1.3-Beispiel mit GnuTLS stellt eine Verbindung her, meldet den Peer ohne diese Logik aber als nicht verifiziert. Interoperabilität und Identität sind zwei Ergebnisse.

GnuTLS kann gespeicherte Schlüssel nach Host und Dienst prüfen, „kein Eintrag“ von „Schlüssel abweichend“ unterscheiden, Ablaufzeiten verwenden und ein eigenes Backend anbinden. Die Dokumentation weist darauf hin, dass normale Zertifikatsprüfung ohne Zertifikatskörper nicht funktioniert; nötig ist ein externer Vergleich oder ein TOFU-artiges Kontinuitätsmodell.

Die API gibt dem Kontrollpunkt eine Form. Sie entscheidet nicht, wer den ersten Wert autorisiert, welches Update vertrauenswürdig ist, ob der Callback tatsächlich lief und welches Anwendungsrecht ein Treffer freischaltet.

DANE und Firmware verteilen Autorität auf unterschiedliche Uhren

DANE ist eine mögliche externe Instanz. RFC 6698 definiert DNSSEC-gesicherte TLSA-Zuordnungen und kann SPKI vollständig oder als Digest auswählen. Ein Dienstname lässt sich so außerhalb einer klassischen CA-Kette an Schlüsselmaterial binden.

Die Behauptung wirkt erst, wenn der Client DNSSEC validiert, Usage, Selector und Matching Type richtig interpretiert und das richtige Objekt vergleicht. Publikation ohne Konsument ist keine Annahmebefugnis.

RFC 7671 beschreibt Rotation als Folge verteilter Schritte: neue Zuordnung vorab veröffentlichen, alte Caches auslaufen lassen, zugehörigen Schlüssel oder das Zertifikat ausrollen und erst danach überholte Einträge entfernen. Währenddessen können verschiedene gültige Sichten bestehen.

Bei eingeschränkten Geräten ist die Uhr langsamer. RFC 7925 sieht die Vorabverteilung eines Peer-Schlüssels oder Hashes vor und beschreibt RPK als Mittelweg ohne vollen Zertifikats- und PKI-Aufwand. Ein langlebiges Gerät bleibt von sicherem Software-Update abhängig. Weniger Handshake-Bytes verlagern Lifecycle-Arbeit, sie beseitigen sie nicht.

Sieben Tatsachen statt eines Erfolgsbits

Eine belastbare Akte trennt konfigurierte Typen, angebotene Liste, Auswahl, empfangene Form, kryptografischen Besitznachweis, Quelle/Version/Frische der externen Bindung und die schließlich erlaubte Anwendungshandlung.

tls_success=true kann einen nicht ausgehandelten Rohschlüssel, einen alten Eintrag, einen nie ausgeführten Callback oder zu breite Rechte verbergen. Ein abgelehnter, mathematisch gültiger Schlüssel kann dagegen genau die sichere Reaktion sein.

Heng Lus Running-Code-Primat ordnet die Belege. RFC und IANA geben Bedeutung und Nummern, DNS oder Konfiguration veröffentlichen eine Bindung. Operative Autorität entsteht im laufenden Prozess, der den falschen Typ abweist, den aktuellen Eintrag prüft und Rechte begrenzt. Der wolfSSL-Patch änderte diesen ausführenden Einspruch.

Evidenzgrenzen

Belegt sind Fehlerart, Build-Bedingung und Reparatur. Nicht belegt sind Ausnutzung, Installationszahl oder vollständige Versionsspanne. Ebenso folgt nicht, dass RPK grundsätzlich schwächer als X.509 wäre.

In einer kontrollierten, aktualisierbaren Umgebung kann ausgehandeltes und geschützt gebundenes RPK angemessen sein. X.509 kann ebenfalls falsch validiert werden. Verboten sein muss der Wechsel: Eine Credential-Form darf nicht die Annahme der anderen erben und zugleich deren Regeln umgehen.

Sources