fbeta ePA3-Service-OpenSource
TLS Certificate Verification Universally Disabled
Every HTTPS connection to the ePA Aktensystem and Konnektor in fbeta's ePA3-Service passes verify=False, unconditional across all environments. A network-positioned attacker terminates the client's TLS with an arbitrary certificate; on the Konnektor session, the client also presents its mTLS smartcard credentials to whoever answers.
Description
verify=False appears in five locations in VAUProtokoll.py (lines 99, 202, 271, 431, 581) and once at the session level in Konnektor.py:44. A source comment explains the original intent (connecting to a self-signed development endpoint), but no conditional was ever added to gate the relaxation:
VAUProtokoll.py:98 (intent comment)
# Um ein VAU-Kanal zu https://epa-as-2.dev.epa4all.de/ aufzubauen muss verify auf False gesetzt werden, da es sich um ein self-signed Zertifikat handeltThe library supports EPA_ENVIRONMENT = "PROD" (constants.py:48-52) with no conditional TLS verification; verify=False applies everywhere, in every environment. IDP connections use bare requests.get(), which defaults to verify=True, so the relaxation is specific to the ePA and Konnektor connection paths.
Konnektor.py:44 (session-level relaxation)
self.session.verify = FalseOn the Konnektor session, the client authenticates itself via mTLS (self.session.cert = (self.cert, self.key)) but does not verify the Konnektor's identity. An attacker impersonating the Konnektor receives the client's mTLS certificate and harvests the resulting smartcard operations. On the ePA Aktensystem side, this finding is the transport-layer enabler for the fbeta: VAU Server Authentication Bypass via Circular Certificate Trust; together they leave no layer of server authentication on the patient-data channel.
Impact
- Any network-positioned attacker (ARP spoofing, DNS poisoning, rogue AP, BGP hijack) terminates the client's TLS to the ePA Aktensystem with an arbitrary certificate and intercepts all traffic. TI-as-a-Service deployments route ePA traffic over the public internet via TLS, the exact threat model
verify=Truedefends against. - On the Konnektor connection, the client presents its mTLS smartcard credentials to whoever answers. An attacker impersonating the Konnektor harvests those credentials and the smartcard operations that follow.
- Combined with the fbeta: VAU Server Authentication Bypass via Circular Certificate Trust, this finding removes the last layer of server authentication. A single MITM position then reads and modifies all inner ePA traffic.
Mitigation
Update fbeta ePA3-Service-OpenSource to 1.3.0 or later. The fix removes all verify=False instances and replaces them with proper CA bundles for the TI endpoints, restores Konnektor server verification with a trust store containing the Konnektor's CA, and makes TLS verification unconditional rather than gating it on EPA_ENVIRONMENT. For development against self-signed certificates, configure the development CA in the trust store rather than disabling verification.
Defender's Checklist
Update to fbeta ePA3-Service-OpenSource 1.3.0 or later.
All versions before 1.3.0 are affected. The fix lives in pull request #9.
Ship the TI PKI bundle with your deployment.
TI PKI root certificates are not in the standard system trust store. Source them from gemSpec_PKI's TI Root CA bundle and pin them on every ePA and Konnektor session.
Grep your fork for verify=False.
Run
grep -RIn 'verify=False\|session.verify\s*=\s*False' .against your own deployment of this library or any fork. Every hit on a production code path is a potential regression; gate development paths explicitly on a non-production environment flag, not by default-off.Validate Konnektor identity, not just your own.
mTLS is two-way; setting only the client side leaks credentials. The Konnektor session must
verify=a CA store that contains the Konnektor's certificate.
Severity Reasoning
References
How We Can Help
Who We Are
The security researchers behind this advisory.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec Researcher
I evaluate your SaMD with the same industry-defining security insight I contributed to the BAK MV for the revision of the B3S standard.
- PhD on Hospital Cybersecurity
- Critical vulnerabilities found in hospital systems
- Alumni of THB MedSec Research Group
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
As a former CTO and developer turned pentester, I work alongside your team to uncover vulnerabilities and find solutions that fit your architecture.
- 20+ years as CTO, 50M+ app downloads
- Architected and secured large-scale IoT fleets
- Certified Web Exploitation Specialist
- gematik Security Hero
Looking for a Penetration Test?
Machine Spirits specializes in security assessments for medical devices and healthcare IT. From MDR penetration testing to C5 cloud compliance, we help MedTech companies meet regulatory requirements.