Loose Options

We understand

Setting up SSL is not all that fun. It is not lost on anyone that setting up even a single web service with HTTPS involves setting up several certificates, reading boring cryptography documentation and dire warnings.

Despite that, all the security features in SSL are there for good reasons, and turning them off, even for development purposes, has led to even less fun than setting up SSL properly.

Please read this before turning anything off!

Man in the Middle attacks are well known

The information security community is very well aware of how insecure most internal networks are, and uses that to their advantage. A video discussing attacks detailed a wide range of possible attacks.

Man in the Middle attacks are common

The average company can expect to have seven or eight Man in the Middle attacks a year. In some cases, up to 300,000 users can be compromised over several months.

Attackers have a suite of tools that automatically exploit flaws

The days of the expert hacker are over. Most security professionals use automated linux environments such as Kali Linux to do penetration testing, packed with hundreds of tools to check for exploits. A video of Cain & Abel shows passwords being compromised in less than 20 seconds.

Hackers won’t bother to see whether something will “look encrypted” or not. Instead, they’ll set up a machine with a toolkit that will run through every possible exploit, and go out for coffee.

Security is increasingly important and public

More and more information flows through computers every day. The public and the media are taking increasing notice of the possibility that their private communications can be intercepted. Google, Facebook, Yahoo, and other leading companies have made secure communication a priority and have devoted millions to ensuring that data cannot be read.

Ethernet / Password protected WiFi does not provide a meaningful level of security.

A networking auditing tool such as a Wifi Pineapple costs around $100, picks up all traffic sent over a wifi network, and is so good at intercepting traffic that people have turned it on and started intercepting traffic accidentally.

Companies have been sued for inadequate security

PCI compliance is not the only thing that companies have to worry about. The FTC sued Fandango and Credit Karma on charges that they failed to securely transmit information, including credit card information.

Correctly configured HTTPS clients are important

Sensitive, company confidential information goes over web services. A paper discussing insecurities in WS clients was titled The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software, and lists poor default configuration and explicit disabling of security options as the primary reason for exposure. The WS client has been configured as much as possible to be secure by default, and there are example configurations provided for your benefit.

Mitigation

If you must turn on loose options, there are a couple of things you can do to minimize your exposure.

Custom Play WSClient: You can create a custom Play WSClient specifically for the server, using the WSConfigParser together with ConfigFactory.parseString, and ensure it is never used outside that context.

Environment Scoping: You can define environment variables in HOCON to ensure that any loose options are not hardcoded in configuration files, and therefore cannot escape an development environment.

Runtime / Deployment Checks: You can add code to your deployment scripts or program that checks that ssl-config.loose options are not enabled in a production environment. The runtime mode can be found in the Application.mode method.

Options

Finally, here are the options themselves.

Disabling Certificate Verification

If you’ve read the above and you still want to completely disable certificate verification, set the following;

ssl-config.loose.acceptAnyCertificate=true

With certificate verification completely disabled, you are vulnerable to attack from anyone on the network using a tool such as mitmproxy.

Disabling Weak Ciphers Checking

There are some ciphers which are known to have flaws, and are disabled in 1.7. WS will throw an exception if a weak cipher is found in the ssl-config.enabledCiphers list. If you specifically want a weak cipher, set this flag:

ssl-config.loose.allowWeakCiphers=true

With weak cipher checking disabled, you are vulnerable to attackers that use forged certificates, such as Flame.

Disabling Hostname Verification

If you want to disable hostname verification, you can set a loose flag:

ssl-config.loose.disableHostnameVerification=true

With hostname verification disabled, a DNS proxy such as dnschef can easily intercept communication.

Disabled Protocols

WS recognizes “SSLv3”, “SSLv2” and “SSLv2Hello” as weak protocols with a number of security issues, and will throw an exception if they are in the ssl-config.enabledProtocols list. Virtually all servers support TLSv1, so there is no advantage in using these older protocols.

If you specifically want a weak protocol, set the loose flag to disable the check:

ssl-config.loose.allowWeakProtocols=true

SSLv2 and SSLv2Hello (there is no v1) are obsolete and usage in the field is down to 25% on the public Internet. SSLv3 is known to have security issues compared to TLS. The only reason to turn this on is if you are connecting to a legacy server, but doing so does not make you vulnerable per se.