Those of us who help create and maintain “the internet” that everyone benefits from are now tasked with helping the world recover with one of the biggest, if not the biggest, security holes in the history of the internet.
To be certain they aren’t vulnerable, users need to change their passwords at every site that was at any point vulnerable to a Heartbleed attack. But a site has to be patched, and its SSL certificate has to be reissued with a newly generated secret key, before its password should be changed; otherwise, the new password is just as vulnerable to Heartbleed as the old one was. What’s more, you can’t just look at the start date of an SSL certificate to determine whether it was reissued, because that doesn’t tell you whether the site was patched before the certificate was deployed, and worse than that, some CAs (e.g., Digicert) quite reasonably re-key certificates without changing their original start dates.
I have passwords at over 500 sites. I’m sure there are people who use many more sites than that. Manually figuring out which sites need their passwords changed, and when to change them, and keeping track of which ones have been changed, is an impossible task.
What we need is a standard, widely adopted way for web sites to indicate, in a way that can be easily interpreted by software, whether they were ever vulnerable to Heartbleed, and if so, when the vulnerability was patched. Then browsers and password keepers such as LastPass can easily determine and track which user passwords need to be changed, and warn the user.
I’m hoping that someone else with far more clout in the browser development and/or internet security community has already thought of this idea and started the ball rolling on making it happen. But just in case that hasn’t happened, here’s my proposed standard:
- Web sites conforming to this standard shall serve the URL “/heartbleed.txt”.
- The file can have LF, CRLF, or CR line endings.
- Blank lines and lines starting with optional whitespace and then “#” are ignored.
- The file must have a line which reads (with optional whitespace between any of the lexical tokens) “vulnerable: 1” or “vulnerable: 0” to indicate whether the site was ever vulnerable to Heartbleed.
- The file must have a line which reads (with optional whitespace between any of the lexical tokens) “patched: 1” or “patched: 0” to indicate whether the vulnerability has been fully patched.
- The file must have a line which reads (with optional whitespace between any of the lexical tokens)” “patched_at: iso-8601-date-time“, where iso-8601-date-time is a valie ISO 8601 date and time in UTC (only UTC is acceptable to make the file as easy and reliable as possible for consumers of the file to parse).
- Any other lines in the file are ignored, to allow for future, backward-compatible enhancements to this standard (not that I anticipate any will be necessary, but of course famous last words and all that).
If someone else has already thought of this idea, please point me to it on-line and I’ll deprecate my own proposal and put a link to theirs here instead. The last thing we want is multiple proposals floating around for solving this problem.
One could make an argument for generalizing this, e.g., calling the file “vulnerabilities.txt”, allowing multiple vulnerabilities to be listed in it with the vital stats for each of them, etc. I’m not sure whether we should do this now, at the expense of making it take longer for this idea to be adopted, or postpone it for later when we aren’t in the-internet-is-burning mode. If we were going to generalize it, then I would probably say that the URL should be /vulnerabilities.txt, it should be formatted as YAML, and it should have top-level keys corresponding to CVE identifiers and for each such identifier the “vulnerable”, “patched”, and “patched_at” fields as subkeys.