$ curl www.openssl.org
  TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _

    $ 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

https://en.m.wikipedia.org/wiki/The_funniest_joke_in_the_wor...

Of course in some cases they may be false flag operations, always a possibility worth keeping in mind.

not positively surprisrd, more like dissapoined.

It prevents mind reading.

Luckily it seemed to have cleared.

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.

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.

If you want to minimize your attack surface, what he suggested is quite possibly the least effective possible thing anyone could do. I point out just a few of the more important issues to consider first, and you tell ME I don't know about security? I don't know what kind of systems you secure, but mine don't rely on 'mount -o ro,remount /' as a defense strategy.

[1] http://ycombinator.com/newsguidelines.html

Turning up at every security discussion since 1874.

I would personally expect that the openssl group is suffering some embarrassment, but this sort of hack is a risk of the business. Hopefully we get a good writeup.

Why is there not a standard for links of this type in browsers. Eg <a href="url" sigurl="url to sig" sigalgo="algo to calculate signature">OpenSSL</a>

That's a simple way to go but I really think it's as generally insecure as reading a signature form a url that is advertised by a website. It's also why I rarely bother.

But if browsers were good about this then it could be done in a much better way which is to sign the application with a real peer verifiable signing method. Such as the SSL cert that covers the site behind the open source project .

now this only works for projects that have SSL certs. Another method would be to have a clearing house that can do 1-1 with github et al and a re cert, like a oss cert organization. A final good way would be to use the beauty of git and use the source checksums and a repeatable build process (which is fricking hard) and come up with a way to give a signature for oss applications based on a git commit and check that back to the public git repository.

really I think knwon public keys for oss projects and branches would be the real answer. And the security gating for newbs would be like windows and linux which check the public signature of the application before they run them from the web and make the end user feel safe instead of doing nothing.

Browsers have a good share in this responsibility as well. Standard domain security should work well here as well. Better than what we have.

I leave this to more entreprenurial minds to make this work and I'd love some real telegraph style sinkers to point out the flaws. This is must me talking after a belated xmas dinner. but I think I'm kind of on course.

But that's if we're talking websites in general. For the specific use here, installing "trusted" software packages, far better solutions already exist and already protected the users of OpenSSL.

  $ 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

It's obvious why it can be a grand target for Man in the Middle, defacement and worst of all integrity attacks. Apart from preventing many of the latter, implementing HSTS could have really mitigated the problem. Anyone who had already visited the site wouldn't see the defaced page. Furthermore, they could get added to an STS preloaded list[1], making the attack invisible to anyone using a modern browser.

If you are interested, the Wikipedia page[2] does a fair job at explaining more about why HSTS is needed.

[1]: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...

[2]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security...

But this is all crap, really. OpenSSL is a library distributed across tens of thousands of independent providers all over the internet. Nobody needs to get it from the main site, and even if they do, there's a multitude of ways to tell if it's the real deal or not. If you know what OpenSSL is, you can type in "https" and be totally secure without HSTS. Even if you needed HSTS (which you don't), who's going to the OpenSSL.org website time after time that HSTS would even be useful?

People make way too big a deal over half-baked countermeasures that don't apply to every case. You find me the person who's downloading vanilla OpenSSL libraries from the main site over multiple visits and is at risk of a client-side MITM and not verifying their sources, and i'll show you someone who's going to get owned even without a MITM.

Furthermore, it's just embarrassing to see such attacks on these high-profile sites. If they can't defend their site (even for users who don't type "https://"), who is to say their library is secure? These kinds of attacks threaten the confidence we have on our fundamental cryptographic building blocks and should be avoided.

1. These attacks don't bear at all on cryptographic building blocks, because any script kiddie can brute force a login or fuzz an input, etc. Has nothing to do with crypto at all. Has nothing to do with their code at all. Completely different systems with completely different attacks with incredibly different requirements... it's worlds apart. There is nothing about defacing a website or even MITM that could ever be compared to breaking a crypto library.

2. HSTS is quite a bit different from the PKI of TLS. That said, what you are basically saying is "HSTS is the same thing as HTTPS when you add the URL to the browser's STS whitelist". (Which could be avoided altogether if you just type "https")

So what your argument really boils down to is: a crypto library is worthless because we really need to use HSTS because OpenSSL.org users are too stupid to type "https".

Not only is this inaccurate and nonsensical, it's just a crappy security model. Now I have to manage HSTS exactly the same way TLS certs are managed and basically reproduce one protocol into a pseudo-protocol and juggle both, keeping things like RFC 6797 in mind. Suddenly the complexity's gone up enormously over time, only to prevent MITM on the client, and we don't even consider whether or not the content was compromised before the connection of the client to the server.

Even if the server is hacked, you still have absolutely no guarantee if the content was modified, because you're not verifying the content once you download it. But sure. Let's freak out about the possibility of a one-sided MITM to the client over HTTP (which every idiot knows is not secure by design), because that's clearly the most important or likely attack to be worried about right now.

Also, you're forgetting about browsers that ship with lists of HSTS-enabled sites.

TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _

script-src at http://www.w3.org/TR/CSP11/

The next logical step is some kind of third party authority, and then you right right into the Certificate Authority problem set, including code signing licenses like Apple and Windows use.

Some F/OSS systems are starting to use similar systems, like the newer Python package distribution systems.

"openssl.org/ owned ;) http://zone-h.org/mirror/id/21425720 …"

Sorry to prefer build things and creating value than destroy it.

I wonder why so many security guys are so condescending and contemptuous...

29-Dec-2013: Web site defacement. Investigation in progress, more details to follow.

Not cool at all, and apparently the guys running the site haven't took notice yet.