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.
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.
(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]
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.
"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)."
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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).
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)
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.
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
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.