Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

article.gmane.org

Post reply on HN
Print view View original

61–70 of 245 posts

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#61

Post by zmguy »

stiff wrote: post #54

It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github…

Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#62

Post by scrollaway »

ensmotko wrote: post #31
bhouston wrote: post #21

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 se…

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.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#63

Post by TacticalCoder »

bhouston wrote: post #21

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 se…

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.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#64

Post by doctorfoo »

this_user wrote: post #48
bhouston wrote: post #26

Earlier quoted context omitted.

> no need for tinfoil hat theories 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. For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 htt…

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?

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#65

Post by this_user »

ge0rg wrote: post #24
bhouston wrote: post #21

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 se…

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 n…

* 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...

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#66

Post by [deleted] »

stiff wrote: post #54

It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github…

[deleted]

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#67

Post by dlitz »

simias wrote: post #23
bhouston wrote: post #21

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 se…

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 bu…

> 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.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#68

Post by ctz »

higherpurpose wrote: post #45
robin_reala wrote: post #4

So what are the options then if OpenSSL isn’t fit for purpose? Is it possible to move wholesale to a different project? Are any of them trying to ease migration over from OpenSSL to themselves?

libsodium, which is a cross-platform version of Dan Berstein's NaCl.

This is not a TLS stack.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#69

Post by amboar »

joosters wrote: post #40
madaxe_again wrote: post #35

Earlier quoted context omitted.

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".

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#70

Post by reidrac »

recentdarkness wrote: post #37
reidrac wrote: post #8

Earlier quoted context omitted.

cURL makes a nice comparison: http://curl.haxx.se/docs/ssl-compared.html GnuTLS had its own problems recently (see: http://www.gnutls.org/security.html ), and regarding NSS... I couldn't find a proper public "security" page for it (eg, release notes for 3.16 point to CVE-2014-1492; but the link to the bugzilla issue is not public), so I don't know. Obviously a good security record doesn't imply things like a good cod…

Regarding the NSS CVE-2014-1492: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-14... Quote: "The cert_TestHostName function in lib/certdb/certdb.c in the certificate-checking implementation in Mozilla Network Security Services (NSS) before 3.16 accepts a wildcard character that is embedded in an internationalized domain name's U-label, which might allow man-in-the-middle attackers to spoof SSL servers via…

Thanks, I can look for a CVE myself ;)

My point is that having a proper security page is a good practice and I really appreciate it as user.

Post reply on HN