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.
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.
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.
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.
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.
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.
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.
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
Finally, here are the options themselves.
In most cases, people turn off certificate verification because they haven’t generated certificates. There are other options besides disabling certificate verification.
- Quick Start to WS SSL shows how to connect directly to a server using a self signed certificate.
- Generating X.509 Certificates lists a number of GUI applications that will generate certificates for you.
- Example Configurations shows complete configuration of TLS using self signed certificates.
- If you want to view your application through HTTPS, you can use ngrok to proxy your application.
- If you need a certificate authority but don’t want to pay money, StartSSL or CACert will give you a free certificate.
- If you want a self signed certificate and private key without typing on the command line, you can use selfsignedcertificate.com.
If you’ve read the above and you still want to completely disable certificate verification, set the following;
With certificate verification completely disabled, you are vulnerable to attack from anyone on the network using a tool such as mitmproxy.
By disabling certificate validation, you are also disabling hostname verification!
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:
With weak cipher checking disabled, you are vulnerable to attackers that use forged certificates, such as Flame.
If you want to disable hostname verification, you can set a loose flag:
With hostname verification disabled, a DNS proxy such as
dnschef can easily intercept communication.
By disabling hostname verification, you are also disabling certificate verification!
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:
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.