Google Online Security Blog

> really? so those discussions are all held amongst programmers eager to use these security vulnerabilities to illegally exploit systems?

Those discussions tend to occur on different forums. Their absence here is no sign of their absence elsewhere. And for many of us, our biggest issue with Aaron Swartz is not what he did, but how he was treated.

> Or are they entirely groups of programmers dedicating their careers to being very worried about the prospect that our systems might not be secure enough? Is that not an ethical position?

That's a nice, positive view of security researchers. For what it's worth, it's one I hold myself.

But we don't exactly hear a lot about those who skipped the whole "ethical disclosure" debate, of if their specific position is indeed ethical, and went straight to selling exploits to the NSA or criminal enterprise.

> I think you're grossly underestimating the scale of crime being perpetrated by banks even very recently. Start with worldwide currency manipulation: http://www.nytimes.com/2015/05/23/opinion/banks-as-felons-or...

Meanwhile, global botnets are common enough that we don't hear about most of them in the news - because they're not newsworthy - except for the rare occasions some security researchers manage to put a dent in one of the larger ones. And everyone gets pissed at Microsoft for mishandling no-ip.com's domains in an effort to fight malware. Not to mention the number of times I've heard of account details of services I…

I shouldn't have been so harsh, because despite the fact that these techniques are already widely deployed [1], most people don't understand them. In fact I had a conversation with an ffmpeg developer on this forum and he didn't think securing ffmpeg this way was feasible. And I think another reply to my message mistook FFI for IPC, as you did. So the vocabulary hasn't even trickled down to most programmers.

Application compartmentalization is certainly difficult in practice, and should be made easier, but it is deployed and it's a lot easier than rewriting all code in a different language.

ffmpeg is a great example. It is hideously broken, with thousands of likely security bugs [2]. Now let's compare these two strategies:

1) Rewrite EVERY video codec in Rust
2) Reuse existing code, but run it in a completely
untrusted process (no OS privileges), and only
communicate with IPC.

The claim is that #2 is much more achievable than #1. You could say that #1 takes orders of magnitude more work, which is true, but that doesn't even quite capture it -- it actually scales differently because for #2 you do constant work and get security for ALL video codecs. It's O(1) vs O(n).

Why not get secure foundations by 2025 instead of 2035? What I'm arguing for is a hybrid, heterogeneous architecture -- instead of rewriting 100% of code in Rust, rewrite 5% in Rust and isolate the remaining 95%. That gets you a better result which much less effort.

These…

The technique they'd be using to do that would be new to science.

Here it is worth pointing out that Google did something awhile ago to make NSA's job much harder (if their goal is to read everyone's mail): they became aggressive advocates for TLS forward secrecy.

http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-term-with.html

TLS forward secrecy involves the ephemeral Diffie Hellman ciphersuites (which your browser supports). Instead of deriving a session key and using the server's RSA key to convey it, the DHE ciphersuites run the DH protocol to derive a session key between the client and the server, and then use the RSA key to sign the exchange ("breaking the tie" if there was a MITM). The RSA key is never used to convey a session key; if you got all of Google's TLS keys, you would not be able to go back in time and decrypt old sessions that used a DHE ciphersuite.

It is also worth pointing out that some of the hardest people working in security show business, including Adam Langley and Michal Zalewski and Justin Schuh, people with unimpeachable reputations in my field, work for Google on these problems.

A couple of notes:

* This was not a MITM attempt

* When traveling laptops, it's more secure to use DNSSEC + Unbound

* The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so - fair enough, I trust Dr Bernstein even more than tptacek - but it's a bit contradictory. He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4).

Also, note, all major DNS providers are collecting data: OpenDNS (also adds a few suspicious redirects when the URL doesn't exist), Google is the leader of world-data mining, etc. The most trustworthy DNS, according to the a research I did some time ago, was/is OpenNIC.

At home I run a dnsmasq + unbound (DNSSEC) + OpenNIC DNS's. On my laptop I have a similar configuration which uses by default a local unbound installation when joins every other network except mine.

[1] http://googleonlinesecurity.blogspot.cz/2013/03/google-public-dns-now-supports-dnssec.html

[2] http://en.wikipedia.org/wiki/DNSCurve#Deployment

[3] http://www.opennicproject.org/

This was indeed a pleasant surprise when I logged into my CloudFlare account.

What intrigues me is that CloudFlare missed an opportunity to allow secure self-signed certificates.

The new CloudFlare SSL setup allows the origin server to present to CloudFlare's servers either (i) an unverified self-signed certificates; or (ii) a certificate signed by a CA. Neither provides great security. In the former case, a MITM can trivially generate a new self-signed certificate. History has shown the latter case is also problematic, as there have been several events where CAs have generated invalid keys [1].

What would be nice is if I could generate a self-signed certificate and upload the fingerprint(s) to CloudFlare. CloudFlare would could then verify the fingerprint when connecting to my origin server, without needing to trust a CA.

Am I missing anything obvious as to why this wouldn't be as secure (or more secure) than the two options CloudFlare has introduced?

[1]: For instance: http://googleonlinesecurity.blogspot.com.au/2013/12/further-improving-digital-certificate.html

The problem I see with this blog post is something I haven't seen mentioned in the comments. It's not GitHub's place to set policy on what kind of disclosure is or isn't "responsible". Egor Homakov's responsibility is not to GitHub; his responsibility is to other users. His moral duty upon finding a security vulnerability is to act in such a way that other users will be minimally hurt. It appears that he has fulfilled that responsibility spectacularly in this case.

GitHub has no business demanding his, or your, agreement to a legal contract that prohibits you from exercising your best judgment in such a case.

Furthermore, "responsible disclosure" is a propaganda euphemism for "allowing irresponsible vendors to cover their asses, possibly at the expense of their users". Terms like "responsible disclosure" have no place in a serious discussion. Please see the blog post by the Google security team at http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html for further details.