Arnis Parsovs is one of the most impactful independent researchers in the field of Estonian eID security. He has discovered and helped fix numerous vulnerabilities in the Estonian ID card system. It's reasonable to assume that similar issues still exist in other national eID implementations.
One of his latest published discoveries demonstrates how an attacker could log into any website protected with mutual TLS (mTLS) client certificate authentication. The vulnerability stemmed from a feature that allowed arbitrary digest values to be signed using ID card software. This mechanism was widely used as a fallback, browser-independent method for accessing ID card functionalities.
During the mTLS handshake, the smart card signs the TLS handshake bytes. The attack works as follows: if a victim attempts to log in to a malicious site, and that site presents the victim with a digest from a target site’s TLS handshake, the malicious site can obtain a valid signature. That signature can then be used to authenticate to the target site as the victim. A demonstration video of the vulnerability is available here:
https://www.youtube.com/embed/Qr638sbaZ_M
What to Keep in Mind About Mutual TLS Authentication
While client certificate authentication is relatively easy to implement, it requires a solid understanding of the underlying security implications. Developers must take several precautions to avoid introducing critical vulnerabilities:
- Always verify the certificate's validity and revocation status. Use CRLs or OCSP checks consistently.
- CRLs must be updated frequently, preferably several times a day.
- Periodically update CA certificates. National eID schemes may rotate root and intermediate certificates monthly.
- Be aware that ID card authentication signs the digest of the TLS handshake. The smart card generates the signature, and the web server (e.g., Apache or NGINX) validates it using OpenSSL. If valid, the server makes certificate data available to the application.
A common oversight is failing to check certificate validity. If CRLs or OCSP are not enforced, stolen or revoked cards may still be used to authenticate. The integrity of the system depends on strict and timely revocation checking.
TLS Session Caching and Its Implications
Because HTTP is stateless, web servers optimize performance by caching TLS sessions. In Apache, the default SSL session cache duration is typically 5 minutes. This means that once a user has authenticated with their ID card and PIN, any requests within the next 5 minutes may reuse the session without a new TLS handshake. This cached session includes the client certificate data.
If the session cache is not explicitly disabled, there’s a risk that someone could access the authenticated session without the card being in the reader and without needing to re-enter the PIN—especially if the user logs out but the session hasn’t expired yet.
Browser Caching Behavior
During ID card authentication, the browser first prompts the user to choose a certificate and then asks for the PIN code. Unlike PIN2 (used for digital signatures), the certificate policy for authentication allows PIN1 to be cached by the browser.
This means that if you log into a site once, the next login attempt to the same site might reuse the cached certificate and PIN without prompting the user again. If the same certificate is used across different sites, the browser may prompt for certificate selection but still use the cached PIN for authentication.
This introduces a serious risk: if the smart card is left in the reader and the computer is accessible, someone else could log into the user’s account without knowing the PIN. Simply logging out is not enough—physically removing the card is the only safe measure in shared environments.
