Hacker News Reader

Comment by bhouston | Hacker News Reader

Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes?

The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not.

Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA.

Remember that the Snowden docs says that the NSA can break SSL/TLS/https/VPN, etc., but we do not know the full details: http://blog.cryptographyengineering.com/2013/12/how-does-nsa... But the one thing all of these technologies (SSL,TLS,https,VPNs) have in common is usually OpenSSL.

View on HN

There's a talk that was given in Belgium / Brussels at FOSDEM2014 two months ago or so by Poul-Henning Kamp (FreeBSD) regarding the NSA and how he'd do it if he had to create holes in software:

http://www.youtube.com/watch?v=fwcl17Q0bpk

He's talking specifically about OpenSSL quite a lot (basically saying it's too complex to ever be secure and probably received many "security patches" from NSA employees).

The entire talk is an eye opener. He explains how NSA shills are reading reddit / HN and poisoning communities / standards / protocols / etc. How everything is made, on purpose, needlessly complex to prevent honest developers from working on important things.

He talks about shills submitting a few correct patches over the months / years, slowly gaining reputation among the community and then misusing that trust to submit (not so) subtle patches introducing security holes on purpose.

He mentions a few of the "common mantra" repeated often (including here) by people who have an interest in the status quo.

He explains why SSL/TLS is broken and says that the "SEC" part of "DNSSEC" is not going to be that secure ; )

I think that the problem is much worse than most people think and that Poul-Henning Kamp is closer to the truth than the ones constantly repeating "bug happens" as if nothing malicious was ever going on.

Too be fair it is obviously intended to be a talk on what could be happening and not what certainly is.

It is, however, reasonable to assume that "they" are as smart as we are, so "how would I do it" analysis is quite called for.

Yes, but it's not reasonable to assume that our armchair "how I would do it" theorizing is, in fact, how they would do it. We can assume that they have come up with the idea, but maybe they discarded it for reasons that aren't obvious to us.

> How everything is made, on purpose, needlessly complex to prevent honest developers from working on important things.

Ah, so that's why OpenSSL is not implemented as a RoR web application with REST-API and Cucumber tests in a TDD way so that Johnny Webmonkey can easily contribute. I always assumed it had to do with portability and performance.

> How everything is made, on purpose, needlessly complex to prevent honest developers from working on important things.

Developers are quite willing and able to do this all on their own. Feature/scope creep is pretty horrible these days.

I'm watching this right now, it's brilliant! This is exactly the kind of stuff I love to think about, but PHK has done a wonderful job thinking it out to a lot of detail. I suggest everyone drop what you're doing and watch it asap. It's exciting and really holds your interest.

I did watch, thanks, but anyone in a hurry can get just the slides here: http://phk.freebsd.dk/_downloads/FOSDEM_2014.pdf

I particularly appreciated the "QUEEN success example: SSC" (self-signed certificates, starts at slide 23), which also got a good laugh from the audience ...

(if you're just watching the video, this is the text of the second slide in the PDF, not shown at FOSDEM:

""" What is this ?

This is a ficticious NSA briefing I gave as the closing keynote at FOSDEM 2014

The intent was to make people laugh and think, but I challenge anybody to prove it untrue.

Playlist spoiler:

Electric Light ORCHESTRA: Confusion

ABBA: Money, Money, Money

Backman Turner OVERDRIVE: Taking Care Of Business

QUEEN: Bicycle Race

Beastie BOYS: Sabotage

PASADENA Roof Orchestra: Pennies From Heaven """ )

Reality is NSA has to do very very little to make this happen. Tiny nudges here and there. Profit motive encourages people to move towards complexity. Simple software commodifies too quickly.

Here's an interesting thought.

The NSA isn't the only entity who could stand to benefit from a privately held exploit to most SSL implementations. The NSA is also not the only group who could actually accomplish this.

Who's to say there aren't groups out there that are doing this already to steal and profit from corporate information, credit cards, etc.?

Sorry to introduce the hyperbole, or not moderate it.

When the government runs a campaign to cause the public to fear and doubt your neighbor that is the beginning of a dark time ahead. This idea that they are one of you, or someone on reddit is just poison.

On an emotional level, more and more Edward Showden is becoming a mystical figure.

The heartbleed bug looks exactly like an NSA backdoor:

* the protocol extension rfc and implementation are from the same person (who is now working for the largest German IT service contractor; formerly state owned T-Systems).

* the extension provides means for one party to send arbitrary data which needs to be returned - a keepalive mechanism would have worked with an empty packet

* there is no input validation on network originated data, in a crypto library, in 2011

This has huge implications on all of the Internet, while the individual parts being reasonably deniable.

