I think if James Clapper or Keith Alexander joined the board of DropBox you'd see the same issues. But they haven't.

Being a donor to one of two political choices (or often both) is one thing. That's very, very far removed from power. Actually having started wars whilst being Secretary of State is entirely different.

She gave speeches strongly advocating war in Iraq, and was an integral part of the whole process that led to a war which killed over 100,000 people. It was later solidly established that the people at the very top of the Bush administration knew their excuses for war were BS and kept repeating them anyway, and ignoring all the evidence that they were wrong.

I keep reading about how intelligent this woman is. But given the things she's done, she sounds pretty goddamn dumb to me. It's not everyone who can say their mistakes led directly to mass death.

Much though I love NSA related conspiracy theories, especially lately, I think "the NSA writes a pile of crap and gives it away for free in the hope it becomes inexplicably popular" is perhaps not the best one available. OpenSSL has been around for a loooong time with virtually no resources put into it, which is one reason it sucks. The other reason being that the original author wrote OpenSSL in order to teach himself C (and it shows).

Recall that SSL was not very widely used up until a few years ago, and it's only in the last 18 months that suddenly every man and his dog wants a secure website. It's not surprising that core libraries that do it are subpar. Even very large companies like Google or Microsoft have typically only had one or two people who really understood and cared about SSL.

Unpopular though it is, if you can take a small(ish) performance hit, you could use a Java HTTPS server that proxies to your app. The Sun/Oracle JSSE SSL stack (in the Oracle VM, not Android) is pure Java and thus immune to these sorts of errors. In JDK8 it supports TLS 1.2, ECDSA, perfect forward secrecy and the use of AES-NI for hardware accelerated constant time stream ciphering.

I would say it is a problem with mailing lists. They are taking mail, rewriting it to say something different, then delivering it in such a way that they claim they didn't change it (with broken digital signatures). This isn't Yahoo breaking mailing lists. This is just mailing lists doing something stupid. The fix is for them to stop doing MITM attacks on people's mail or to do it, but to resign the mail themselves so they take responsibility for it.

It's not like DKIM is new by the way, mailing list developers and admins have had this coming for years. But you won't find a more backward or stubborn bunch than crusty postmasters who ran mailing lists the same way since the 80's.

Blah blah blah.

Java 8 has a full SSL stack written in Java itself, so no buffer overflows there, and which uses AES-NI for hardware accelerated encryption if available. It also supports perfect forward secrecy and other modern features (no session tickets though).

If you look at the CVE history of JSSE what you will find is that occasional bugs like the Heartbleed attack (not checking length fields correctly) get reported as denial of service issues because they cause managed exceptions that might, if you wrote your code non-defensively, cause your server app to quit. Or they might just cause the connection to drop, which is the right behaviour.

It's about a million times safer than an ancient piece of 1980's style C like OpenSSL.

I don't think Chrome uses OpenSSL, although they are thinking about switching to it. They use NSS, same as Firefox. I'm not sure any browsers use OpenSSL - it's mostly used on the server.

I feel your pain, but I'm not sure the people complaining in this thread understand the sheer size of YouTube. It's literally the entire worlds video repository. There are over 100 hours of video uploaded every minute. Over 100 hours! Even if YouTube employed an entire army of specialised copyright lawyers trained in the international nuances of fair use, there's no possible way the enormous number of disputes could ever be mediated in a fair way.

When you upload to YouTube, you get a lot of stuff for free, but you don't have to use them. You could host the video yourself and then the disputes would come to you directly instead of being auto-resolved by a machine. If you aren't willing to pay the costs of doing that, then you need to accept the consequences of YouTube's razor-thin profit margins and vast economies of scale.

Many years ago there was an R&D project inside a large tech company. It was exploring many of the hot research topics of the day, topics like mobile code, type based security, distributed computing and just in time compilation using "virtual machines". This project became Java.

Were all these ideas actually good? Arguably, no. Mobile code turned out to be harder to do securely than anyone had imagined, to the extent that all attempts to sandbox malicious programs of any complexity have repeatedly failed. Integrating distributed computing into the core of an OO language invariably caused problems due to the super leaky abstraction, for instance, normal languages typically have no way to impose a deadline on a method call written in the standard manner.

