Google a officialisé à son tour son propre « fork » d’OpenSSL, l’implémentation libre de référence des protocoles SSL et TLS. Une décision qui a pour but de simplifier l’entretien du code en interne, mais qui crée au passage une nouvelle variante du composant, quelques semaines après l'affaire Heartbleed.

Alléger le code autant que possible

OpenSSL s'est fait connaître du grand public ces derniers temps surtout pour ses problèmes de sécurité. Ceux qui n’en avaient jamais entendu parler ont peut-être découvert son existence au travers de la problématique concernant HeartBleed, cette faille critique qui mettait en danger la confidentialité des données personnelles dans les échanges avec de nombreux sites et services.

Si Google utilise OpenSSL depuis longtemps, la situation qui entoure le composant a évolué et la firme s’est retrouvée piégée par une complexité accrue. La raison en est qu’elle utilise un lot de patchs qu’elle applique à chaque nouvelle mouture d’OpenSSL, soit pour en optimiser le fonctionnement, soit pour qu’il soit plus adapté à ses propres produits et besoins. Une partie de ces patchs est d’ailleurs proposée directement pour intégration, mais la majorité d’entre eux reste l’apanage de Google, soit parce qu’ils pourraient induire une cassure dans la compatibilité de la branche principale, soit parce qu’ils sont trop expérimentaux. 

Les équipes ont donc comme objectif final d’obtenir un résultat beaucoup plus léger, notamment en supprimant bon nombre d’API (Application Programing Interface) et ABI (Application Binary Interface).

Un SSL visiblement « ennuyeux » pour Google 

C’est ce qu’explique le développeur et cryptologue Adam Langley, qui travaille chez Google. Il ajoute que l’entreprise a besoin d’un nombre croissant de ces patchs pour ses propres produits et la maintenance du code, ajoutée à la vérification de la compatibilité, sont devenues de vrais casse-têtes. Aussi, la philosophie a complètement basculé : désormais, c’est la propre implémentation de Google, baptisée « BoringSSL » (littéralement « SSL ennuyeux », le nom n’est pas définitif), qui comptera, les nouveautés d’OpenSSL étant reprises et ajoutées pour assurer la compatibilité.

Google annonce ce changement car l’utilisation de BoringSSL devrait commencer à se voir prochainement dans les dépôts de Chromium. Ce qui signifie que dans quelques mois, Chrome en sera officiellement équipé en version finale. Un peu plus tard, c’est Android lui-même qui devrait en bénéficier, et il ne serait d’ailleurs pas étonnant qu’une annonce en ce sens soit faite durant la conférence Google I/O qui ouvre ses portes ce mercredi.

Une communication avec les autres forks... 

Adam Langley explique cependant que BoringSSL n’a pas vocation à entrer en concurrence avec OpenSSL. Pourquoi ? Tout simplement parce qu’il s’agit d’un composant utilisé en interne qui ne sera pas proposé comme solution de remplacement parce que « meilleure ».

Langley précise également d’autres éléments importants. En effet, les problématiques de sécurité liées à OpenSSL ont permis l’émergence de plusieurs initiatives. C’est tout particulièrement le cas de la Core Infrastructure Initiative lancée par la Linux Foundation et réunissant de nombreux grands noms du secteur : Microsoft, Intel, IBM, Amazon, Apple, Adobe, Dell, Cisco, Facebook, VMware ou encore Fujitsu. Or, Langley précise justement que Google continuera de participer activement au projet qui vise à alimenter en capitaux des efforts de sécurisation de certains composants open source cruciaux, car utilisés par de très nombreux produits, services et sites.

Mais Google n’est pas non plus insensible à LibreSSL. Cet autre « fork » d’OpenSSL est parti cette fois de l’OpenBSD Foundation et notamment du fondateur du célèbre Unix, Theo de Raadt. Début mai, ce dernier avait expliqué qu’au terme d’un premier examen, 90 000 lignes de code C et 150 000 lignes de contenus avaient été supprimées pour se concentrer sur l’essentiel. Cependant, LibreSSL n’est pas encore terminé et sa première exploitation doit se faire dans la mouture 5.6 d’OpenBSD, qui doit arriver le 1er novembre.

Or, encore une fois, Google compte intégrer dans BoringSSL toutes les contributions importantes qui seront faites dans LibreSSL et Adam Langley indique d’ailleurs que l’inverse est aussi possible. À la demande d’ailleurs de l’équipe travaillant sur LibreSSL, plusieurs anciennes contributions réalisées par Google sur OpenSSL ont été passées sous licence ISC, appelée également licence OpenBSD. Langley ajoute que ce sera également le cas de tout nouveau code qui sera écrit pour BoringSSL.

... mais pas non plus de fédération de tous les efforts 

On peut donc voir que les projets vont communiquer entre eux. Car non seulement OpenSSL n’est pas mort, mais des moyens conséquents, fédérés par la Linux Foundation, devraient lui permettre de regagner ses lettres de noblesse. Des morceaux seront vraisemblablement échangés avec LibreSSL et Boring SSL. Cependant, on ne peut s’empêcher de regretter que tous les efforts ne soient pas réellement réunis en un unique lieu, en l’occurrence OpenSSL qui bénéfice déjà de l’attention d’un grand nombre de géants de l’informatique et des réseaux.

Pour autant, ce nouveau venu ne semble pas faire trop grincer des dents. Theo de Raadt est d’ailleurs satisfait de la décision de Google car il a remarqué durant le week-end les similitudes entre BoringSSL et LibreSSL : « Leur priorité est la sécurité et non la compatibilité avec les ABI. Tout comme nous ». Il estime qu’avec le temps, la version de Google présentera un nombre élevé de similitudes avec LibreSSL, ce qui pourrait débloquer des opportunités pour ce dernier.