When NSA gets you worrying
In a post on Wednesday, researchers Alex Halderman and Nadia Heninger presented compelling research suggesting that the NSA has developed the capability to decrypt a large number of HTTPS, SSH, and VPN connections using an attack on common implementations of the Diffie-Hellman key exchange algorithm with 1024-bit primes. Earlier in the year, they were part of a research group that published a study of the Logjam attack, which leveraged overlooked and outdated code to enforce « export-grade » (downgraded, 512-bit) parameters for Diffie-Hellman. By performing a cost analysis of the algorithm with stronger 1024-bit parameters and comparing that with what we know of the NSA « black budget » (and reading between the lines of several leaked documents about NSA interception capabilities) they concluded that it’s likely NSA has been breaking 1024-bit Diffie-Hellman for some time now.
The good news is, in the time since this research was originally published, the major browser vendors (IE, Chrome, and Firefox) have removed support for 512-bit Diffie-Hellman, addressing the biggest vulnerability. However, 1024-bit Diffie-Hellman remains supported for the forseeable future despite its vulnerability to NSA surveillance. In this post, we present some practical tips to protect yourself from the surveillance machine, whether you’re using a web browser, an SSH client, or VPN software.
Disclaimer: This is not a complete guide, and not all software is covered.
To make sure you’re using the strongest crypto, you have to look at the encryption algorithms (or cipher suites) that your browser supports. There’s an excellent tool, How’s My SSL?, that will test your browser’s cipher suite support. The relevant area of the page is the bottom, Given Cipher Suites. You want to make sure that you don’t see the text « _DHE_ » in the list of ciphersuites – although the Elliptic Curve variant of Diffie-Hellman, represented by suites with « _ECDHE_ » is okay. It is important to note that there is a trade-off here: removing your clients support for « _DHE_ » ciphers will eliminate the risk of this attack, but it may also remove Forward Secrecy support altogether for some sites. Here’s how to remove those « _DHE_ » cipher suites if you still have them:
(tested with 40.0.3)
Open a new tab, enter « about:config » into the location bar and hit the « Enter » key. If you get a warning page, click « I’ll be careful, I promise! » This will bring you to the Firefox configuration settings. In the search bar up top, type « .dhe_ » and hit the « Enter » key. This should result in two settings being displayed: « security.ssl3.dhe_rsa_aes_128_sha » and « security.ssl3.dhe_rsa_aes_256_sha ». Double-click both of them to change the value from « true » to « false ».
Now, if you refresh the How’s My SSL page, the « _DHE_ » ciphersuites should be gone!
After following these steps in the following operating systems, refresh the How’s My SSL page, the « _DHE_ » ciphersuites should be gone. Note that the hex values for the blacklist correspond to the TLS Cipher Suite Registry
(tested with 46.0.2490.71, OSX 10.10.5)
Open « automator » and double-click « Run Shell Script ». Replace the « cat » command with the following:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --cipher-suite-blacklist=0x0033,0x0039,0x009E,0xcc15
Save the application to your applications folder with whatever filename you like. In finder, you can drag the application to your dock and use that to launch Chrome without the vulnerable ciphers.
(tested with 46.0.2490.71, Windows 7)
Right-click the shortcut to your Chrome application, click « properties » and then add the following to the end of the « target »: « –cipher-suite-blacklist=0x0033,0x0039,0x009E,0xcc15 »
The target then should be similar to the following:
"C:Program Files (x86)GoogleChromeApplicationchrome.exe" --cipher-suite-blacklist=0x0033,0x0039,0x009E,0xcc15
From now on, open Chrome from this shortcut.
Tested with 46.0.2490.13, Ubuntu 14.04 LTS
Starting chrome from the command line with the following flag removes the undesired ciphers:
An excellent guide for hardening your SSH configuration was released after revelations that the NSA can sometimes decrypt SSH connections. The guide is available here.
Most VPN software supports the « .ovpn » file extension used by OpenVPN. Many VPN providers will also provide « .ovpn » files to connect using OpenVPN. You can query your OpenVPN client for the ciphers it supports with the following command:
This list should be ordered by strongest ciphers first. Recent versions of OpenVPN will have « ECDHE » support, but in order to connect your VPN provider has to support the desired cipher as well. Ciphers with just « DHE » can be vulnerable, however OpenVPN often has VPN servers generate their own primes, which mitigates the risk of the precompute attack. Edit your « .ovpn » file with a line containing the strongest ciphers and testing it against your VPN provider to see if it connects properly:
If it does not connect with strong ciphers, contact your VPN provider and request they update their servers to support the strongest ciphers available.
Update 10/16: Updating VPN section for relevance to VPN clients. Added a note on the trade-off of removing DHE ciphers from web browsers.
Source: Electronic Frontier Foundation