TLS-Gruppenvorgaben finden, die den Wechsel zu hybriden Standardeinstellungen verhindern

Ziel

Stand: 25. Oktober 2026. Einstellungen finden, die eine Anwendung auf eine ältere Auswahl von TLS-Schlüsselaustauschgruppen festlegen, anschliessend eine geprüfte Richtlinie wiederherstellen und die tatsächliche Aushandlung überprüfen. Die Standardeinstellungen der Laufzeitumgebung, Beschränkungen des Providers und anwendungsspezifische Vorgaben für den exakt eingesetzten Build erneut prüfen. Ein Bibliotheksupgrade ersetzt nicht zwangsläufig eine Gruppenliste, die der Aufrufer übergibt.

Voraussetzungen

Anwendungsquellcode, generierte Deployment-Konfiguration, Laufzeitargumente und eine autorisierte Testgegenstelle beschaffen. Festhalten, welche Bibliothek die Anwendung tatsächlich verwendet. Jede explizite Beschränkung als erforderliche Richtlinie, aktive Kompatibilitätsausnahme oder ungeklärte historische Einstellung einordnen. Eine erforderliche Beschränkung nicht allein deshalb entfernen, weil sich die Standardeinstellungen geändert haben.

Schritte

1. Anwendungs- und Deployment-Verzeichnisse einschliesslich Vorlagen und Startskripten durchsuchen. Zum Beispiel:

   rg -n -e 'CurvePreferences|tlsmlkem|jdk[.]tls[.]namedGroups|setNamedGroups' \
     -e 'ssl_ecdh_curve|ssl_conf_command|SSL_CTX_set1_groups|SSL_set1_groups' .
   

   Die tatsächlich geladene OpenSSL-Konfiguration separat auf Groups und dessen älteren Alias Curves prüfen. Für jede wirksame Abweichung von den Standardeinstellungen die zuständige Stelle und die Begründung festhalten; eine Suche im Quellcode allein kann Einstellungen nicht sichtbar machen, die erst beim Deployment eingebracht werden.

2. Laut den Versionshinweisen zu Go 1.24 ist X25519MLKEM768 aktiviert, wenn Config.CurvePreferences nil ist. Eine befüllte Liste bestimmt die zulässigen Austauschverfahren, während das Paket deren Reihenfolge intern festlegt. Eine unnötige Zuweisung entfernen, um die Standardeinstellungen wiederherzustellen, oder eine erforderliche Liste zulässiger Verfahren gezielt aktualisieren. Auf die dokumentierte Deaktivierung über GODEBUG=tlsmlkem=0 prüfen. Die Anwendung neu bauen und deployen, bevor das Ergebnis geprüft wird.

3. Für Java sowohl jdk.tls.namedGroups als auch Aufrufe von SSLParameters.setNamedGroups prüfen. Die Ankündigung von Oracle vom 17. Mai 2026 ordnet die Änderung JEP 527 in Early-Access-Builds von JDK 27 zu; der Leitfaden zu Java SE 27 dokumentiert X25519MLKEM768 als bevorzugten Standard. Das Entfernen veralteter Vorgaben auf der vorgesehenen Laufzeit testen. Die Verfügbarkeit von ML-KEM als kryptografischem Grundbaustein allein ist kein ausreichender Nachweis für eine TLS-Integration in einer anderen Java-Version oder einem anderen Provider.

4. Für nginx explizite Einstellungen von ssl_ecdh_curve mit dem dokumentierten Standard auto vergleichen, der die eingebaute Liste von OpenSSL verwendet. Auch geerbte Einstellungen und Vorgaben über ssl_conf_command prüfen. Die erforderliche Zertifikatskompatibilität erhalten: nginx weist darauf hin, dass eine explizite Liste die von ECDSA-Zertifikaten verwendeten Kurven enthalten muss. Die vollständige Konfiguration vor dem üblichen kontrollierten Neuladen validieren.

5. Bei Anwendungen, die die OpenSSL-Konfiguration verwenden, Groups/Curves und abweichende Vorgaben auf API-Ebene prüfen. Die dokumentierte Gruppenliste verwendet Doppelpunkte als Trennzeichen; die Java-Eigenschaft verwendet Kommas. Die Syntax eines Produkts nicht in ein anderes übernehmen. Vor dem Aktivieren bestätigen, dass die erforderliche Gruppe implementiert ist.

6. Neue Anwendungsverbindungen vor und nach der Änderung mit repräsentativen Gegenstellen vergleichen, die Hybridverfahren unterstützen, sowie mit weiterhin erforderlichen älteren Gegenstellen. Die ausgewählte Gruppe, das Authentifizierungsergebnis und etwaige Handshake-Fehler festhalten. Die nginx-Variable $ssl_curve meldet die ausgewählte Kurve, sofern das eingebundene OpenSSL dies unterstützt; $ssl_curves beschreibt die vom Client angebotene Liste und beantwortet eine andere Frage.

Erwartetes Ergebnis

Unnötige Festlegungen sind entfernt, für notwendige Beschränkungen sind Verantwortliche benannt, und beobachtete Verbindungen belegen die beabsichtigte Richtlinie. Zu den Konfigurationsänderungen gehören entsprechende Deployment-Änderungen und ein dokumentierter Rollback.

Grenzen und Prüfbasis

Dies ist ein auf Anbieterdokumentation gestützter Vorschlag für ein Auditverfahren; es werden keine Anwendungstests behauptet. Die Wiederherstellung der Standardeinstellungen ermöglicht die Aushandlung, ohne jeder Gegenstelle ein Hybridverfahren vorzuschreiben. Kompatibilitätsausnahmen sollten begrenzt und überprüfbar bleiben. Zertifikatsvalidierung oder andere Sicherheitsbeschränkungen nicht deaktivieren, um einen Handshake erfolgreich abzuschliessen.