Fewer IPsec VPN Connections at Risk from Weak Diffie-Hellman

A researcher challenges a conclusion in a recent academic paper on weak Diffie-Hellman implementations that claims 66 percent of IPsec VPN connections are at risk.

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).”

Suggested articles


  • Anonymous on

    We (Eyal Ronen and Adi Shamir) have been running multiple tests over the last few weeks in order to check the claims made in the Adrian et al paper[1], titled "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", and are in the final stages of writing a comprehensive report about our findings. In the specific case of IPSEC, we have independently reached essentially the same conclusions as in Wouters’ blog post (which had just been published at https://nohats.ca/wordpress/blog/2015/10/17/66-of-vpns-are-not-in-fact-broken/ , and reported in https://threatpost.com/fewer-ipsec-vpn-connections-at-risk-from-weak-diffie-hellman/115189/ , and in http://it.slashdot.org/story/15/10/29/2230233/fewer-ipsec-connections-at-risk-from-weak-diffie-hellman ), namely, that the success rate of a hypothetical NSA attack on this protocol would be much lower than the original estimate which appeared in [1]. More interestingly, we also checked the claimed statistics in [1] related to HTTPS connections (which was not checked by Wouters). These connections use the TLS protocol (or its predecessor SSL) to securely access http servers on the internet, and is of great interest to intelligence services since it protects access to search engines (such as GOOGLE), to email (such as GMAIL), to social networks (such as FACEBOOK), to financial information (such as CITIBANK and VISA) and to various services (such as ordering books on AMAZON or reserving airline tickets on EXPEDIA). In particular, we tested the percentage of all DH-based connections (which use all key sizes, including the safer groups with 1536 bit primes which presumably cannot be attacked by the NSA with a feasible preprocessing). Our methodology was to use OpenSSL version 1.0.1e-fips from 11 Feb 2013 in its standard configuration (the version installed on our cluster computer at the Weizmann Institute) in order to open a secure connection to every single site in the Alexa list of the top one million web sites, and to check if the server chose ECC, DH, RSA, or completely declined opening a secure connection. Since many sites declined an SSL connection attempt, we also tried to add either the "www." or "login." prefix to all the sites on the list. This slightly increased the number of successful connections, since some sites only encrypt the communication after you log in. Our full scan of all the top one million websites showed that DH-based connections were established to around 18.7% of the sites that accepted HTTPS. This is a slightly smaller percentage than the 23.9% described in [1], which refers to the fraction of HTTPS connections that use the ten most popular 1024-bit DH groups (note that this discrepancy could be due to natural trends in the use of cryptography on the internet, due to the time difference between the two scans). However, our main claim is that most of these 1000000 web sites have a relatively small amount of traffic and are of little interest to intelligence services, and thus this statistics is not the right one to use when trying to estimate the possible success rate of a hypothetical NSA attack. We thus compiled the fraction of DH-based connections among the attempted connections to the top k web sites for all values of k smaller than one million. For example, when we restrict our attention to the top 1000 web sites, the percentage of sites whose connection used a DH handshake drops to 4.5%, and if we consider only the top 100 web sites (which include most of the interesting sites mentioned above), the percentage drops to just 2%. In other words, the most popular web sites are the least likely to negotiate a DH handshake when the client is not actively modified or influenced by the NSA. It is interesting to note that some of the leaked Snowden documents support the conclusion that DH-handshakes are rarely seen by intelligence services. For example, consider the document at http://www.spiegel.de/media/media-35512.pdf made public in December 2014 whose title is "TLS trends at GHCQ”. It probably dates from the end of 2012, and explicitly states that at that time DH keys were used in only 5% of the TLS traffic they observed. While we have no information about whether the NSA is able to break a few 1024 bit DH keys with a truly massive preprocessing, we can safely conclude that even if they were successful in preprocessing all the DH groups ever used on the internet (of arbitrarily large sizes), they would be able to passively break only a few percent of the HTTPS connections that really interest them. We will publish a full description of our findings in the next few days at http://www.wisdom.weizmann.ac.il/~eyalro/

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.