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.
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.)
As far as I can tell, this article is content free.
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.
In other news, Wired obviously still thinks that breaking the browser's back button is a valid way to boost conversions.
I read the complete article. I read the page of the researchers that is linked. I know how this stuff works.
I still have no idea what they have found. Far too little info to estimate how relevant this is.