Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need a “/heartbleed.txt” standard, and we need it ASAP

blog.kamens.us

Post reply on HN
Print view View original

31–40 of 51 posts

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#31

Post by jzwinck »

jik wrote: post #23
jzwinck wrote: post #13

If a site knows it may have been compromised, it could simply force users to change their passwords on the next login. There is precedent for this (Adobe is one I recall), and it doesn't require any new smarts on the client side.

Great, and how do the users keep track of which of the hundreds of sites they use have done that? With the idea I'm proposing, it's possible to automate this _in the client_, such that users can proactively defend themselves against sites that haven't patched themselves or even indicated whether they were ever vulnerable in the first place. "Do you want to visit this web site? It may by vulnerable to the CVE-2014-016…

What site operator would install something which turns users away? Users will just click OK anyway, and if there is no OK button, users will decide their client is broken and go back to using Internet Explorer.

I'm trying to understand what the workflow and incentives are here. Not every site operator is very security-savvy, and to a first approximation no users are.

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#32

Post by jik »

edent wrote: post #14
jik wrote: post #9

Earlier quoted context omitted.

Sorry. My blog doesn't usually get this much traffic. ;-) Trying to increase the number of servers but httpd isn't cooperating.

I use CloudFlare ( https://www.cloudflare.com/ ) on my blog - handles even the largest load HN has thrown at it. Worth setting it up - just in case :-)

We use CloudFlare at work, but I had not previously foreseen the possibility that it might be needed for my blog.

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#35

Post by blauwbilgorgel »

I thought about a "hackers.txt" around the time "humans.txt" got popular. It would be stored not in a publicly accessible location, but in a location where finding it would mean a data leak (private web folder, users.sql).

It would have information like a unique security email contact, bounty for responsible disclosure and congratulations on a job well done.

These heartbleed attacks do scare me. They scare me enough that I get the feeling that resistance is futile. Changing your password on a few sites is not going to help when the opposition controls every bit of fiber between you and the website you're logging in on.

I do think that sites should disclose much more prominently when they were hacked. A few days ago there was the headline "Chrome inadvertently blocks wired.com". I think such a headline should be "Wired possible serving malware for a few hours yesterday". No "heartbleed.txt" hidden away, but a large banner across the top of the site: "We were hacked! Read more here! Update your virus scanners and scan your computer."

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#36

Post by jik »

jzwinck wrote: post #31
jik wrote: post #23

Earlier quoted context omitted.

Great, and how do the users keep track of which of the hundreds of sites they use have done that? With the idea I'm proposing, it's possible to automate this _in the client_, such that users can proactively defend themselves against sites that haven't patched themselves or even indicated whether they were ever vulnerable in the first place. "Do you want to visit this web site? It may by vulnerable to the CVE-2014-016…

What site operator would install something which turns users away? Users will just click OK anyway, and if there is no OK button, users will decide their client is broken and go back to using Internet Explorer. I'm trying to understand what the workflow and incentives are here. Not every site operator is very security-savvy, and to a first approximation no users are.

>What site operator would install something which turns users away?

The point of this proposal is mostly to enable sites to tell users that they _have_ been fixed (and when), not to tell users that they _haven't_.

Having said that, site operators pay to install valid SSL certificates from valid CAs because they know that if they won't, the browsers will increase the friction necessary for users to access their site.

If something like what I am proposing is widely adopted, then not patching their sites and notifying users that they have done so will similarly increase friction, so site operators will have an incentive to do it.

>Not every site operator is very security-savvy, and to a first approximation no users are.

The penetration of password management apps like LastPass continues to increase. The fact that many users do not choose to avail themselves of better security is no justification for not implementing better for security for the users who do.

If that were not the case then SSL would not exist.

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#37

Post by jik »

SchizoDuckie wrote: post #33

sarcasm mode on Great idea. Let's give attackers that have metasploit installed a shortlist of your current system status. /sarcasm No. No. No.

As others have pointed out, if they have metasploit installed they're just going to scan your site for all known vulnerabilities in a matter of minutes. Making it easier for the good guys to find out whether you've patched Heartbleed is not going to make things any easier for the bad guys.

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#38

Post by jik »

maxerickson wrote: post #15
jik wrote: post #8

Earlier quoted context omitted.

Yeah, I added an update to the bottom of the posting mentioning the possibility of generalizing it.

I tried to comment on the blog with something about a time stamp is all you need for the general case (and maybe some urls giving more information about the situation). Patched: 0 and Vuln: 1 isn't really useful information for the user; if sensitive data is involved the site should take itself offline, not warn users. A time stamp indicating when a mess was resolved is all a user who cares needs to decide to create…

I could live with simplifying the proposal to just list CVE numbers and timestamps.

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#39

Post by sixothree »

bitJericho wrote: post #4

Biggest 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?

Re: We need a “/heartbleed.txt” standard, and we need it ASAP

#40

Post by icebraining »

dubcanada wrote: post #16

Yah just what we need more *.txt files in the root of your website!

You do know that a URL doesn't have to map to a particular path in the filesystem, right? You can load the resource's representation from anywhere you want.
Post reply on HN