AI
The Protocol That Promised to Replace VPNs
OPC UA is an industrial automation protocol, about 15 years old, used with PLCs and SCADA systems that control pipelines, solar parks, gas turbines, and similar physical infrastructure. Unlike older serial or proprietary protocols, it is standardized and open-source. It includes transport encryption and authentication, which leads vendors and users to argue that OPC UA can cross trust boundaries without a VPN. That premise made it an interesting target because, rather than using TLS, the protocol implements its own cryptographic layer.
A Two-Phase Handshake Built on RSA
OPC UA separates communication into two handshakes. The first, the secure channel handshake, performs RSA-based key exchange using each party’s certificate to arrive at a symmetric session key. The second, the session handshake, runs inside that encrypted channel and handles authentication via a challenge-response: each side generates a random number and the other signs it with its RSA private key. Both phases are optional in terms of encryption and authentication mode. Clients and servers negotiate these settings during the handshake.
Signing Oracle: No Private Key Required
The session handshake signs a challenge concatenated with the peer’s certificate, identical in format regardless of direction. No metadata indicates message direction. This enables a signing oracle relay: claim to be Server B when connecting to Server A, forward Server A’s challenge to Server B, collect Server B’s signature, and present it back to Server A. Many implementations trust their own certificate by default, so the attacker can log in as the server itself, gaining maximum privileges via two parallel connections without the private key.
Breaking RSA with a 25-Year-Old Padding Attack
Attacking the TCP variant requires bypassing the secure channel, which uses RSA with deprecated PKCS#1 v1.5 padding. Bleichenbacher’s 1998 attack breaks this: send a manipulated ciphertext, observe whether the server accepts the padding, and use that one-bit signal to narrow down the plaintext over roughly one million queries. OPC UA amplifies the timing difference. Instead of encrypting a symmetric key, it encrypts message blocks directly in RSA ECB mode. Repeating the same ciphertext 100 times forces 100 RSA decryptions on valid padding, widening the timing gap to roughly 0.1 seconds.
Five of Seven Implementations Broken Out of the Box
Tervoort tested seven OPC UA implementations. Five were vulnerable to at least one attack variant, and four were vulnerable in their default configuration. Against a C-based server, the full Bleichenbacher attack takes 15 minutes. Slower implementations took up to 2 hours. Most produce no logs during the attack because the exploit happens before authenticated communication begins. After responsible disclosure to the OPC Foundation, which responded within two hours and held a meeting the same day, Siemens WinCC and other vendors confirmed they were affected.
Why Rolling Your Own Crypto Keeps Going Wrong
The root cause is rolling a custom crypto stack instead of using TLS. If you design a client-server protocol today, use TLS. For PKCS#1 specifically: treat the padding scheme as fundamentally broken and disable it, regardless of whether the deprecation notice cites SHA-1. For existing OPC UA deployments that cannot be patched quickly, apply network segmentation. If patching is possible, at minimum use IP allowlisting. Never expose an OPC UA server to arbitrary internet traffic. Tervoort published a tool to scan for both vulnerabilities against any compliant implementation.
Notable Quotes
you’ve got an authentication bypass where you’re logged in to server A as server A, which usually has maximum privileges. Tom Tervoort · ▶ 11:01
suddenly starts to sound pretty practical for a timing attack involving a million messages. Tom Tervoort · ▶ 25:57
very impressive actually my compliments to the OPC foundation that’s not how responsible disclosure usually goes in my in my experience Tom Tervoort · ▶ 29:23
I’m not going to design the crypto myself. I’m just going to use TLS. Tom Tervoort · ▶ 33:26
Key Takeaways
- OPC UA’s custom crypto layer has fundamental flaws; always use TLS for client-server protocols.
- Bleichenbacher’s 1998 PKCS#1 attack still works in OT environments; disable this padding scheme everywhere.
- Five of seven OPC UA implementations were vulnerable, including four in their default configuration.
About the Speaker(s)
Tom Tervoort is a Principal Security Specialist at Secura, based in the Netherlands. His research focuses on cryptographic protocol attacks and Windows Active Directory pentesting. He also develops cryptography and secure programming courses for software developers. In December 2020 he won a Pwnie award for Best Cryptographic Attack for discovering the Zerologon vulnerability. He has spoken at Black Hat USA 2021 and 2023, Black Hat Europe 2022, and ONE Conference 2021.