The problem is not the cost of fixing a bug.
The problem is the cost of the bug being exploited on a very large scale.
It seems that we currently have some diversity, not every SSL transactions on the earth are handled by OpenSSL, and I hope it will never happen.
The people building the "black box" need to know what they're doing and it needs to work. Period.
But human nature prevent it, we know for quite a long time that software is never perfect and that security is never absolute.
Diversity is the solution mother nature is using.
I've wrote quite a lot of backend/server code, but I tend to use non-standard code to avoid vulnerability.
Interoperability/Common Standards is a very good thing, but we don't have to all use the same implementation.
Also, never trust something you don't understand.
This is not a problem with OpenSSL, or the C Language or the Malloc implementation, this is a problem because everyone is relying on the same black box they do not understand.
Because this is "standard" and common practice to use it.
The only long term defense against this kind of vulnerability is software (and hardware?) diversity.
Software built on custom SSL implementations may have even worse vulnerabilities, but nobody will discover them, and even if they do, it won't affect everyone on this planet.
When I read Theo De Raadt, I fear his "solution" may only worsen the problem.
We can't have all our secrets protected by the exact same door, no matter how strong the door is, once it's broken...
Slashdot Mirror
The problem is not the cost of fixing a bug. The problem is the cost of the bug being exploited on a very large scale. It seems that we currently have some diversity, not every SSL transactions on the earth are handled by OpenSSL, and I hope it will never happen.
The people building the "black box" need to know what they're doing and it needs to work. Period.
But human nature prevent it, we know for quite a long time that software is never perfect and that security is never absolute. Diversity is the solution mother nature is using. I've wrote quite a lot of backend/server code, but I tend to use non-standard code to avoid vulnerability. Interoperability/Common Standards is a very good thing, but we don't have to all use the same implementation. Also, never trust something you don't understand.
This is not a problem with OpenSSL, or the C Language or the Malloc implementation, this is a problem because everyone is relying on the same black box they do not understand. Because this is "standard" and common practice to use it. The only long term defense against this kind of vulnerability is software (and hardware?) diversity. Software built on custom SSL implementations may have even worse vulnerabilities, but nobody will discover them, and even if they do, it won't affect everyone on this planet. When I read Theo De Raadt, I fear his "solution" may only worsen the problem. We can't have all our secrets protected by the exact same door, no matter how strong the door is, once it's broken...