Live data from Hacker News

OpenSSL.org hacked?

openssl.org

41–50 of 98 posts

Re: OpenSSL.org hacked?

#41

Earlier quoted context omitted.

but what if they set-up the server side so that the server returns different results depending on the browser/OS?

$ curl -A "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" www.openssl.org

But what if they return a joke, so funny, that it kills whoever reads it?

Re: OpenSSL.org hacked?

#42
post #25
post #3

Other pages are still up (although I haven't checked that they're unmodified) - it does appear the attacker didn't bother to bring anything but the front page down.

They did that on purpose, their intent seems to be to bring awareness rather than destruction.

An email works too :)

Re: OpenSSL.org hacked?

#44
post #27

Earlier quoted context omitted.

Who runs OpenSSL? Is it again volunteer? I think big companies need to step in and help creating infrastructure for these big projects.

Yes, all-volunteer. There are no ongoing commercial sponsors for that project.

As it should be. There was a story in HN a few weeks ago about why open source projects better not run on funding. Something with making it obligatory to work on the project and add features just to do something. And of course the people "donating" have some say in what's going on. I'm not saying backdoors per se, but should we want any sort of pressure this way?

Re: OpenSSL.org hacked?

#45
post #39

Does anyone have any details about how this was done? Was it a compromised admin account, a local root exploit, social engineering, etc? I'm eagerly awaiting the post-mortem.

No, and this is what makes it non-news. Especially since it links to the hacked webpage. Neither really Hacker nor News...

Re: OpenSSL.org hacked?

#46

Yet another example of why to both sign release artifacts AND verify them is important. Also, if you're running the public website for a security lib or core FOSS package, expect more attacks by kiddies trying to build rep... so very conservative tech choices (mostly static website served from a read-only fs) and defensive practices are de rigueur.

What's the use in a static website or a read-only FS when you can overwrite what's in RAM, or just attack routing or DNS? Security is a little more complex.

Re: OpenSSL.org hacked?

#47

What is a good reason for openssl.org not to utilize HSTS[1]? $ curl -I https://www.openssl.org/ HTTP/1.1 200 OK Date: Sun, 29 Dec 2013 03:57:54 GMT Server: Apache/2.2.22 (Ubuntu) Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 15686 Content-Type: text/html [1]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Because it doesn't need it. Technically no website needs it. Only people who don't know how to type "https" need it.

Re: OpenSSL.org hacked?

#48

Yet another example of why to both sign release artifacts AND verify them is important. Also, if you're running the public website for a security lib or core FOSS package, expect more attacks by kiddies trying to build rep... so very conservative tech choices (mostly static website served from a read-only fs) and defensive practices are de rigueur.

What's the use in a static website or a read-only FS when you can overwrite what's in RAM, or just attack routing or DNS? Security is a little more complex.

Ahh yes, the "if you can't turn it into Fort Knox, don't bother at all" guy.

Turning up at every security discussion since 1874.

Re: OpenSSL.org hacked?

#49

What is a good reason for openssl.org not to utilize HSTS[1]? $ curl -I https://www.openssl.org/ HTTP/1.1 200 OK Date: Sun, 29 Dec 2013 03:57:54 GMT Server: Apache/2.2.22 (Ubuntu) Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 15686 Content-Type: text/html [1]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Because it doesn't need it. Technically no website needs it. Only people who don't know how to type "https" need it.

No. HSTS prevents SSLStrip attacks when the intended destination is always meant to be in SSL.

Re: OpenSSL.org hacked?

#50

Yet another example of why to both sign release artifacts AND verify them is important. Also, if you're running the public website for a security lib or core FOSS package, expect more attacks by kiddies trying to build rep... so very conservative tech choices (mostly static website served from a read-only fs) and defensive practices are de rigueur.

What's the use in a static website or a read-only FS when you can overwrite what's in RAM, or just attack routing or DNS? Security is a little more complex.

The point is to minimize attack surfaces. If you're serving static content that's one less path for an attacker to potentially exploit. With only static files exploits are limited to those contained in the web server or the OS network code. With a read only filesystem certain classes of privilege escalation are eliminated.

Attacks on routing or DNS are more difficult to deal with, but at least it isn't your server being compromised, and if you're using HTTPS properly then the certificate should show as invalid at least.

So yeah, security is complex, but his advice was spot on. The fact that you seem to call it into question says that you don't know much about security.

Post reply on HN