* Tries to give all the information you need instead of a rating.
* Open source, so you can self host it.
* Does the entire certificate chain.
* Allows to paste a CRL/Cert
* Validates the certificate, chain, CRL and OCSP (of every cert in the chain)
* Has easy copy-pastable PEM versions of certs
* Ciphersuite enumeration as an option.
* Fast.
For those who are trying to use the command line (rather than a webapp), "sslscan" performs these checks from a simple CLI tool.
However, I'm simply using load balancering sevices provided by AWS and Rackspace; my understanding is that (since they perform SSL termination) it is their software on the load balancer that chooses the ciphers, and as far as I know, I cannot change this. Are they misconfigured? (why?) Is there any way to work around it short of doing the load balancing myself?
[1]http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
Using a LB to offload SSL termination might seem like a good idea (you save a bit of CPU, really not more than a few percent in practice), but you expose your customer traffic to capture/inspection between the LB and your backends. This network can span multiple hops or even datacenters.
Also, when the next openssl vuln hits, you can patch your setup in no time and do not need to wait for the LBs to be patched at your vendor's will.
Of course I'm just speculating here.
Organizations running such huge websites need to be conservative about dropping support -- even if it only bites 0.01% of users that can be a huge population!
ouch.
For a permanent solution, get a very small Digital Ocean server, install this with the requested unsafe settings, and let the machine be dedicated to this. Even if someone compromised the machine, they wouldn't get anything of interest.
Also, it's flagging the following ciphers:
ECDHE-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
DES-CBC3-SHA
These are triple-DES though, rather than just single DES. Is that considered weak these days?The real reason to disable them is because of how slow they are. The only thing that is gonna actually use 3DES for TLS is MSIE on XP, its the last remaining secure cipher.
- Does not enumerate ChaCha20
- Doesn't detect BoringSSL - try running it on certly.io
How would I detect boringssl?
Friendly suggestion: Show a prominent summary at the top of the report of any areas of concern.
I'd like to see a check for SSLv2. For instance this site supports sslv2 and it should be flagged: download.biscom.com.
https://www.ssllabs.com/ssltest/analyze.html?d=download.bisc...