SSL tools we wish we'd known about earlier | Hacker News Reader

SSL tools we wish we'd known about earlier

certsimple.com

217 pointsnailer57 comments

My favorite tool is the Calomel Firefox addon. https://addons.mozilla.org/nl/firefox/addon/calomel-ssl-vali...

The article links to https://badssl.com/, which shows a list of links to good and bad configurations. Calomel gives more details about what is right and wrong, and sometimes surprises with its rating.

Another similar add-on I use is SSleuth. https://addons.mozilla.org/en-US/firefox/addon/ssleuth/ One features it has that Calomel apparently doesn't is that it shows you its "score" for all of the domains on a page, not just for the domain of the top-level document.

Am I right to be excited about http://letsencrypt.org being about to make all of this much more sane? General availability on 2015 Sept 14.

LE will mean a domain validated cert is free rather than costing 10-15 dollars, with the same proviso as other domain validated certs. That's a good thing.

But it won't change a lot of the things mentioned in the article: people will still need to configure servers, fix browser errors, researchers need a source for large-scale SSL scans, inspect packets, lookup domain contact info without junk results.

We're working on the configuring servers stuff BTW: we landed patches in node.js to ensure their TLS implementation passes SSL Labs out of the box and I'm hoping to do the same for nginx in future.

Letsencrypt offers to configure common webservers automatically. If a lot of people take up the offer, there could soon be much fewer servers with grossly insecure TLS configurations.

https://sslmate.com - being able to get fresh certificates in less than a minute right from the command-line is amazing.

(Author here, replying with my old openid account due to rate limit.)

The 'freshness' is possible because it's a domain validated certificate - domain validated certificates are < 1 min, and normally cheap or free, as all you have to do to get a domain-validated cert is have an official sounding email address, publish a DNS text record, or some other way to show you have control of the domain. Domain validation doesn't require any investigation of the identity behind that domain, which is why they don't show the company name or the green bar. In Edge, domain validated certs show a hollow grey lock. [1]

EV certificates require checking the actual company - government registration, business status (eg, do you pay your taxes), does the person requesting the certificate have authority to take actions on behalf of the company, does the company have a verifiable physical address, and more [1]. They then show that company's identity in the certificate and browser - as the company name in a green bar.

Nearly everyone you speak to will quote a either a vague figure or 7-10 days to provide an EV cert.

CertSimple only does EV, and our average certificate issuance time is 5 hours. We've been doing them even faster than that recently - check the tweets on the front page of the site. A big part of that is that CertSimple checks a whole bunch of your company's information before you pay us any money. [2]

[1] https://certsimple.com/blog/dv-ssl-in-microsoft-edge

[2] https://certsimple.com/blog/are-ev-ssl-certificates-worth-it

[3] https://certsimple.com/blog/checking-orders-before-you-pay

Cool. One question: what if I'm not a company?

Woo, rate limit's expired!

If you're not a company, or registered organization, or government department, you can't get an EV certificate right now. The cabforum EV guidelines [1] don't currently have provision for individuals.

I know that sucks. Especially when there is already capability to use government IDs for individuals in the EV guidelines for checking e.g. company directors in some cases [1].

But here's why:

- The certificate subject for an EV cert, i.e. the thing the CA is attesting to by signing your certificate is the unique in the jurisdiction registration ID.

Eg, visit https://github.com and click the certificate in Chrome - you can see GitHub is Delaware company 5157550.

The subject for an individual version of an EV cert would needs to be:

- unique in the jurisdiction

- publicly revealable

You couldn't use the number of the ID checked, since passport numbers, drivers license numbers and other are considered 'High Risk Confidential Information' in much of the world [2]

Unfortunately such a document don't exist in much of the world.

[1] https://cabforum.org/wp-content/uploads/EV-V1_5_61.pdf

[2] http://security.harvard.edu/book/1-high-risk-confidential-in...

The tuple (Full Name, Date of birth, Place of birth) ought to be a suitable unique subject for an individual.

"Meet my two twin sons, Collision (pronounced cole-eye-zon, we call him Cole for short) and Collision (pronounced call-iss-on, though we like to call him Colin)."

Luckily you are such a good parent that your twin sons would never dream of impersonating each other online.

And of course the Date Of Birth is really Date/Time of Birth.

The point is that "this is unique enough" is not a good standard when the data is sketchy or even subject to manipulation. The corporate ID numbers otherwise being discussed are unique by fiat.

