TLS-Zertifikatsprüfung deaktiviert

Beschreibung

sslContext.init(keyManagerFactory.getKeyManagers(), getFakeTrustManagers(), null);

System.setProperty("javax.xml.accessExternalDTD", "all");
System.setProperty("jdk.internal.httpclient.disableHostnameVerification", "true");

public static TrustManager[] getFakeTrustManagers() {
    return new TrustManager[] { new X509TrustManager() {
        @Override
        public void checkClientTrusted(X509Certificate[] chain, String authType)
            throws CertificateException {}
        @Override
        public void checkServerTrusted(X509Certificate[] chain, String authType)
            throws CertificateException {}
        @Override
        public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
    }};
}

Auswirkung

• Ein Angreifer im Netzwerkpfad zwischen epa4all und einem Backend (dem ePA-Aktensystem, dem IDP oder dem Konnektor) terminiert die TLS-Verbindung mit einem beliebigen Zertifikat, auch einem selbstsignierten, und leitet den Verkehr weiter. Die Verbindung kommt zustande, weil keine Zertifikats- oder Hostname-Prüfung sie ablehnt.
• Der abgefangene Verkehr enthält Versichertenkennungen, Dokumenteninhalte, IDP-Credential-Austausch und SMC-B-Kartenoperationen. Der Angreifer kann all dies mitlesen und verändern. Werden der IDP-Credential-Austausch oder die SMC-B-Operationen abgegriffen, reicht das über die zum Zeitpunkt verarbeitete Betroffene hinaus auf jede Betroffene, für die die abgefangene SMC-B-Karte tätig werden kann.
• Im produktiven Bereitstellungsmodell passt das Angreifermodell ins Praxisnetz: epa4all läuft als On-Premise-Container in einer Arztpraxis, ist aus dem lokalen Netz erreichbar und baut ausgehende Verbindungen zur gematik-Infrastruktur auf.

Abhilfe

Aktualisieren Sie auf einen Build vom 20.05.2026 oder später, der die Zertifikats- und Hostname-Prüfung wiederherstellt und die gematik TI-PKI über einen Telematik-TSL-basierten Keystore verankert. Für betroffene Builds existiert kein Workaround. Das alleinige Wiederherstellen des JVM-Standard-Truststores reicht jedoch nicht aus: Das ePA-Aktensystem, der VAU-Proxy und der IDP präsentieren Zertifikate, die in der gematik TI-PKI wurzeln (etwa GEM.RCA-X), die nicht in der Standard-Mozilla-Root-Liste enthalten ist. Eine Standard-Trust-Konfiguration würde öffentlich ausgestellte Zertifikate akzeptieren und dabei den legitimen gematik-Ursprung nicht authentifizieren; die Trust-Anchors müssen daher die veröffentlichten TI-PKI-Roots sein, bei aktivierter Hostname-Prüfung. Kombinieren Sie diesen Fix mit med-united: VAU-Server-Authentifizierungs-Bypass; beide sind erforderlich.

Checkliste für Betreiber

• Auf den Build vom 20.05.2026 oder später aktualisieren.

  Alle 1.0.0-SNAPSHOT-Builds vor diesem Datum sind betroffen. Der Fix stellt die Zertifikats- und Hostname-Prüfung wieder her und ergänzt den Telematik-TSL-Keystore.

• Prüfen, dass die Trust-Anchors die TI-PKI-Roots sind, nicht der System-Standard.

  Die gematik-Backends präsentieren Zertifikate, die in der TI-PKI wurzeln (GEM.RCA-X), die der Standard-JVM-/Mozilla-Truststore nicht enthält. Binden Sie einen dedizierten Truststore aus den veröffentlichten gematik-Root-CAs an den CXF-/WebClient-Transport für diese Hosts und lassen Sie die Hostname-Prüfung aktiviert.

• Sicherstellen, dass kein permissiver Hostname-Verifier verbleibt.

  Prüfen Sie, dass jdk.internal.httpclient.disableHostnameVerification, tlsParams.setDisableCNCheck(true) und jeder hostnameVerifier((h, s) -> true) aus dem Produktionspfad entfernt sind. Ein Truststore mit deaktivierter Hostname-Prüfung lässt sich weiterhin durch jedes Zertifikat umgehen, das auf einen vertrauenswürdigen Root zurückführt.

• Diesen Fix mit dem VAU-Server-Authentifizierungs-Fix kombinieren.

  TLS-Pinning authentifiziert den Transport, nicht die signierten öffentlichen Schlüssel des VAU-Servers. Beide Schichten müssen prüfen; siehe med-united: VAU-Server-Authentifizierungs-Bypass.

Bewertung im Detail

Referenzen

• GHSA-296w-v8f6-3rf7 (med-united)
• med-united-epa4all-Repository
• Verwandt: VAU-Server-Authentifizierungs-Bypass in epa4all
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests