GnuTLS est une bibliothèque logicielle libre diffusée sous la licence LGPL 2.1 et plus et écrite en C et C++. GnuTLS implémente les protocoles réseau SSL 3.0, TLS 1.0, TLS 1.1 et TLS 1.2. Ceux-là même utilisés par tous les navigateurs web quand vous surfez en HTTPS.
Une version majeure est en cours de développement, elle ajoute une implémentation du protocole DTLS et améliore la compatibilité avec OpenSSL.
Depuis la version 2.12, GnuTLS a changé de moteur cryptographique par défaut et utilise Nettle. Par rapport à l'ancien moteur, libgcrypt, Nettle se veut moins lourd aussi bien en mémoire qu'en consommation processeur.
Cette version, estampillée 2.99.0, est une version de développement mais utilisable dès à présent pour ajouter le support de DTLS à vos applications utilisant UDP massivement, comme les logiciels de messagerie ou de visioconférence. En effet, DTLS permet enfin d'ajouter la sécurisation des données au dessus des protocoles orientés datagrammes et non connectés tels qu'UDP. Jusqu'à présent, la seule implémentation de DTLS se trouvait dans OpenSSL dont la licence est incompatible avec la GPL. Ce qui empêchait son utilisation dans beaucoup de logiciels libres.
Par rapport à son concurrent le plus connu, à savoir OpenSSL, GnuTLS propose une API très claire et très bien documentée. Un vrai plaisir d'utilisation par rapport à OpenSSL qui est un vrai désastre en la matière.
Aller plus loin
- Le site officiel (164 clics)
- L'annonce officielle (40 clics)
# GnuTLS vs OpenSSL... mouais
Posté par vosgien_ . Évalué à 3.
Je ne veux pas dire, mais critiquer OpenSSL ok... le code n'est pas top, l'API crade et la doc presque inexistante. Par contre oser vanter les qualités de GnuTLS par rapport à OpenSSL... c'est l'hôpital qui se fou de la charité. Parce que franchement... il n'y a pas beaucoup plus immonde que GnuTLS.
Un petit article très intéressant ici.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par ecyrbe . Évalué à 9.
Pense tu sérieusement qu'OpenSSL n'a pas de failles? L'auteur de ton article critique la gestion de cette faille par les développeurs de GnuTLS, qu'il pense qu'ils n'ont pas testé leur patch...il la sort d'ou son information disant que le patch n'a pas été testé? C'est du troll de compet, mais ses arguments sont bidons.
Il demande de regarder le code de GnuTLS pour se convaincre que GnuTLS est mauvais par rapport à OpenSSL. Et bien, j'ai regardé le code de l'un et de l'autre... Et sans contestation possible, OpenSSL est le grand perdant. Mieux, le code de GnuTLS est bien écrit et clair. Il peut y avoir des failles comme dans toute bibliothèque, mais elles ne sont pas pire que certaines perles que j'ai pu voir passer au sujet d'OpenSSL.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Antoine . Évalué à 3.
Ben, je ne suis pas spécialiste en sécu, mais la décision de supprimer un certificat d'une chaîne sous prétexte qu'il est auto-signé est en effet un peu stupide. Le principe d'une chaîne de certificats, c'est bien que les certificats se valident les uns les autres le long d'une chaîne de confiance : si on supprime un maillon, comment prétendre vérifier la fiabilité de l'ensemble ?
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Pierre Carrier . Évalué à 9.
En considérant le certificat à approuvé comme le premier de la chaîne (retourner l'image dans votre tête si ça vous embrouille) :
Un certificat qui n'est pas au début d'une chaîne ne doit pas être auto-signé, il doit être signé par le maillon le suivant dans la chaîne.
Pour ce qui est du certificat de fin, il doit être vérifié par un certificat faisant partie des CA approuvés, passés en paramètre (trusted_cas) dans la fonction incriminée.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Peu importe : un certificat auto-signé ne peut pas être ailleurs qu'au bout de la chaîne en question. C'est comme si, dans une pile de briques de Lego, on supprimait les briques uniquement femelles du milieu de la chaîne : en pratique, ça revient à ne rien faire puisque ces briques ne peuvent pas se trouver au milieu.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Grunt . Évalué à 10.
Wa, j'ai mis du temps à comprendre :]
Alors, en fait, ça c'est un certificat dans la chaîne:
Et ça c'est le certificat au bout de la chaîne, qui est auto-signé:
Effectivement, il n'a rien à faire au milieu.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par ecyrbe . Évalué à 8.
Ce n'est pas le fait de supprimer un certificat auto-signé qui est une faille... c'est même légitime ce qu'ils voulaient faire. Mais ils le faisaient mal. Si le dernier certificat de la chaine était auto-signé, ils ne devaient pas le prendre en compte, vu que sinon ils pouvaient à tort le considérer comme invalide!
Ce qu'ils faisaient mal, c'est qu'ils enlevaient le dernier certificat après l'avoir vérifié. Hors un homme du milieu qui envoyait une chaine avec deux certificats auto-signé, pouvait se faire passer pour valide. Bref, ils faisaient le test à l'envers.
Il fallait en premier enlever le certificat auto-signé de la liste, puis vérifier la chaine par rapport à la liste de confiance. Mais le premier Patch faisait aussi une énorme boulette! Après avoir enlevé le certificat auto-signé, ils ne vérifiaient pas que la liste était vide! Du coup cela générait un segfault. Bref, le premier correctif à cette faille était mauvais car il générait un segfault et faisait planter le programme appelant, mais il fut corrigé avant que quoi que ce soit ne soit packagé officiellement. Bref, la faille était très gênante, et très facile à exploiter. Mais ce qui a introduit la faille était à la base une vérification légitime pour éviter un faux négatif. Par la suite, un correctif qui enlève en premier le certificat auto-signé, si la liste ne devenait pas vide à été fournit. (cf. ici)
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Antoine . Évalué à 2.
Non, tu te trompes. Je cite l'article mentionné au début du fil (dans un message bizarrement moinssé) :
Voilà, il n'y avait pas besoin de retirer les certificats auto-signés parce que ça ne correspond à aucun besoin particulier.
De quel faux négatif parles-tu ?
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par ecyrbe . Évalué à 4.
Ne te fit pas à l'article, il raconte n'importe quoi. Il y avait un bug qui faisait qu'une chaine de certificat était considéré comme invalide pour certains certificats auto-signés. Le correctif à introduit la faille expliqué. Le correctif nécessitant le retrait du certificat auto-signé (vu qu'on doit l'avoir dans sa liste de confiance) était donc utile.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Antoine . Évalué à 1.
Je ne sais pas, mais l'algorithme semble avoir été totalement réécrit depuis la version présentée dans l'article :
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/x509/verify.c;hb=HEAD#l535
Ce qui implique que l'algo original était probablement peu satisfaisant.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par ecyrbe . Évalué à 2.
Et bien l'algorithme n'a pas été réécrit.. juste réordonné comme je l'ai précisé plus haut, et ils ont ajouté une boucle pour enlever en plus dans la chaine tous les certificats auquel on fait déjà confiance, car il est inutile de les vérifier.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par Antoine . Évalué à -1.
Ben, vu qu'à peu près tout a changé dans l'algo, j'appelle ça une réécriture.
C'est comme si tu disais que quicksort est une version modifiée de bubblesort.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par ecyrbe . Évalué à 6.
Et bien tu ne sais pas lire... car le code n'a pas vraiment changé... déplacer un bout de code et ajouter une boucle ce n'est pas la mort et celà n'a absolument pas changé la logique derrière l'algorithme originel. Celà n'est absolument pas un changement d'algorithme mais une amélioration. Mais comme tu le dit toi même tu n'est pas spécialiste en crypto, donc c'est logique que tu n'arrives pas à comprendre les changements.
[^] # Petite question de néophite
Posté par Marc Dauwn . Évalué à 3.
Au delà du troll "qui a le plus de failles", je viens de me poser une question et, étant quelqu'un de généreux, je la partage:
Vu la complexité des algorithmes cryptographiques actuels, on peut considérer qu'il y aura toujours une faille dans la bibliothèque X ou Y.
Ne peut-on pas "chaîner" les cryptages? Une passe avec X, puis rebelote avec Y, si il y a une faille dans X, il reste Y et à l'inverse le chinois du FBI devra d'abord s'attaquer à X pour exploiter la faille de Y.
Bon, la faille se trouve sûrement dans mon raisonnement sinon, aussi noob que je sois, cela serai déjà utilisé.
Vous avis?
[^] # Re: Petite question de néophite
Posté par small_duck (site web personnel) . Évalué à 5.
Ça fait un certain temps que je me suis penché sur la question, mais il me semble que l'argument contre le chaînage des techniques de cryptage était que la combinaison est généralement plus facile à déchiffrer que la somme des parties, car mieux à même de faire ressortir des invariants, ou de magnifier les faiblesses des algos, un peu comme faire un double ROT13. Maintenant, ce n'est peut-être plus vrai avec les algos modernes.
[^] # Re: Petite question de néophite
Posté par Antoine . Évalué à 10.
Il est en effet regrettable que certains compromettent la sécurité de leurs données en appliquant, par zèle, un double ROT13 alors que le ROT13 simple est réputé inviolable.
[^] # Re: Petite question de néophite
Posté par Michaël (site web personnel) . Évalué à -1.
Tu es rude! Tu aurais du attendre le 15 septembre à 7 heures pour poster ton commentaire :)
[^] # Re: Petite question de néophite
Posté par Michaël (site web personnel) . Évalué à 4.
Ce que tu écris me rappelle l'introduction du chapitre de TAoCP (Knuth) consacré aux nombres pseudo aléatoires: Knuth y raconte ses erreurs de jeunesse, il souhaitait construire un générateur de nombres aléatoires 'hachtement bien en empilant des méthodes apparemment toutes plus ingénieuses les unes que les autres qui poussaient les bits de la graine aléatoire dans une danse virevoltante, et surtout vers un cycle suffisamment court pour être visible à l'œil nu!
La morale de son histoire est que plus un système est complexe, moins on est capable de l'analyser et d'en énoncer des propriétés intéressantes. En cryptographie on veut avoir confiance dans le fait qu'un système est difficile à casser, techniquement on démontre des théorèmes du genre «Victor décrypte le message de Alice à Bob» équivaut à «Victor sait résoudre telle problème de maths» et on monte un cryptosystème dont la casse équivaut à un problème de maths réputé insoluble.
Un deuxième point est que si tu empiles deux cryptosystèmes S et T pour coder ton message m, le message codé est donc S(T(m)), le petit Victor peut utiliser tout ce qu'il sait sur la forme des messages générés par T pour casser S.
Mais bon, je le concède, ma réponse est celle d'un néophyte.
[^] # Re: Petite question de néophite
Posté par Pierre Carrier . Évalué à 0.
Ta nouvelle bibliothèque invoque plusieurs algorithmes au lieu d'un, et on rajoute une couche pour gérer l'appel aux algorithmes dans le bon ordre, valider chaque résultat, etc.
Il suffit qu'un bout de code soit cassé pour ouvrir une faille.
En gros, ta proposition augmente la quantité de code, donc le risque de bugs, donc de failles de sécurité.
Keep It Simple, Stupid.
[^] # Re: Petite question de néophite
Posté par Victor STINNER (site web personnel) . Évalué à 8.
Vu la complexité des algorithmes cryptographiques actuels, on peut considérer qu'il y aura toujours une faille dans la bibliothèque X ou Y.
C'est plutôt dans les protocoles comme TLS ou dans la gestion des certificats que des failles sont trouvées plutôt dans les implémentations des algorithmes de chiffrement.
[^] # Re: GnuTLS vs OpenSSL... mouais
Posté par pasScott pasForstall . Évalué à -4.
Ben vu les problemes que le patch apporte, si le mec avait teste et toujours commite, ca devient grave..
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.