4 ms·

Google had more than 20 years for auditing OpenSSL and submitting patches. It didn't. Instead NIH solutions are now popping up after having exploited OpenSSL f

by cllg 5y ago

Google had more than 20 years for auditing OpenSSL and submitting patches. It didn't. Instead NIH solutions are now popping up after having exploited OpenSSL for more than two decades.

Tuna-Fish 5y ago
Well, yes. It's still better to start doing the right thing late than never? > Instead NIH solutions are now popping up after having exploited OpenSSL for more than two decades. Building new crypto libraries to replace OpenSSL is not caused by NIH, it's caused by rationally examining the existing codebase and coming to the conclusion that sometimes starting from scratch is the sane choice. Google is doing the incremental fixing approach (in BoringSSL) too, but it's very clearly a stopgap.
pizzazzaro 5y ago
Google has been using their own "BoringSSL" for a while internally. But the fact is? OpenSSL has reached an age where we go about 12 months between severe vulnerabilities. The code itself is built on compromises that made sense in a different era, with major changes bolted on. And then more changes bolted on top of that. And then again, more bolted on top of that. Losing wide-scale Linux adoption of LibreSSL? Has left us more dangerously monocultured. GnuTLS exists. OpenSSH exists. But each finds itself most applicable in different circumstances. LibreSSL was a relatively drop in replacement, but the lack of TLS3 support? Later ended up killing serious Linux support. There was so much code to audit, overhaul, rewrite, or simply remove? That the team writing it still has their work cut out for them, before TLS 3 support can even be considered. https://www.libressl.org/goals.html https://www.libressl.org/goals.html So to see Google help put an auditable, open, safe-language alternative out there? It is a fascinating move. Im suspicious that google's involved, same as you. But so long as it is auditable? And someone more trustworthy is at the helm, keeping it honest? Im excited to see this exist.

by cllg 5y ago

Google had more than 20 years for auditing OpenSSL and submitting patches. It didn't. Instead NIH solutions are now popping up after having exploited OpenSSL for more than two decades.

Tuna-Fish 5y ago

Well, yes. It's still better to start doing the right thing late than never? > Instead NIH solutions are now popping up after having exploited OpenSSL for more than two decades. Building new crypto libraries to replace OpenSSL is not caused by NIH, it's caused by rationally examining the existing codebase and coming to the conclusion that sometimes starting from scratch is the sane choice. Google is doing the incremental fixing approach (in BoringSSL) too, but it's very clearly a stopgap.

pizzazzaro 5y ago

Google has been using their own "BoringSSL" for a while internally. But the fact is? OpenSSL has reached an age where we go about 12 months between severe vulnerabilities. The code itself is built on compromises that made sense in a different era, with major changes bolted on. And then more changes bolted on top of that. And then again, more bolted on top of that. Losing wide-scale Linux adoption of LibreSSL? Has left us more dangerously monocultured. GnuTLS exists. OpenSSH exists. But each finds itself most applicable in different circumstances. LibreSSL was a relatively drop in replacement, but the lack of TLS3 support? Later ended up killing serious Linux support. There was so much code to audit, overhaul, rewrite, or simply remove? That the team writing it still has their work cut out for them, before TLS 3 support can even be considered. https://www.libressl.org/goals.html https://www.libressl.org/goals.html So to see Google help put an auditable, open, safe-language alternative out there? It is a fascinating move. Im suspicious that google's involved, same as you. But so long as it is auditable? And someone more trustworthy is at the helm, keeping it honest? Im excited to see this exist.