So the weakdh.org article got some renewed press again, and it keeps coming up with this rather misleading paragraph:
We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break.
That’s a rather bold statement. How do the authors know the MODP groups of 66% of VPN servers? This is what they write in their research paper:
We measured how IPsec VPNs use Diffie-Hellman in practice by scanning a 1% random sample of the public IPv4 address space for IKEv1 and IKEv2 (the protocols used to initiate an IPsec VPN connection) in May 2015. We used the ZMap UDP probe module to measure support for Oakley Groups 1 and 2 (two popular 768- and 1024-bit, built-in groups) and which group servers prefer. To test support for individual groups, we offered only the single group in question. To detect default behavior, we offered servers a variety of DH groups, with the lowest priority groups being Oakley Groups 1 and 2.
The first problem is that the first packet exchange performs the DiffieHellman 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. Imagine the following configuration (in SWAN ipsec.conf syntax):
rightid="CN=knownweakdevice.com, O=OldVendor, C=CA"
When the weakdh people’s scanner showed up, it allowed the initial request/response packet to be 1024. But once it got further into the negotiation, if would authenticate and identify the remote peer, and refuse to establish the IKE connection with the modp1024 group for everyone except the one known buggy device. But since the scanner had no credentials, it never got that far. So this is a false positive. This is how freeswan and openswan worked, and how libreswan works. When it receives more information, it tries to switch connection to the best matching connection. Note that with only the above two configurations enabled, libreswan would immediately reject an incoming IKE exchange that tries to use modp768 or modp2048, since no loaded connection specifies that modp group. Note the default when not specifying an IKE line is modp2048 and modp1536 for IKEv2, and modp1536 and modp1024 for IKEv1. With a preference for the higher group.
This method of connection switching requires the IKE daemon to know or go through all the connections to look at the modp group. If I understood the strongswan implementation correctly, it does not even bother to reject the incoming request based on modp group. It will just answer whatever the modp group is on the first packet. Later on in the exchange, once it has committed to a specific configuration, it will check for the modp group and reject the connection. So that is false positive number two for the scanner.
The article continues:
Of the 80K hosts that responded with a valid IKE packet, 44.2% were willing to accept an offered proposal from at least one scan. The majority of the remaining hosts responded with a NO-PROPOSAL-CHOSEN message regardless of our proposal. Many of these may be site-to-site VPNs that reject our source address. We consider these hosts “unprofiled” and omit them from the results here.
Well, that means the authors just excluded all freeswan/openswan/libreswan servers that are configured to not allow modp1024 because that is exactly what they would return. Libreswan per default does not allow modp1024 in IKEv2, so this is a rather big false negative!
We found that 31.8% of IKEv1 and 19.7% of IKEv2 servers support Oakley Group 1 (768-bit)
In our sample of IKEv1 servers, 2.6% of profiled servers preferred the 768-bit Oakley Group 1
Now regardless of the strong connections the authors missed, they did find a large number of weak ones. There is no excuse whatsoever for an IKEv2 server to allow modp768 or modp1024. It’s even questionable to allow modp1536 because every IKEv2 implementation supports modp2048. The 31.8% of modp768 is also inexcusable. The freeswan/openswan implementations never supported modp768 unless you specifically recompiled it (and the distro versions never had it compiled in). libreswan removed the compile time option altogether. The modp1536 group made it into freeswan – and preferred over modp1024 – before the modp1536 group was actually standardized in an RFC! So unless you specifically configured any of the *swan IKE implementations to use these weak groups, and your remote clients didn’t start out with a weak group, you would be using modp1536. Even back in 1997. This has not been an IKE problem in opensource IKE software ever. But, there is a catch.
The insecure Cisco administrator
86.1% and 91.0% respectively supported Oakley Group 2 (1024-bit)
This statistic matches my 15 year experience with IKE very well. It is very unfortunate that administrators fear reconfiguring a Cisco’s IPsec configuration. As such, when you need to interop with a Cisco, the other party usually has a SOP document that tells them how to configure the Cisco for use with 3DES-SHA1 modp1024. You are lucky if you are not forced to use md5. This is not a technical problem – Cisco VPN Concentrators can do modp2048. It is the humans that are afraid to touch something they are not familiar with that works.
MODP groups in the near future
The ipsecme working group at the IETF is actually working right now to update the set of mandatory to implement algorithms. This also includes promoting new algorithms to SHOULD or MUST and demoting others to MAY or MUST NOT. But it will only do so for the IKEv2 protocol. Most vendors have locked their IKEv1 stacks and will not make any changes to it anymore. So IKEv1 will always stay using modp1024 and modp1536. So if you can, use IKEv2.
The 66% of VPN number is surely very wrong. Measuring that number is per definition impossible, due to the common implementations of IKE daemons that hide the acceptance and rejection of the modp groups from un-authenticated IKE clients. However, I do agree that there are too many old IKE servers deployed that need to have their configurations upgraded to allow stronger modp groups and stronger encryption protocols.
If you want to go beyond modp1536, you should really upgrade to IKEv2. You will also need to move to IKEv2 if you want to move from AES-SHA1 to AES_GCM (or soon chacha20poly1305). Any IKE implementation that does not support IKEv2 is not actively maintained and should not be used.
See also my earlier article weak DH and LogJam attack impact on IKE
UPDATE: A more detailed explanation of the NO_PROPOSAL_CHOSEN case
The way IKE is specified and the way it works in practice is slightly different. The theory of operation is that a client starts with a list of proposals, that can include multiple DH modp groups. But that initial packet already contains the KE payload for one of the DH modp groups. So the client might send a proposal set containing 1024 + 1536 + 2048, but it only sends one KE payload. That KE payload basically denotes the client’s default. In this example, that would be either 1024 or 1536 or 2048. If the server receives this KE + proposal, it needs to make a decision. If the KE modp group is acceptable, use that. If not, then look if the proposal contains any other modp groups it is willing to use. If it does, it should return INVALID_KE with a payload of the acceptable modp group to use. The client receiving this can then select the other modp group it is willing to use and start the IKE exchange from scratch with a new request. (It’s a little more complicated because this reply is unauthenticated, so the client might wait for a bit to see if a “real server” accepts its modp). In practise, this often does not work. For example iphone ios8/ios9 do not process INVALID_KE payloads at all, as they assume a single correct modp group is configured on both sides using their enrollment program. So in practise, the server will accept the client’s DH if it is one of its allowed groups. This can mean that even though client and server both can do a more secure DH group, they end up using the most commonly used shared group. This is usually 1536 or 1024 for IKEv1 and 2048 for IKEv2.
An additional issue with IKEv1 is that the first packet also contains the OAKLEY_AUTHENTICATION_METHOD. If this is mismatched (eg PSK vs RSA) the IKE server will also return NO_PROPOSAL_CHOSEN.
And both both IKEv1 and IKEv2, the initial packet contains encryption/integrity algorithms too. If these mismatch (eg AES vs 3DES or SHA1 vs MD5) then the IKE server will also return NO_PROPOSAL_CHOSEN.
You can test the NO_PROPOSAL_CHOSEN return directed at vpn.nohats.ca. It is configured to accept connections from anyone, but requires modp1536 for either IKEv1 or IKEv2, using X.509/RSA authentication. You can send it PSK requests for modp1024 and get NO_PROPOSAL_CHOSEN.
Hmmm. You say: “Well, that means the authors just excluded all freeswan/openswan/libreswan servers that are configured to not allow modp1024 because that is exactly what they would return.” To be clear, servers configured not to allow modp1024 would reply NO-PROPOSAL-CHOSEN even to IKE packets offering other, more secure groups first? Because if I’m reading the paper correctly, that’s the behaviour they saw.
See the updated note I added to the post that clarifies this aspect
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, 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 . More interestingly, we also checked the claimed statistics in  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 , 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/
Which vpn do you recommend ?
I am a core developer of libreswan