My weekend project.

* 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.

Thank you so much for this. Can I fork it to add the ability to accept an HTTP POST for the domain/hostname, and return the persistent results URL back to a webhook? (Slack integration)

I do have a JSON (plain text, readable json) output endpoint planned, but that will be GET as well. Pull requests are welcome though.

It also does custom ports and protocols, for example 8443, 465 (SMTP), 994/995(POP/IMAP) etc.

Custom ports and IPv6 support <3

This is pretty great (and you even managed to snag a short domain name)!

For those who are trying to use the command line (rather than a webapp), "sslscan" performs these checks from a simple CLI tool.

+1 to SSLScan. Last time I checked though, the Windows builds don't work/support the XML output option. Automating this last year involved capturing STDOUT and regexing...

Thanks for doing this, awesome job. May I request IPv6 support?

As far as I can tell the website is accessible via IPv6 and you can run checks on IPv6 only servers. What is missing?

If your hostname is dual stacked it only checks for ipv4 afaik.

These services always dock me for including RC4 ciphers. I understand that these are bad because RC4 is broken or near broken; I shouldn't be using it.

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?

It appears AWS lets you configure this[1]. You may have chosen a policy and never changed it. A note on that page says if you don't choose a policy, you'll always use the latest one. It looks like you can create a custom one, as well.

[1]http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...

Use these services as tcp load balancers and terminate SSL on your backends.

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.

rc4 may be "bad", but if you notice, it is so densely deployed on clients, it's hard to avoid.

Thanks, looks great!

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...

I've tweaked my Apache configuration but don't seem to be able to trigger a rescan--the cipher list doesn't appear to change. I guess it's cached for a little while, but the UI doesn't make that clear.

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?

They have 112-bits of security and are considered fine until 2030 by NIST. (insert opinion of NIST here)

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.

Feature/bug: It doesn't seem to attempt to explicitly negotiate older protocols. For instance, I'm dealing with a site that still has SSLv2 and export ciphers enabled if a client requests it. (Like, if I run openssl s_client -ssl2.) SSLlabs detects this, but tls.so doesn't.

Known issue. Have to look in to that...

I started to build a similar thing, for the command line, last year but did not get as far.

https://github.com/jamescun/ssltest

Few notes:

- Does not enumerate ChaCha20

- Doesn't detect BoringSSL - try running it on certly.io

ChaCha20 support is not in Openssl 1.0.2 yet, only an outdated dev branch. When it's in, it'll support it.

How would I detect boringssl?

Nice.

Friendly suggestion: Show a prominent summary at the top of the report of any areas of concern.

That's a good idea. Chain issues are already reported, but expiry or validation errors should be prominent as well.

I really like the nice big horizontal check marks for the "health" of each aspect of the certificates. Thank you for releasing this.

Why are certificate serials highlighted in red?

No particular reason. What would you do different?

Maybe he meant that coloring them red means that something went wrong or that there's something that you should pay attention to.

Of course I'm just speculating here.

Yes, that's the same impression I got skimming through the page for a domain.

Thank you for putting this all together and making it open source. By the way, will you be releasing an API? I think this API would be really valuable.

Funny, looked up Gmail and they are still allowing SSL3

With browsers supporting TLS_FALLBACK_SCSV the SSL3 risk isn't that great since an MITM attack can't force a downgrade. Therefore SSL3 should only end up being used by old clients that don't support anything newer.

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!

Damn you IE8 and Android 2!!!

Nice work. This will help a lot of people who audit sites.. and its great to have an open alternative to the closed source ssllabs tester.

"PHP must allow shell_exec and remote fopen."

ouch.

Not a big deal if you're self-hosting. Put it in a Docker container (on your own machine or one of your servers), run it when you need it, and then shut it down.

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.

It's not about finding anything of interest in the server. It's the negative impact this server and many others like it have on others when they're leveraged in an attack.

I definitely do not support having unmonitored servers. If your server is used in an attack, you should see a traffic spike and shut it down.

I also meant to say that any server used for this purpose should be firewalled so that only your IP can access it.

An outward attack from this server against another doesn't necessarily register in bandwidth graphs. It all depends on the type of attack.

Nice work. How do you determine the destination SSL library?

Thanks. Just needed something like this last week.

Seriously, nice work!