Je ne suis pas un expert de ce sujet, mais Blanchet et Pironti, que j'ai croisés à quelques séminaires, sont très convaincants. Biensûr il n'existera jamais de preuve absolue qu'une implémentation est sécurisée, mais ils franchissent déjà une grosse marche dans la sécurité ! Je trouve juste aberrant de voir un groupe de codeurs, aussi bien intentionns soient-ils, reprendre le même chemin que celui qui a conduit à OpenSSL et HeartBleed…
Si cela t'intéresse, tu peux consulter leurs pages, leurs papiers, où ils expliquent tout ceci bien mieux que moi. :=)
Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.
Quand on travaille sur des points aussi critiques de sécurité, il me semble normal de prouver la conception du protocole ET son implémentation. Biensûr, c'est encore à l'état de recherches, mais ils ont une implémentation qui fonctionne, et qui est prouvée, ce qui est une belle avancée. Il y a eu beaucoup d'articles traitant de Heartbleed et des solutions à lui apporter, mais on ne mentionne jamais les implémentations prouvées, qui sont, selon moi, la seule solution d'avenir…
Pour ceux que ça intéresse, j'ai retrouvé le nom de leur implém': c'est miTLS.
Un procès d'intention serait bien mal venu. J'imagine que les développeurs d'OpenSSL étaient totalement impliqués dans leur travail, avec pour objectif fonctionnel et sécurisé. Et pourtant, on retrouve ce trou béant qui est HeartBleed dans leur code.
Quelle différence de démarche dans le processus de développement de ce 'LibreSSL' ? Aucune. Des développeurs pleins de bonnes intentions, sans doute des experts en sécurité, qui vont tout faire pour obtenir un logiciel robuste et performant. Et pourtant, on retrouvera sans doute des trous béants dans leur code.
Il me semble qu'il serait temps de passer à des implémentations prouvées. L'équipe Inria ProSecco a réalisé une implémentation prouvée de TLS. Les failles sont alors automatiquement décelées, ce qui ajoute un degré de sécurité à l'implémentation. Pourquoi ne pas utiliser cette même démarche avec les composants de sécurité clés ?
[^] # Re: Implémentation prouvée
Posté par vanille_cafe . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 1.
Je ne suis pas un expert de ce sujet, mais Blanchet et Pironti, que j'ai croisés à quelques séminaires, sont très convaincants. Biensûr il n'existera jamais de preuve absolue qu'une implémentation est sécurisée, mais ils franchissent déjà une grosse marche dans la sécurité ! Je trouve juste aberrant de voir un groupe de codeurs, aussi bien intentionns soient-ils, reprendre le même chemin que celui qui a conduit à OpenSSL et HeartBleed…
Si cela t'intéresse, tu peux consulter leurs pages, leurs papiers, où ils expliquent tout ceci bien mieux que moi. :=)
[^] # Re: Implémentation prouvée
Posté par vanille_cafe . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 3.
Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.
Quand on travaille sur des points aussi critiques de sécurité, il me semble normal de prouver la conception du protocole ET son implémentation. Biensûr, c'est encore à l'état de recherches, mais ils ont une implémentation qui fonctionne, et qui est prouvée, ce qui est une belle avancée. Il y a eu beaucoup d'articles traitant de Heartbleed et des solutions à lui apporter, mais on ne mentionne jamais les implémentations prouvées, qui sont, selon moi, la seule solution d'avenir…
Pour ceux que ça intéresse, j'ai retrouvé le nom de leur implém': c'est miTLS.
Alfredo Pironti en parle ici: http://alfredo.pironti.eu/research/projects/mitls et il y a même un site dédié ici: http://www.mitls.org/wsgi
# Implémentation prouvée
Posté par vanille_cafe . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 9.
Un procès d'intention serait bien mal venu. J'imagine que les développeurs d'OpenSSL étaient totalement impliqués dans leur travail, avec pour objectif fonctionnel et sécurisé. Et pourtant, on retrouve ce trou béant qui est HeartBleed dans leur code.
Quelle différence de démarche dans le processus de développement de ce 'LibreSSL' ? Aucune. Des développeurs pleins de bonnes intentions, sans doute des experts en sécurité, qui vont tout faire pour obtenir un logiciel robuste et performant. Et pourtant, on retrouvera sans doute des trous béants dans leur code.
Il me semble qu'il serait temps de passer à des implémentations prouvées. L'équipe Inria ProSecco a réalisé une implémentation prouvée de TLS. Les failles sont alors automatiquement décelées, ce qui ajoute un degré de sécurité à l'implémentation. Pourquoi ne pas utiliser cette même démarche avec les composants de sécurité clés ?