Following the discovery of numerous security vulnerabilities in its code, the OpenSSL cryptographic library has been forked yet again - this time as Google's BoringSSL.
The open-source OpenSSL project was one that, for many, had flown under the radar for years. Typically used to encrypt and decrypt data sent over public networks like the internet, the first time many non-technical types heard of the package was when news broke of the Heartbleed vulnerability. The result of apparent poor coding practices within the project, Heartbleed allowed attackers to retrieve memory contents from servers running OpenSSL - including, it transpired, the private keys used to decrypt data sent to the server.
The flaw was serious enough to trigger the OpenBSD project to fork the OpenSSL source code into LibreSSL, pruning and refining it in order to improve security but in such a manner that means the new code is unlikely to work outside the project's own operating system. Now, Google is getting in on the act with the launch of BoringSSL - a fork of OpenSSL which aims to provide no nasty surprises.
The project isn't a direct response to Heartbleed and similar vulnerabilities, however. 'Earlier this year, before Apple had too many goto fails and GnuTLS had too few, before everyone learnt that TLS heart-beat messages were a thing and that some bugs are really old, I started a tidy up of the OpenSSL code that we use at Google,' explained Google engineer Adam Langley of the project. 'We have used a number of patches on top of OpenSSL for many years. Some of them have been accepted into the main OpenSSL repository, but many of them don’t mesh with OpenSSL’s guarantee of API and ABI stability and many of them are a little too experimental.
'[Now] we’re switching models to one where we import changes from OpenSSL rather than rebasing on top of them. The result of that will start to appear in the Chromium repository soon and, over time, we hope to use it in Android and internally too,' claimed Langley. 'There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project. We will still be sending them bug fixes when we find them and we will be importing changes from upstream. We’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us.'
Warning with tongue-in-cheek that the BoringSSL name is 'aspirational and not yet a promise,' Langley's announcement of BoringSSL and Google's adoption thereof is yet another blow for the OpenSSL project and its founders who are still working to repair its reputation following recent events.
The open-source OpenSSL project was one that, for many, had flown under the radar for years. Typically used to encrypt and decrypt data sent over public networks like the internet, the first time many non-technical types heard of the package was when news broke of the Heartbleed vulnerability. The result of apparent poor coding practices within the project, Heartbleed allowed attackers to retrieve memory contents from servers running OpenSSL - including, it transpired, the private keys used to decrypt data sent to the server.
The flaw was serious enough to trigger the OpenBSD project to fork the OpenSSL source code into LibreSSL, pruning and refining it in order to improve security but in such a manner that means the new code is unlikely to work outside the project's own operating system. Now, Google is getting in on the act with the launch of BoringSSL - a fork of OpenSSL which aims to provide no nasty surprises.
The project isn't a direct response to Heartbleed and similar vulnerabilities, however. 'Earlier this year, before Apple had too many goto fails and GnuTLS had too few, before everyone learnt that TLS heart-beat messages were a thing and that some bugs are really old, I started a tidy up of the OpenSSL code that we use at Google,' explained Google engineer Adam Langley of the project. 'We have used a number of patches on top of OpenSSL for many years. Some of them have been accepted into the main OpenSSL repository, but many of them don’t mesh with OpenSSL’s guarantee of API and ABI stability and many of them are a little too experimental.
'[Now] we’re switching models to one where we import changes from OpenSSL rather than rebasing on top of them. The result of that will start to appear in the Chromium repository soon and, over time, we hope to use it in Android and internally too,' claimed Langley. 'There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project. We will still be sending them bug fixes when we find them and we will be importing changes from upstream. We’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us.'
Warning with tongue-in-cheek that the BoringSSL name is 'aspirational and not yet a promise,' Langley's announcement of BoringSSL and Google's adoption thereof is yet another blow for the OpenSSL project and its founders who are still working to repair its reputation following recent events.
MSI MPG Velox 100R Chassis Review
October 14 2021 | 15:04
Want to comment? Please log in.