A challenge has been made against one of the conclusions in a potentially blockbuster academic paper on cryptographic weaknesses that may be the open door through which intelligence agencies are breaking encrypted connections.
The paper, “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice,” claims that a massively resourced agency such as the NSA could build enough custom hardware that would crack the prime number used to derive an encryption key. Once enough information is known about the prime, breaking Diffie-Hellman connections that use that same prime is relatively trivial.
In the paper, the team of 14 cryptographers and academics who wrote it claim that upwards of 66 percent of IPsec VPN connections can be passively decrypted in this manner.
Paul Wouters, a founding member and core developer of the Libreswan Project, as well as a Red Hat associate, said that researchers are jumping to a conclusion because of the way they scanned and tested VPN servers, and that the number is likely too high.
Wouters explained in a blog post and again to Threatpost that he found a number of issues that inflated the number vulnerable VPN connections.
From Wouters’ post:
“The first problem is that the first packet exchange performs the Diffie-Hellman and no IDs or credentials are sent. This means that the server in question does not yet know which configuration this connection maps to, unless it is limited by IP. If it is limited by IP, then their probe likely did not even solicit an answer because they came from the wrong IP – Cisco VPN servers tend to not give error messages and will just drop the packet. If the configuration is not limited by IP, because the connection supports roaming users, then the VPN server cannot yet reject the connection based on a weak MODP group.”
The researchers said in their paper that in May they scanned a 1 percent random sample of public IPv4 addresses for IKEv1 and IKEv2 (Internet Key Exchange), the protocols used to initiate IPsec VPN connections. More than 80,000 hosts responded with valid IKE packets, and 44 percent of those were accepting proposals to initiate connections, the paper said. Most of the remaining servers responded with no_proposal_chosen regardless of the proposal sent, and those were omitted in the results published in the paper. No_proposal_chosen indicates there is a mismatch of proposals happening during session negotiations.
Wouters said in his post that is problematic because some servers, such as Libreswan, Freeswan and Openswan, which are open source VPN implementations for Linux, for example, are configured to not allow such proposals. He called this portion of the results “a rather big false negative.”
“The problem is, they did not count the servers that replied with NO_PROPOSAL_CHOSEN, so those are not part of the 100 percent, but those would be the ones that did reject the weak DH groups,” Wouters told Threatpost. “The real problem is, you just cannot know the real configuration of a IPsec server without having credentials. So scanning the Internet for weak IPsec servers is always going to give really bad results.”
Alex Halderman, one of the researchers who wrote the paper, told Threatpost that Wouters’ argument illustrates the complexity involved in measuring IKE exchanges.
“We’re going to do additional measurements based on his feedback in order to tighten our estimates, but I don’t think anyone disputes that this problem affects a very large number of VPNs,” Halderman said.
Wouters, using his time as a Freeswan/Libreswan/Openswan developer for context, said it’s nearly impossible to know what it is indeed a large number of VPNs, or for that matter, how many people are running Freeswan et al.
“That’s the beauty of open source software. We know it must be in the millions. But even the oldest freeswan did not support DH 768 and supported both DH 1024 and DH 1536 with a preference for the latter,” Wouters said. “So unless the administrator explicitly configured it weaker, we will be using at least 1536. So I would say it’s hopefully in the single percentage digits.”
One of Halderman’s colleagues acknowledged some limitations of the research’s measurement methodology. The colleague said Wouters was correct in concluding that if a server required special extensions, it could not be profiled. Or, he said, if it conducted a stronger Phase 2 handshake, the scan would not be able to determine that.
“But because of the space constraints within the paper, we couldn’t describe the entire methodology, so he’s wrong on some points,” the colleague said. “We scanned with RSA and PSK [pre-shared key] scans (he assumes we only scan PSK).
“We scan in Main Mode to avoid the NO-PROPOSAL-CHOSEN vs. WRONG-KEX-GROUP question in IKEv1 (he assumes we scan in Aggressive Mode). If a server has multiple configurations including one with 1024-bit and one with stronger, we’ll likely profile it as 1024-support, but non-1024-prefer based on how the server implementation works (he assumes that we’ll always mark it as 1024-supported and 1024-preferred).”