That looks good, thanks for sharing

Also useful. sslscan (http://sourceforge.net/projects/sslscan/). Point it to an endpoint and it will tell you all the ciphers and protocols that are accepted, and what the various defaults are, and details about the certificate bound to it. It's available in the Debian/Ubuntu repository for easy installation.

SSL Scan is good, but the industry standard for server configuration scanning is SSL Labs:

https://www.ssllabs.com/index.htm

Agreed, but not everything is public facing, and sometimes you need quick verification. ssllabs is great and should definitely be done on all external endpoints, but it takes a while to run.

Would being able to specify a HTTP (CONNECT) proxy to SSL Labs be useful to you for the testing of your internal hosts?

Being able to use non standard ports would help. I usually just SSH tunnel it in. But needing to use port 443 makes it annoying.

So, two things.

First, the link is missing an 'l' at the end. [0] Second, exactly what makes SSL Labs the 'industry standard'? I'm well-aware of their services and use in the industry, but I would tend to think that the actual RFCs are industry standard, and not a rather specious high-school grading system for whether a particular TLS provider is secure.

[0] https://www.ssllabs.com/index.html

In my opinion, the high-school grading system is one of the best features of SSL Labs. Most people don't have the time or interest to read the RFCs and follow the issues closely. The grading system help them easily understand what is important and what isn't. (Disclosure: I built SSL Labs.)

So I used this site to check my server and then used the Mozilla SSL config generator. This fixed my site and got me to an "A" rating.

So at this point the biggest thing I'm looking at is the "Chain issues" line that reads "Contains anchor". Assuming this has something to do with the bundle file I created?

Yes. Your bundle should not actually contain the top-level CA certificate which is present in browsers.

Thanks, that did the trick.

How would you go about testing your internal endpoints?

Use Nmap's SSL scripts. Especially useful for scanning STARTTLS non-web services like SMTP, POP3, and IMAP.

If you're not using Mozilla's SSL config generator, you should check it out. The Mozilla OpSec team did a nice job on this. I love when teams give back to the community. https://mozilla.github.io/server-side-tls/ssl-config-generat...

It is pretty good, but it’s not an “SSL” config generator; it’s an “OpenSSL” config generator. It only supports OpenSSL. No GnuTLS, no NSS, nothing but OpenSSL.

Specifically it's for Apache/Nginx/HAProxy/AWS ELB which link against openssl (there's also a node port). Are there alternate bindings for any of these for GnuTLS, NSS, etc?

For Apache there are https://mod.gnutls.org/ and https://fedorahosted.org/mod_nss/

I was using mod_gnutls for some sites, but it did not make it into Debian Jessie. mod_nss is still in Debian Stable though.

Note: mod_gnutls is present in Debian unstable, and it is possible to backport it to Debian stable:

  dget --build http://ftp.debian.org/debian/pool/main/m/mod-gnutls/mod-gnutls_0.6-1.4.dsc

You will likely get some error about “Unmet build dependencies”. If you do; run this:

  mk-build-deps --install --remove mod-gnutls_0.6-1.4.dsc

and try the dget command again. Then install the package:

  sudo dpkg --install libapache2-mod-gnutls_0.6-1.4_$(dpkg-architecture -qDEB_HOST_ARCH).deb

A firefox plugin that gives you more details about the ssl/tls connection of the site you're connected to: https://addons.mozilla.org/fr/firefox/addon/ssleuth/?src=sea...

It also gives a summary grade. Very few sites are 10/10 (I only remember github having this grade)

Python.org and Twitter also get a 10/10 for me. That score is rare because (by default in SSleuth) you need an EV certificate to get the last 1 point and most sites don't have one (and many that do, like the banks I use, don't use the best TLS configuration). I personally treat a 9/10 with a DV certificate as secure as 10/10 with an EV certificate.

Sometimes I use this one to validate certs: https://www.sslshopper.com/ssl-checker.html

The Qualys SSLlabs scan does not accept an IP address. I'm often in the situation where the cert is installed and ready, but the name is not yet pointing to the new IP address. The above URL can verify that you haven't left out the intermediate cert.

Other things I use all the time:

`openssl x509 -in $FILE -text | less`

https://lapo.it/asn1js

https://golang.org/pkg/crypto/x509/

https://github.com/agl/certificatetransparency