* T-Systems was never state-owned. The German Federal Post used to be state owned but was split into separate post, communications and banking divisions in 1995. Deutsche Telekom IPO'd in 1996. T-Systems was founded in 2000 as a subsidiary of Deutsche Telekom. The German state currently holds around 15% of Deutsche Telekom stock.

* RFC 6520 was published in February 2012. At that time Robin Seggelmann wasn't employed by T-Systems but was instead writing his dissertation at the University of Duisburg-Essen [1].

* His dissertation [2] actually gives an explanation for the payload:

"The payload of the HeartbeatRequest can be chosen by the implementation, for example simple sequence numbers or something more elaborate. The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport."

[1] http://www.robin-seggelmann.de/

[2] http://duepublico.uni-duisburg-essen.de/servlets/DerivateSer...

This is the first that I've had time to actually sit down and look at code, the RFC, etc, and I'm scratching my head.

The rationale for the payload for DTLS (sent over UDP) is reasonable, but I'm scratching my head over why the payload is even there for TLS. I guess there's some logic in making the protocol the same irrespective of underlying transport, but the payload is completely redundant for reliable protocols, which will handle any retransmission or reordering automatically.

Edit: Upon further (amateur and arguably ill-informed) reflection I'd argue that the heartbeat functionality shouldn't apply to TLS at all. It's needless complexity that can be handled by the underlying reliable transport. That doesn't change that the OpenSSL project clearly has code-quality issues, but it would have averted this particular fiasco, at least.

I am dismayed that a security-oriented protocol isn't focused on minimalast design. That seems very backward to me.

It's easy to see why, without the benefit of hindsight, one might think that the minimal approach was to have the same extensions apply to both DTLS and TLS.

I don't know where to go look (mailing list archives? meeting minutes?) to find any discussion about this extension (I'm woefully ignorant of Internet standards processes), but it would certainly be nice to review that discussion.

Given the rather dramatic differences that need to occur in a protocol designed to work over unreliable versus reliable transport, though, it seems like a bad idea to try to keep "parity" between DTLS and TLS. I can see how somebody might see it as "elegant" to do so, but I'd argue they're different animals solving different problems.

Maybe the payload is used for a sequential id number?

If you ever implement connection oriented protocols, you will very quickly find the need for a heartbeat mechanism - otherwise you have no way of telling whether the remote end is dead, or if is just busy creating data for you/doesn't have any data for you right now.

Not having heartbeats, you end up relying only on arbitrary timers to time out your connections, which are far from optimal, or you end up relying only on the underlying protocol which is not enough in most cases.

TCP doesn't provide that for you. (TCP does provide keepalives, intended for other means, they might be a poor mans substitute, but they arn't exposed to the TCP user in a particularly useful way - it's also the wrong layer for this problem)

I'm familiar with the paradigm. I've written some code to talk to dodgy embedded devices that don't "talk" unless they have something to say and I have ended up having to use timers. It sucks, to be sure.

I looked back to RFC1122 to get a feel for the nature of TCP keepalives, and I would agree that they're unsuitable for this application.

If we posit that a keepalive mechanism is useful for TLS I'd still argue that a payload is unnecessary because TCP will handle in-order delivery. A NOOP with some random-length padding would have worked just as well.

TCP heartbeats certainly will let you know if the remote end is entirely dead.

