Interesting. Sounds like browser maintainers need to detect the patch level of a server and adjust the padlock icon accordingly. I don't know if this is as simple as a version number check, or if sites would need to be probed for vulnerabilities. In the latter case, maybe a global shared registry needs to be created that can be queried by browsers and updated by web admins (not on the honor system, obviously; after updating their server they could just ask it to re-audit them).
Alternately, an HTTPS implementation that can silently update itself without admin permissions like browsers can. The web moves too fast for manual security patches.
A lot of the cipher vulnerabilities absolutely take a probe. In fact, multiple probes.
The client sends a list of acceptable cipher suites to the server. The server then selects one that is also agrees with (this can be based on many factors, strongest first, quickest first, a custom priority, etc). Because of this, if you send, say 40 ciphers, the server will only respond with one. To get an accurate list of cipher suites supported, you must send each one individually to truly test whether the server does support a particular cipher suite or not.
Not to mention, if a server is sending out its 'patch level' to a client machine on request, that in itself is a vulnerability.
The government does use such a tool - or at least something similar - https://pulse.cio.gov/ is just one example of a public repository of some of those results.
It also makes me wonder if crawling the web and probing servers could get one in trouble for "hacking" under our current laws, even if the purpose is to protect people. Especially since, in this case, the people whose servers you're probing will stand to lose instead of gain from the audit.
In fact, now that I think about it, disclosing a list of sites that have known vulnerabilities could actually be a legitimately irresponsible thing to do; you'd be picking targets for bad-actors unless there was a confidential disclosure process.
If every site responded, upon request, with their patch level, a database could easily be created.
Or a scan becomes that much easier to perform on 100,000 endpoints - and then your targeted attacks can begin on only vulnerable systems. 'Exploiters' waste a lot of time trying non-vulnerable systems.
The less information your server exposes to the outside, the better.
So, yeah -- this is a really hard problem: mapping technical characteristics such as TLS properties and domain name similarities to actual threats.
That's one of the reasons why, in my thesis (which I defend in... 1 week!), I propose replacing replacing security indicators with risk indicators [1]. I think technical properties of a web page, in conjunction with the context of specific interactions, can be used to determine whether the interactions might be risky. By informing users of risks they may be taking, they feel more confident making their own trust decisions.
(Meanwhile on the back-end: as a web server developer, I'm trying to find ways to make it easier to do upgrades when vulnerabilities in protocols are fixed, etc. It's also hard.)
If there are ways to detect TLS vulnerabilities, it'd be nice to know that in the browser if that's not already possible. I would simply not visit sites that don't properly encrypt, and would even go as far as to block them.
I still have no idea what they have found. Far too little info to estimate how relevant this is.