There's a load of useful stuff in the OpenSSL commandline, figuring out s_server and s_client can be very useful for debugging.

GnuTLS has some useful stuff too, IIRC

The Native OS X Wireshark is great! I always hated the one that required X11 as it rarely ever worked right :(

Unfortunately, native interface is too bugged to serious use yet. When trying to "Follow TCP Stream" it will crash with big streams (>20mb) and several tools are missing.

But for quick or simple auditing it works great!

There's also sslyze for comprehensive and fast scans, it can test just about any TLS service.

https://github.com/nabla-c0d3/sslyze

Nmap has some very useful SSL scripts, such as ssl-enum-ciphers, ssl-heartbleed, ssl-poodle, ssl-ccs-injection and this one for testing Diffie-Hellman configurations: https://github.com/eSentire/nmap-esentire

The whois query works with his Microsoft example but I get a malformed request error when trying it with some of the newer domain extensions like .ninja

Author here. The query format is (sadly) server dependent. For a ninja domain, use `whois.nic.ninja` as the server, and don't use the 'domain somedomain' query syntax.

    whois -h whois.nic.ninja domains.ninja

Normally the server would tell you the syntax it supports with `whois -h whois.nic.ninja help`, but whois.nic.ninja doesn't support `help` either.

See https://certsimple.com/blog/junk-free-whois

I really like the Debian version of whois because it solves this problem by automatically picking the correct server based on the query (even for .ninja) and following referrals to a whois server with more details.

https://packages.debian.org/stable/whois

Rad. Did some clicking around, here's the upstream https://github.com/rfc1036/whois

Thanks! Also came across gwhois.org that seems to take a novel approach to the problem too.

https://cipherli.st

This should be on the list of valuable tools as well. It's a site which has strong example configurations for Apache, nginx, Openssh and many many others.. It's a great reference site. It's updated as new vulnerabilities are released, and as new technologies become available too.

Careful about implementing it all though - as their warning says, unless you understand things like HSTS or HPKP, implementing them incorrectly could make your site unavailable for a very, VERY long time.

That said, it's an easy way to get an A+! If you disable everything but TLS1.2, you can get a perfect 100/100/100/100.

Clicking through to the relevant "Rationale and tutorial" article on that site is well worth it, those tutorials are very useful for newbies.

I also found Mozilla's documentation for TLS very helpful: https://wiki.mozilla.org/Security/Server_Side_TLS

I love https://cipherli.st too - it's definitely worth reading their rationales - but the Mozilla Server Side TLS project the other poster and the article mentioned seems to have more contributors and be more frequently updated (it's also on github).

I find https://testssl.sh/ particularly useful

No one has mentioned the https://labs.portcullis.co.uk/tools/ssl-cipher-suite-enum/ perl script yet.

The tool performs a similar function to sslscan, THCSSLCheck and sslyze, but differs by crafting part of the SSL handshake instead of using an SSL library to establish a full connection. [...] Libraries either become outdated and therefore incapable of testing for new protocols such as TLSv1.2 or exotic cipher suites; or they are updated and lose support for older protocols – namely SSLv2.

Support for SSL testing over SMTP (STARTTLS), RDP and FTP (AUTH SSL)

Another useful site:

https://ssldecoder.org/

Source for self-hosting:

https://github.com/RaymiiOrg/ssl-decoder

I find Julien Vehent's CipherScan to be very useful https://github.com/jvehent/cipherscan

I'm hearing this undercurrent in the discussion here that domain validated cents are somehow inferior.

Other than the fact that certsimple sells EVs exclusively, I don't really see any meaningful benefit. The arguments for EV are the Verisign sales pitch from 1999. (Ie. We are very careful!)

They listed openssl s_client, which is awesome, but they neglected to mention openssl s_server, which is also an awesome way to set up easy reproductions/testcases for others when something like badssl might not be available due to firewalls and such.

http://sourcefourge.net/projects/xca/ is a nice gui for x509 certificate and crl maintenance, creation etc.

(edit: inb4 kneejerk about sourceforge)

Looks like the domain name is misspelled; the URL should be:

https://sourceforge.net/projects/xca/

Heh. Once upon a time, school allowed me to choose my preference, the choice being to either use her Majesty's English or American English, but not both. I chose British and stuck to it, but here is an example of where I'm just taking it too far. lol

Thanks for correcting. :-)

Reply on news.ycombinator.com