Taher Elgamal (Axway) "Le modèle de confiance du SSL est désuet"

Le créateur du SSL admet les limites de son protocole, et en particulier celle du modèle de confiance sur lequel il repose. Selon cet expert, aujourd'hui responsable sécurité chez Axway, c'est aussi le rôle des navigateurs qui doit être revu.

JDNSolutions. Pourriez-vous expliquer brièvement les raisons et les conditions de votre participation à la création du protocole SSL ?

Taher Elgamal. En 1994, les fondateurs de Netscape considéraient Internet comme un outil pour le commerce électronique. Il s'est vite avéré impossible de mener une activité professionnelle sur un réseau ouvert sans sécuriser la connexion entre l'acheteur et le vendeur. Le commerce électronique exigeait une confidentialité des données et une validation d'identité entre les deux parties. Nous avons travaillé à un protocole qui réponde à cette demande.

Le protocole SSL actuel a été développé par mon équipe chez Netscape. A l'époque, nous avons réuni plusieurs experts en sécurité, les avons installés dans une pièce et avons étudié avec eux le protocole pendant plusieurs jours. Nous nous sommes ainsi assurés que personne ne rencontrait de problèmes, l'avons ensuite distribué et avons sollicité l'ITF, l'International Technology Forum, pour en faire une norme.

Pensez-vous que le mode d'utilisation actuel du protocole SSL corresponde parfaitement à son but initial ?

L'application du protocole SSL s'avère pertinente pour le commerce électronique. Son utilisation répond à l'objectif de sa conception, ainsi qu'en plus, à beaucoup d'autres applications, comme le VPN SSL.

Cette dernière application n'avait d'ailleurs pas du tout été prévue, mais c'est le lot de toute innovation. Certains ont compris que tous les navigateurs intégraient ce composant client SSL et qu'on pouvait donc l'utiliser pour beaucoup d'autres applications.

Je dirais donc que le protocole SSL permet aujourd'hui de sécuriser le commerce électronique tel que nous l'envisagions il y a 17 ans, mais il offre également d'autres solutions, que nous n'avions pas forcément envisagées au départ.

D'après vous, la récente attaque BEAST, qui a pu casser le chiffrement SSL, devrait-elle susciter l'inquiétude des RSSI, des sites Web et/ou de leurs clients ?

Les fondements techniques de l'attaque BEAST étaient en fait déjà connus en 2004/2005. Nous savions donc déjà que, dans certains cas, une méthode particulière de cryptage dans le protocole SSL présentait un défaut.

Nous ne devions cependant pas laisser un protocole aussi largement utilisé que TLS présenter un tel défaut. La communauté ITF a donc conçu TLS 1.1, puis 1.2. Des nouvelles versions du protocole TLS qu'il faut inciter le monde entier à adopter.

"Les navigateurs devraient intégrer les nouvelles versions du protocole TLS."

En outre, si vous observez les particularités de fonctionnement actuel de BEAST, la présence d'un programme malveillant sur une machine client s'avère essentielle pour l'exploit. Ce programme malveillant intègre des cookies dans le flux SSL, de sorte que le hacker puisse en calculer les clés.

Concrètement, l'attaque BEAST n'est donc pas si dangereuse. En effet, si un programme malveillant réside déjà sur votre machine, il peut de toute façon accéder à toutes vos données et les lire indépendamment de problèmes ou dysfonctionnements SSL...

La version actuelle de l'attaque BEAST ne présente donc en fait aucun élément nouveau inquiétant. Elle souligne simplement que le secteur dans son ensemble doit cesser d'utiliser des versions de produits aux défauts identifiés.

Pourtant, les versions 1.1 et 1.2 du protocole TLS ne sont toujours pas prises en charge par la plupart des sites Web...

Le véritable problème est que les navigateurs ne prennent pas en charge ces nouvelles versions du protocole. Le site Web lui-même ne peut apporter de solution à lui seul. Les fournisseurs de navigateurs devraient intégrer les nouvelles versions du protocole TLS. Il est très important que chacun de nous applique les correctifs de sécurité, et déploie en permanence les dernières versions, même si cela peut parfois s'avérer plus compliqué que prévu.

La version actuelle de l'attaque BEAST n'est pas si grave, mais cela n'exclut pas que dans les années à venir, quelqu'un crée une forme plus puissante et nocive d'atteinte à la sécurité. Nous devons inciter le secteur à prendre en charge les dernières versions du protocole TLS et je pense que les fournisseurs de navigateurs sont les plus à même d'agir en ce sens. Lorsque les navigateurs seront à la norme, la prise en charge TLS requise englobera également les sites Web.

Comment la sécurité des autorités de certification devrait-elle ou pourrait-elle être renforcée de manière simple et efficace ?

Il s'agit aujourd'hui d'une question essentielle. L'intégralité du système de confiance du commerce électronique repose sur les autorités de certification, et ces dernières sont liées aux navigateurs. C'est cela, le modèle de confiance. Et chaque année, avec chaque version de navigateur, les autorités de certification remplissent leur rôle pour attester du maintien de la conformité.

Mais je pense qu'il s'agit d'un modèle désuet. Je crois que pour bien faire, les fournisseurs de navigateurs devraient signer numériquement des clés de certification et, si un signataire ne donne pas satisfaction, il faut le révoquer, tout simplement. Si tous les clients et serveurs prennent en charge la révocation, l'autorité de certification déficiente peut être immédiatement supprimée du système. La manière actuelle d'associer des clés à des navigateurs ne s'avère pas une bonne idée.

Quel choix recommanderiez-vous aux détenteurs de sites Web en matière d'autorité de certification ? Le prix du certificat importe-t-il ?

Le prix importe peu. L'obtention d'un certificat d'une autorité opérationnelle s'avère, elle, importante. Il s'agit du seul moyen garantissant la fiabilité de votre activité. Consultez donc d'abord, par exemple, le site Web de l'autorité et notez les autres entreprises ayant obtenu des certificats de sa part. Vous devez vous assurer qu'elle ne délivre pas des certificats à des entités inconnues sans vérifier leur véritable identité. Le problème n'est pas le prix, mais les références des autorités pour délivrer et gérer des certificats.

Titulaire d'un bachelor of science de l'université du Caire en 1981, puis un master of science et un doctorat de l'université Stanford, Taher Elgamal a publié en 1985, un article intitulé "un cryptosystème à clef publique et un schéma de signature basé sur les logarithmes discrets", désormais connu sous le nom d'algorithme ElGamal. De 1995 à 1998, il est directeur scientifique chez Netscape où il participera notamment à la création et au développement du SSL. Il a également travaillé chez RSA, Securify ou Kroll-O'Gara avant d'être aujourd'hui responsable sécurité (Chief Security Advisor) chez Axway.