Just in time compilation was perhaps one of the worst ideas of all. Take a complex memory and CPU intensive program, like an optimising compiler, and run it over and over again on cheap consumer hardware? Throw away the results each time the user quits and do it all again when they next start it up? Brilliant, sounds like just the thing we all need!

But unfortunately the obvious conceptual problems with just in time compilers did not kill Java's love for it, because writing them was kind of fun and hey, Sun wasn't going to make any major changes in Java's direction after launch - that might imply it was imperfect, or that they made a mistake. And it was successful despite JITC. So when Microsoft decided to clone Java, they wanted to copy a formula that worked, and the JITC concept came along for the ride.

Now, many years later, people are starting to realise that perhaps this wasn't such a great idea after all. .NET Native sounds like a great thing, except it's also an obvious thing that should have been the way .NET worked right from the start. Android is also moving to a hybrid "compile to native at install time" model with the new ART runtime, but at least Android has the excuse that they wanted to optimise for memory and a slow interpreter seemed like the best way to do that. The .NET and Java guys have no such excuses.

Perhaps I will phrase the question in a more helpful manner.

Let's take it as read that you are indeed a (possibly former) Intel employee who worked on RDRAND. Given the black box nature of the RNG and the fact that some time ago someone posted anonymously to Slashdot claiming that a small number of chips were jinxed so that RDRAND was predictable, do you know of a good way to rebuild confidence in the integrity of a particular chips RNG?

More generally, do you have any interesting thoughts on the topic of building trust in blackbox hardware, whether it be an RNG or otherwise (e.g. Intel SGX)?

Hey Kasper,

It's Mike H, remember me? We used to work together in SRE ;) How is the startup going? I have also recently moved on from the big G.

Now. When this thing first started to bubble up, I didn't feel very concerned either. OK, so I got fewer emails from recruiters than otherwise would. No big deal, not like there was exactly a shortage of those.

However, I just want to point out one thing:

I would only consider there to be a real problem, if facebook would reject resumes submitted by candidates, just because they happened to work for Google. I have seen no evidence of such a practice existing.

Did you read the article? It seems that the only reason such a situation did not occur is because Sandberg told Google to pound sand. During the time in question, these emails clearly show that a very senior Google executive was directly asking Facebook not to hire Google employees, even if they employees in question wanted to go work there and what's more, good corporate relations were being pegged to that demand.

I must admit, I never knew much about Rosenberg and don't have many memories of him (can't even recall what he looks like). But regardless, this paints Google in a very negative light indeed. Rosenberg was willing to threaten other companies in order to make them stop not just pursuing but actually hiring "his" people. Facebook refused, but who knows what other companies didn't? Was that really the only time he took that approach? Was this a Rosenberg-specific moment of madness/idiocy or does it run deeper? I await further discovery with great interest. Even if this was a brief failure on the behalf of just one executive, that's still completely unacceptable and Rosenberg needs to be fired, now. Employees are not assets whose freedom of employment can be traded for corporate deals and to treat them that way is completely unacceptable.

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

Can you please prove this? Unless you're using a very flexible definition of "all the time", there is no publicly known evidence for this point of view. There are millions of certificates in the world and the number of bad certs is low enough that people can enumerate all the compromises on wiki pages.

HSTS is designed to solve the problem of people not requesting encrypted sites.

You realise you can do key pinning in SSL as well, right? The point of certificates is to let you find out a public key when you don't have advance knowledge. Certainly for mobile apps, there's no requirement that the app trusts any CA.

Fail. SSH has been researched and discovered to not work.

We monitored SSH logs to analyze user behavior when our system adminis- trators changed the SSH host key on a popular server within our department. The server’s public key had remained static for over two years and thus expected to be installed at most user’s machines. Over 70 users attempted to login over the server after the key change during the monitored period. We found that less than 10% of the users asked the administrators if there was a key change and none verified the actual key.

SSL is a hell of a lot better at stopping MITM attacks than anything else humanity has created. Certainly SSH does not even qualify.