SSL testing – servers or domains?

print
We have started testing our SSL certificate spot checks – KeyChest – and realized that we were conceptually different from SSL Labs. We focus on the server rather than the domain name and it makes a difference.

Note: Before you say it. No, we don’t try to compete with SSL Labs! Rather than rigorously check your crypto settings already done brilliantly by SSL Labs, we focus on on-going operation support, i.e., that your server certificate is always valid.

Once again it showed how important user acceptance testing (UAT) was in terms of setting and meeting user expectations. We have announced our free SSL certificate spot checker to get some initial feedback before we launch the “real thing” – a certificate planner.

DEF CON should be ok next year

When you want to use the spot check, you just enter a domain name and will get back a certificate management information (an expiry date of your certificate, or your “certificate” downtime over the last 2 years) with an additional background info.

People primarily used it to check their web servers and some of them noticed a difference between our results and other services, notably SSL Labs. One of them was a different indication of a high-security mode called HSTS (HTTP Strict Transport Security), which requires web browsers to prevent web-server access if it detects a security problem.

A small difference in results pointed at a significant conceptual difference between the KeyChest service and other SSL checkers. We decided to focus on servers, rightly or wrongly, while other services check web domains. In technical terms, if the primary web-server redirects requests somewhere else, SSL Labs will follow the re-direct and test the final destination.

I am not sure, which approach is better so we decided to stick with our implementation and explain the difference to set user expectations right.

Our initial intention was to check servers and we should always be able to check whatever server we choose. I just didn’t quite appreciate how complex can be simple things. Having said that, when we detect an active re-direction, you can click on a link, which shows the final server. Once you register and get access to your dashboard (still in the process of being finalized! as of 13 June, 2017), you can see results for both servers.

The interesting question

A question based on my ignorance, I fear. I wonder what really is the value of HSTS to web-server visitors. You can test a web server and see an A+ (SSL Labs), which you can only get if there’s HSTS set up.

However, there are two interesting properties:

  1. you can set the HSTS only for a particular subdomain (or the main domain name) or all sub-domain; and
  2. you can only set the HSTS for a particular page only.

It’s perfectly possible that when you follow a link on a web site, the HSTS will “disappear”. Or it can magically “appear”, if you stumble on a particular page, and stay for a while.

I guess where I’m coming from is a question of the meaning of D or A or A+. How much it helps me decide that when I go to “https://scrooge-online-bank.money” I really get to my favorite bank.  🙂

Addendum – news.google.com

Guys have just added “Tracking feature” to the production server so I tried it with “news.google.com”.  The check showed a number of neighbours and the very first one was: accounts.db833953.google.cn. I’m thinking – hmm, interesting, must be something to do with the new Chinese data protection law. So I try to run a spot check on that one and here’s what I get – a redirection to a server in Ireland. It’s sometimes fun to have a look under the bonnet.

Google accounts in .cn redirected to Ireland

Published by

Dan Cvrcek

Founder and CEO of Enigma Bridge, engineer, entrepreneur, cryptography SME, security architect, and professor.