[deleted]
"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
41–50 of 245 posts
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#42Earlier quoted context omitted.
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…
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.
Kickstart it ?
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#43Has 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…
IETF already has chairs that work for NSA, which they refuse to get rid of.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#44This should be a case study about why people developing system-critical software shouldn't write their own memory allocators.
At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.
The discouraging of everybody who wants to provide an alternative only locks us in to supershitty software that got there first. Worst is Better reigns.
I mean, there is an extremely small chance that anybody will adopt your library if it is unquestionably better than the dominant alternative. We don't actually need to discourage people, we need to do everything to encourage them. Sure, 99 of 100 will be no better than our present crap. What does it matter? Few will adopt it anyway. The tragedy is that the better alternatives will probably meet the same fate.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#45So 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.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#46Earlier quoted context omitted.
No, that's essential, that line is the message. A secure library should be defensive in coding style and implementation, not sloppy. It should have defaults that err on the safe side, not the fast side, if you have to choose.
It's a massive open source project that's more than 15 years in the making and supports a massive range of architectures and ever-moving standards. Shit happens, we need to figure out how to make sure it won't happen again at this scale, there's really no need for name calling.
We need to stop have such a fucking accepting attitude about sloppy engineering in security-critical code. People who don't want to be held to a high standard should get out of there and go do something that can't break the internet.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#47Earlier quoted context omitted.
At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.
The discouraging of everybody who wants to provide an alternative only locks us in to supershitty software that got there first. Worst is Better reigns. I mean, there is an extremely small chance that anybody will adopt your library if it is unquestionably better than the dominant alternative. We don't actually need to discourage people, we need to do everything to encourage them. Sure, 99 of 100 will be no better th…
"nobody" is not an absolute here. It's a reminder that the vast majority of people who get the idea to write their own memory allocator, garbage collection or filesystem will do an even worse job at it than the people who implemented the ones we typically use did, but it will end up going mostly unnoticed and possibly make it into some critical piece of software.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#48Earlier quoted context omitted.
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…
> 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.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#49This should be a case study about why people developing system-critical software shouldn't write their own memory allocators.
At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.
I don't understand this attitude, if something is incredibly complex and very hard to get right, this can indicate that there is a mismatch between the tools you use to implement it and what you should use.
With the right language it might be much more pleasant to implement:
Consider for example https://github.com/GaloisInc/halfs a filesystem implemented in Haskell, I think it has ~10000loc
It can also mean that existing implementations are poorly documented and research papers on the subject place no importance on implementation details. Of course you should not use your first implementation in production, but that is as obvious as not letting someone do brain surgery who has no prior training in it.
Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"
#50This 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 know I'm replying to a troll, but... you have been following the news, right? Would you rather have us use the backdoored RSA bSAFE library? That was developed by paid professionals, who by your logic should be the paragons of competence.
All software has bugs.