TLS-Zertifikatsprüfung in Produktion deaktiviert

Beschreibung

private KonnektorConnectionFactory buildFactory(Config cfg) {
    return KonnektorConnectionFactoryBuilder.newBuilder()
        .clientKeys(cfg.clientKeys())
        .konnektorUri(cfg.konnektorUri())
        .proxyServer(cfg.proxyAddress(), cfg.proxyPort())
        .trustAllServers() // currently we don't validate the server's certificate
        .build();
}

public class NaiveTrustManager implements X509TrustManager {
  @Override
  public void checkServerTrusted(X509Certificate[] chain, String authType) {
      // we're naive, let's just trust everything
  }
}

Auswirkung

• Ein Angreifer im Netzwerksegment zwischen ePA-Dienst und Konnektor (dem LAN der Gesundheitseinrichtung, einem VPN-Transit-Hop oder TI-Netzwerkinfrastruktur) präsentiert ein selbstsigniertes Zertifikat für einen beliebigen Hostnamen; der Client akzeptiert es und die Verbindung kommt zustande.
• Der abgefangene SOAP-Austausch enthält Versichertenkennungen (KVNR), SMC-B-Kartenoperationen (Authentifizierung und Signatur), Dokumenteninhalte und Credential-Austausch. Der Angreifer kann all dies mitlesen und manipulieren.

Abhilfe

Aktualisieren Sie epa4all-client auf 1.2.2 oder höher. Der Fix ersetzt .trustAllServers() durch einen korrekt konfigurierten TrustManager, der das Zertifikat des Konnektors prüft, und entfernt den Hostname-Check-Override setDisableCNCheck(true). Das Konnektor-Zertifikat muss gegen den passenden Trust-Anchor (die CA des Konnektors, die betreiberspezifisch sein kann) bei aktivierter Hostname-Prüfung validiert werden; nicht allein auf den System-Standard-Truststore zurückfallen.

Checkliste für Betreiber

• epa4all-client auf 1.2.2 oder höher aktualisieren.

  Alle Versionen vor 1.2.2 sind betroffen. Der Fix ist Pull Request #36.

• Prüfen, dass trustAllServers() aus dem Produktionspfad entfernt ist.

  Stellen Sie sicher, dass der produktive Einstiegspunkt .trustAllServers() nicht mehr aufruft und kein NaiveTrustManager installiert wird. Die dahinterliegende Methode ist im Javadoc als nicht produktionstauglich markiert.

• Sicherstellen, dass die Hostname-Prüfung aktiv ist.

  Prüfen Sie, dass setDisableCNCheck(true) entfernt ist, sodass CN/SAN des Konnektor-Zertifikats dem erwarteten Hostnamen entsprechen müssen.

• Gegen den korrekten Trust-Anchor validieren.

  Das Konnektor-Zertifikat muss auf seine passende CA zurückführen. Binden Sie diesen Truststore an die Verbindung, statt die Prüfung zu deaktivieren; ein selbstsigniertes oder betreiberspezifisches Konnektor-Zertifikat wird mit einem dedizierten Truststore behandelt, nicht mit einem Trust-all-Manager.

Bewertung im Detail

Referenzen

• CVE-2026-45574 (NVD)
• GHSA-5hhf-xmfx-4vvr (Oviva)
• Oviva epa4all-client PR #36 (Fix)
• Oviva-epa4all-client-Repository
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests