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

81–90 of 245 posts

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

#81

Post by davidw »

icebraining wrote: post #79
davidw wrote: post #39

Earlier quoted context omitted.

This sums up some of the difficulties with the production of open source software: https://en.wikipedia.org/wiki/Public_good

If this is a consequence of the difficulties with the production of open source software, does that mean there are much more secure proprietary implementations of SSL/TLS? Which ones?

A quick search with Google reveals various commercial SSL implementations. I have no idea how good they are.

Most people probably think openssl is good enough and are not willing to pay for something else.

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

#82

Post by ig1 »

zmguy wrote: post #61
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?

A number of the OpenSSL team are employed by large tech companies to work on OpenSSL. For example Bodo Möller and Ben Laurie work for Google.

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

#83

Post by EvanAnderson »

this_user wrote: post #65
ge0rg wrote: post #24

Earlier quoted context omitted.

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…

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.

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

#84

Post by _pmf_ »

TacticalCoder wrote: post #63
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…

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

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

#85

Post by naveen99 »

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?

I suggest using Wei Dai's http://www.cryptopp.com as a new starting point for all low level crypto.

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

#86

Post by higherpurpose »

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…

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

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

#87

Post by joshuak »

kryptiskt wrote: post #53
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…

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

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

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

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

#88

Post by motters »

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…

My attitude towards complaints about open source projects is that if you think the errors are rudimentary then just submit some patches. If there is not enough test coverage then add one. This applies especially if you believe that the project is critically important.

I think what might be happening here is expert syndrome. People may be told that if they're not experts then they shouldn't be reviewing or changing the code.

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

#89

Post by obsurveyor »

TacticalCoder wrote: post #63
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…

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

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

#90

Post by supersnap »

goldenkey wrote: post #55
supersnap wrote: post #33

This is pretty much proof that open source fails to maintain security software in a responsible way. Look kids ssl is not that hard to implement. Time to let the cargo cult go have a campfire and sing songs. This is too important to leave to lazy paid for nothing programmers who want to write lazy ass c code after too many beers. Grow up

I guess we should just let you code it in Enterprise java and pay you dividends.. Get a hold of yourself - most open source is actually funded by large companies in the first place. And being drunk has nothing to do with bad code, I for one code better when inebriated. Your straw man banter doesn't need to be on HN.

Java has nothing to do with it. Untrusted input is untrusted input. Any moron can figure that out.

OpenSSL, no code review, no tests, and bad code.

Why are we responsible for finding these bugs?

And no just FYI my code has no bugs

Post reply on HN