They won't let you know if the application process is jammed up --- but TLS hearbeats won't do that for you either! (For example, it's common to have the crypto handled by front-end processes, with the application logic elsewhere.) So if that's what you want, then you need heartbeats at the application layer, not in TLS.

Given all that, the case for hearbeats at the TLS layer for TLS over TCP seems ... weak. Particularly since simply having them there violates the commonly cited best practice that security kernels should be kept small. And this violation has already had disastrous consequences.

Besides, for all the times I see people making this argument, I've yet to see them cite an example of a real problem in a real world deployment for which TLS hearbeats were used, and turned out to be the best solution.

It seems odd to, in a security context, say "The payload of the HeartbeatRequest can be chosen by the implementation", giving a huge amount of freedom to implementers (apparently it was determined that "something more elaborate" might extend to an implementation needing to send a full 64K of chosen payload data) without further investigating whether any particular choices made by the implementation might have consequences for the security of the protocol.

Why allow variable length payloads at all? Why allow more than about 128 bits of data for distinguishing responses? I guess you might argue a client might want to disguise the nature of these heartbeat packets from an eavesdropper, so they need to be variable in size - that's reasonable, but if it's a requirement, then surely you'd want to comment on the security risk of using a "simple sequence of numbers" rather than "something more elaborate". 64K of data, though? That seems like a lot of leeway to give an implementation - considerably more than enough to disambiguate heartbeat packets; implementations are going to keep 64K of data around and compare it byte for byte to check whether the echo they got back matches the payload they transmitted earlier?

I really don't mean to ascribe malice here; I tend to assume this is just a bug, and that the payload for heartbeat packets gets to be up to 64K because once you've decided to make something a variable length buffer, you're probably choosing between having a one byte or a two byte field for length, and 256 bytes seems like it might be too small so you figure 'why not make the length field two bytes?' and then... oops; someone makes a buffer overrun and suddenly we're faced with 64K at a time of data being ripped out of any old server's heap.

I wonder if it's simply that the DTLS heartbeat is modeled on the ICMP echo-request packet? Pings also contain a blob of up to 64kB of arbitrary data (in the case of ICMP, this is/was handy for detecting pattern-dependent link problems). Unlike DTLS, though, the length of the payload is determined by the enclosing protocol, not redundantly by a length field in the packet itself.

If he's working for a German firm now, it wouldn't be an NSA backdoor. Maybe the US isn't the only government with an eye on developing these exploits.

I think the intended implication is that he would be an agent for the NSA within that firm. Your second sentence stands however.

There is absolutely no basis for such an inference. It could have been a one off job, he could be undercover, etc. In fact if I were a clandestine organization I would definitely try to recruit people from other countries to make matters appear less obvious.

http://en.wikipedia.org/wiki/Hanlon's_razor

This bug is too general and too wide open to be deliberate. Any college student could write code this shitty. An engineered flaw would have to be more subtle.

Check out phk's fosdem talk[0]. I've linked to the the part where he talks about openSSL, but I'd suggest watching the whole thing. I'm now starting to believe the talk wasn't a joke at all...

[0] https://www.youtube.com/watch?v=fwcl17Q0bpk&feature=youtu.be...

Because it wasn't.

I was there at the talk and while he put a humorous spin on it by playing the part of a NSA agent, it's also extremely insightful to see it from that point of view. And yeah, when you really think about it... OpenSSL is the NSA's playtoy.

Of course, there's no way to prove that. But really, does it matter? Whether the NSA is behind OpenSSL sucking or not... we have to assume they know of several backdoors/exploits, and the OpenSSL API still sucks and prevents people from doing productive crypto.

Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy.

That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible.

Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.

> no need for tinfoil hat theories

For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 http://nation.time.com/2013/11/04/google-shocked-the-nsa-hac... http://www.reuters.com/article/2014/03/31/us-usa-security-ns... https://www.techdirt.com/articles/20130909/11430124454/john-...

There is a difference between infiltrating companies and deliberately introducing a bug that compromises a large chunk of the Internet. I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

Perhaps they assume all software is buggy, so they may as well own the bugs?

I would assume the NSA always assumed (note past tense) that their secrets stay pretty secret, and their wide-open backdoors will not get knockers.

They don't assume that.

I don't see why people think that NSA is simultaneously genius-level forces of the Illumanti architecting events that will culminate years later, and yet would make the rookie level mistake of introducing a backdoor that is protected only by obscurity.

They know other security services understand how to decompile code (or read the original source).

More importantly, they know that critical government services they can't predict will end up possibly running things like their broken version of OpenSSL. There's a FIPS standard, of course, but note that the Heartbleed page made quite clear that FIPS is vulnerable too.

> I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

Don't we actually already have evidence of other cases of the NSA adding backdoors to widely used systems, exploitable by anyone aware of them? Isn't that what the elliptic curve backdoor was? http://www.wired.com/2013/09/nsa-backdoor/all/

Apparently your assumption is quite not safe to assume.

I guess the NSA either figures nobody else will notice the backdoor, or just doesn't care. I guess only they know their motivations.

The mooted backdoor in the Dual-ECDRBG involves the possibility that the public parameters were generated based on some secret values, such that knowing the secret values allows you to break the generator.

It doesn't allow just anyone to break it - merely knowing the backdoor is there isn't enough.

> the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

If possible, yes. However, if they were indeed responsible for this, they'd probably have a couple honeypots to detect exploitation by third parties. If they considered the third party harmless, they could decide whether the vulnerability should be "independently discovered" or not.

Planting a complicated exploit would be harder and increase the risk it could be traced back to them.

On the other hand, if the NSA pwned OpenSSL, shouldn't such a big thing have been in Snowden's docs?

The NSA, according to the Snowden docs, can break SSL. No details though: http://blog.cryptographyengineering.com/2013/12/how-does-nsa...

Those documents do not say they can break SSL. They say they focus on SSL, and can break some specific SSL-using services.

Would the specific be the version of openssl being used by the 'target'?

Can't look right now but was this 'bug' introduced at some point in time?

This bug was added 2 years ago, the Snowden documents are from before that, as far as I know.

It could be. Only a percentage of the documents have been analysed so far.

Snowdon might not have known every implementation detail.

"the absence of evidence is not the evidence of absence"

http://en.wikipedia.org/wiki/Argument_from_ignorance

Actually, it is (a weak form of bayesian ~).

http://ojs.uwindsor.ca/ojs/leddy/index.php/informal_logic/ar...

http://lesswrong.com/lw/ih/absence_of_evidence_is_evidence_o...

Interesting. However, your sources are rather obscure, and I'm not sure what you mean by "a weak form."

I'd say a Baysian analysis is a way to evaluate the veracity of an argument from ignorance, not necessarily a replacement of that argument. An argument from ignorance is a strict subset of a baysian analysis in which there is no causal relationship between the missing evidence, and the conclusion. This is such a case. So we can conclude by using a baysian analysis that this is in fact an argument of ignorance.

Unless, of course, you have additional statistical samples that show a non zero relationship between not knowing about NSAs activity and the fact that they are engaged in that activity.

In Snowden's TED talk he said that the best reporting is yet to come.

http://www.ted.com/talks/edward_snowden_here_s_how_we_take_b...

You have kept up to date with the news, right? Truecrypt, RSA... OpenSSL is low-hanging fruit by comparison. Of course it's back doored - probably more than once.

You're right that it needs cleaning - it needs a full audit. I'm surprised in the light of the Snowden revelations that none of us have suggested this sooner, but hindsight is a bitch and all that.

Lots of people have suggested it. Very few people have dedicated their time to helping do it, though. Welcome to the 'other people should do this' club!

I don't know what the gp's skills are, but assuming he's not a computer security professional then the 'other people should do this' club is exactly the club he should be in. Would you trust his audit of the code if he wasn't heavily experienced? it's the same case as "don't roll your own crypto".

There's a difference between "trusting his audit of the code" and "trusting his code". Any interested and motivated person can audit code. If nothing is found, that might not prove much. But if a vulnerability is found, the audit was worthwhile from some perspective.

Sure, so long as the bug is a genuine bug and not a misunderstanding. Debian's openssh valgrind warning springs to mind. Crypto implementations can be subtle and non obvious. Maybe it's crap design for that reason, but it seems like it's what we've got to work with currently.

That bug affected OpenSSL as well. Admittedly, it was caused by the Debian maintainer, but still, OpenSSL's poor design is partially to blame.

Kickstart it ?

Was there an issue with truecrypt?

http://www.computerworld.com/s/article/9243873/NSA_spying_pr...

So nothing specific or proven actually?

> Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.

https://xkcd.com/927/

There are very few competent FOSS crypto implementers, and unfortunately, they're spread very thinly. I'm not sure that having yet one another crypto library is going to be helpful unless we actively move our users to the new library and kill the old projects.

Another irrelevant xkcd comment...

Stop posting this xkcd. Seriously. It's not funny, it's not witty, it's old as hell and it does not make sense.

What would evidence of conspiracy look like? Do we need comments in the code, "this is an NSA back door...", seriously?

>You have to be backwords compatible

we have been making this trade off for years and it wont get any easier in the future, its about time we started a fresh initiative that doesn't make backwords compatibility a priority, except of course in the sense of maintainability moving forward.

In this post-Snowden era I believe Occam's razor yields a different result about NSA interference.

> Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy.

But we do have "evidence for conspiracy". We known for certain that there are organizations with huge budgets that have introducing such vulnerabilities pretty much written into their mission statements. Why would we assume they would not be involved in something they obviously should be (however perverted their goals are)? It would be grossly incompetent of the NSA not to try introducing bugs into OpenSSL.

IETF already has chairs that work for NSA, which they refuse to get rid of.

Sounds like it's time to create a competing group that issues standards for the internet.

I think now would be great time to reconsider the OpenBSD ipsec debacle in this kind of new light. Correct me if I'm wrong, but doesn't ssh use openssl libraries and the openbsd guys were heavily involved in openssl's development? A lot of people think the closed audit that found a minor unintentional bug was the last word on this subject, but the orginal guy who made the claim posted in 2012 further explaining how the FBI had made this attempt.

Can't wait to find out SSH is comprimised too!

openssl was not created by the same people behind openbsd.

You are correct, just got done reading Theo's rants on the subject and realized I was mistaken, so apologies. The same style of potential subversion may be at hand, regardless.

Even the name "Heartbeat" sounds like something NSA would name it.

What would it sound like if it were named to indicate signs of life?

Reply on news.ycombinator.com