Doesn't heartbleed let an attacker hijack the keys? Then they can man-in-the-middle the connection, and spoof the file so that the website appear to be not vulnerable to the attack.
We need a “/heartbleed.txt” standard, and we need it ASAP
41–50 of 51 posts
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#42Doesn't heartbleed let an attacker hijack the keys? Then they can man-in-the-middle the connection, and spoof the file so that the website appear to be not vulnerable to the attack.
MITM attacks require far more sophistication and many more moving parts than just stealing data from a web server's memory. Just because you have the SSL cert's key doesn't mean you have the ability to use it to MITM a site.
I'm not saying what you propose is impossible; I'm just saying it's quite unlikely. Security is all about layers. You don't throw away a layer that could be effective at increasing security in the majority of cases just because there are some cases where it wouldn't work.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#43Doesn't heartbleed let an attacker hijack the keys? Then they can man-in-the-middle the connection, and spoof the file so that the website appear to be not vulnerable to the attack.
There can be a useful communication of "passwords older than X should be changed" to the user. Blocking that doesn't make the user any worse off than simply not having it.
(That leaves the question of how useful it is to users; I guess it is nice for a service like lastpass, but the truly paranoid probably aren't relying on cues from services)
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#44Doesn't heartbleed let an attacker hijack the keys? Then they can man-in-the-middle the connection, and spoof the file so that the website appear to be not vulnerable to the attack.
MITM attacks require far more sophistication and many more moving parts than just stealing data from a web server's memory. Just because you have the SSL cert's key doesn't mean you have the ability to use it to MITM a site. I'm not saying what you propose is impossible; I'm just saying it's quite unlikely. Security is all about layers. You don't throw away a layer that could be effective at increasing security in th…
Of course. You can't MITM all the traffic to the site. But if hackers are targeting a certain security-conscious user, this standard will give them another tool!
This new layer will make the security better for the average user, but it will enable attackers to make a website look falsely patched in a MITM attack.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#45Since the point of this proposal is to inform password managers (or other user agents) that a password needs to be changed, a slightly different approach could be to specify "if you created an account in this timeframe, you should change your password." Then there's no need to specifically address which vulnerabilities existed when.
Something like:
https://www.linkedin.com/.well-known/password_revoke:
from:
to:
change_url: https://www.linkedin.com/sorry-we-lost-your-password-our-bad/
And then LastPass or 1Password or your browser or a plugin looking at credentials stored by your browser could routinely check sites where you have accounts, and say "Hey, LinkedIn says that your password is at risk and should be updated. Would you like to do that now?"
This is roughly equivalent to having LinkedIn send an email to all affected accounts (which is mandatory good citizenship, right?), but maybe will increase the success rate. It's another way for sites that have big embarrassing security breaches to try to do the right thing.
Possible downsides:
- Might teach users a behavior that makes them more vulnerable to phishing?
- More worryingly, if an attacker was able to MITM requests, they would be handed a list of every site where you have an account, and a way to affirmatively reach out and ask you for your password to those sites.
- Attackers might be able to detect the list of sites you have accounts at just by analyzing encrypted traffic. That could be valuable info on its own.
- An attacker who gained the ability to write to password_revoke (but no direct access to user data) could potentially escalate the attack by revoking everyone's passwords (although it's not clear to me how much more dangerous that would be than being able to write to password_revoke in the first place, and it might be a quick way to blow their cover).
Interesting idea anyway.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#46Since the point of this proposal is to inform password managers (or other user agents) that a password needs to be changed, a slightly different approach could be to specify "if you created an account in this timeframe, you should change your password." Then there's no need to specifically address which vulnerabilities existed when. Something like: https://www.linkedin.com/.well-known/password_revoke : from: to: chan…
I'm wondering if this is too specific. The other alternative proposal that someone floated in response to my proposal -- a file containing just CVE numbers and timestamps for when the site was no longer vulnerable to each of them -- seems more generalized and covers more than just passwords.
I'd extend that proposal to allow a CVE to be listed with a special token indicating "never vulnerable" (perhaps "1970-01-01T00:00:00Z" as the patched-at timestamp) and perhaps to allow a CVE listed with two timestamps indicating the range of time during which the site was vulnerable.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#47Your proposal may want to follow RFC 5785 aka "/.well-known/" That said, I don't see what problem you're solving or why the solution you propose should help.
>Your proposal may want to follow RFC 5785 aka "/.well-known/" This is addressed in a comment below the blog posting. >That said, I don't see what problem you're solving or why the solution you propose should help. I don't know how to explain it better than I already have. Sorry.
Your end-comment about /vulnerabilities.txt is a better solution than a /heartbleed.txt as this will not be the last such vulnerability.
However, I disagree about YAML. I'd recommend a standard JSON or CSV.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#48Biggest ever hole? Really? Am I the only one that remembers Yahoo placing passwords in the URL of unencrypted pages? I remember having to erase the URL line when people were around for fear of leaking my password.
Is that really bigger? Heartbleed meant that I, sitting comfortably in my home, could hit up yahoo.com and grab your credentials without being anywhere near your computer, or any of the data your computer sends or receives. Password in the URL with unencrypted HTTP is colossally dumb, but at least I have to either access your computer or at least snoop on its connection to take advantage of it.
My point is that there have probably been hundreds of these types of events going back to the ancient times of the internet. The sky is not falling guys, just a good downpour.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#49Earlier quoted context omitted.
Is that really bigger? Heartbleed meant that I, sitting comfortably in my home, could hit up yahoo.com and grab your credentials without being anywhere near your computer, or any of the data your computer sends or receives. Password in the URL with unencrypted HTTP is colossally dumb, but at least I have to either access your computer or at least snoop on its connection to take advantage of it.
My point is that there have probably been hundreds of these types of events going back to the ancient times of the internet. The sky is not falling guys, just a good downpour.
My point is that heartbleed is unique in its combination of severity and scope. Something like 25% of all the web servers on the internet could have their most private data extracted for a period of two years. The sky isn't falling, but I can't think of anything else that comes close. Vulnerabilities that affect individual sites, while still really bad, still don't approach this.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#50Biggest ever hole? Really? Am I the only one that remembers Yahoo placing passwords in the URL of unencrypted pages? I remember having to erase the URL line when people were around for fear of leaking my password.
Isn't Yahoo one (of the many) sites affected by heartbleed?
Yes, and they were particularly slow in patching it too. Took them over a day.