Les inconvénients

Le protocole SSL/TLS, comme tout autre technologie novatrice dans le domaine de sécurité, possède son lot d’inconvénients :

3.4.8.1 Problèmes liés aux navigateurs

Le problème des navigateurs réside surtout dans la vérification automatique de la validité des certificats, des listes des révocations et des restrictions d’exportation et la conservation des clés privées dans des endroits sécurisés.

Vu l’absence de consultation automatique des signatures par les navigateurs, l’autorité de certification, qui a émis les certificats pour les clients ou même les sites, peut même ensuite révoquer ces certificats sans que les utilisateurs cessent d’en vérifier la validité.

Ce problème est bien relié aussi à l’usage de ces navigateurs par des utilisateurs non experts dans le domaine de la sécurité et des PKI dont SSL/TLS est bien rattaché (quand un certificat expire, l’utilisateur reçoit un message et doit obtenir manuellement un nouveau certificat, ce qui n'est pas forcément trivial pour un utilisateur quelconque).

Dans ce cadre, puisque le but était de rendre l’utilisation de SSL/TLS la plus souple possible, un problème de confiance est apparu entre les utilisateurs et la liste des certificats des autorités de certification imposée et codée en dure dans les navigateurs.

3.4.8.2 Problème cryptographique (lié à l’implémentation)

Même si SSL/TLS a été standardisé à l’IETF et approuvé cryptographiquement comme un protocole sécurisé, de nouvelles attaques sont apparues sur ce protocole ciblant la partie Handshake en essayant de recouvrir le master_secret dont tout le chiffrement du canal SSL/TLS est fondé.

Ces attaques sont liées surtout à l’implémentation de ce protocole dans l’API OpenSSL [OpenSSL] la plus répondue actuellement dans le domaine des « Open Source ».

Des chercheurs de l’EPFL (Ecole Polytechnique de Lausanne) [Canv03], de l’université de Stanford et de l’université de Prague ont trouvé des failles dans les implémentations OpenSSL version 0.9.6 liées à l’interception des mots de passe, le temps d’encryptage et de décryptage des blocs SSL/TLS et à la création des sessions basées sur RSA. Le dernier problème est le plus persistant puisque le recouvrement du master_secret dérive la capturation et le déchiffrement de tous les messages SSL/TLS.

3.4.8.3 Attaques liées au réseau

Une autre attaque qui peut arriver sur SSL/TLS est la construction des sites très similaires à des sites que l’on souhaite abuser. Ceci est dû, en grand sort, en trompant des serveurs DNS [RFC1034] [RFC1035] non sécurisés.

3.4.8.4 HTTPS et les Proxy

La sémantique générale de HTTPS est d’ouvrir un canal sécurisé entre deux entités (client et serveur SSL/TLS), sans permettre à aucun tiers intermédiaire d’accéder ou de partager la communication avec eux. Pour cela, les Proxy, qui joue le premier rôle dans l’optimisation de la bande passante sur les liens Internet, sont totalement inutiles avec SSL/TLS.

D'ailleurs, les Proxy exigent un support spécial de la méthode CONNECT pour pouvoir passer le HTTPS. Quand la connexion SSL/TLS est établie, le cache des Proxy est désactivé puisque les serveurs Proxy ne peuvent faire aucun contrôle sur les messages SSL/TLS.

3.4.8.5 SSL et les hôtes virtuels

HTTPS interagit faiblement avec les serveurs virtuels. Le problème résiste encore dans la faite que dans SSL/TLS, toutes les données sont envoyées après l’établissement du Handshake SSL/TLS. Normalement dans les connexions HTTP, le serveur utilise l’entête «HOST» du HTTP pour déterminer quels serveurs virtuels le client veut accéder. Puisque dans HTTPS, l’entête HTTP est envoyé après l’établissement du Handshake SSL/TLS, le serveur ne peut savoir à quels serveurs virtuels le client veut accéder (surtout si les serveurs virtuels sont sur plusieurs machines).

Une méthode pour détourner ce problème est de configurer une machine avec plusieurs adresses IP de sorte que pour chaque serveur virtuel on lui assigne une adresse IP. Une méthode plus opérante serait d’envoyer dans le message client_hello du Handshake de SSL/TLS la DNS du serveur que le client essaye de se connecter.

3.4.8.6 Utilisation des faibles clés de chiffrement

Théoriquement, SSL/TLS est vulnérable aux attaques par force brute (tentatives de déchiffrement direct d'un message crypté) si les clés utilisées sont de 40 bits. C'est pourquoi, il est plus sûr d'utiliser des clés de 128 bits pour se prémunir des attaques. Les caractéristiques temporelles et financières de ce type d'attaque sont facilement calculables.

Des renseignements sur le type de SSL/TLS utilisé indiquent le matériel et le temps nécessaire à l'attaque. Le chiffrement à 40 bits est de moins en moins cher et long à attaquer, même pour un pirate seul. Tant qu'il n'existe pas d'algorithmes cryptographiques capables d'attaquer directement le chiffrement 128 bits, ce dernier pourra être considéré comme sûr. 3.4.8.7 SSL/TLS et les applications basées sur UDP

L’avantage majeur de SSL/TLS est qu’il fournit un canal sécurisé transparent aux applications. Cependant, SSL/TLS exige un canal fiable comme TCP et ne peut pas être utilisé pour sécuriser des applications au-dessus de UDP [RFC768].

Quand TLS a été développé, cette limitation n'a pas été considérée particulièrement sérieuse parce que la grande majorité d'applications utilise le protocole TCP. Actuellement, cette situation a changé. Au cours de ces dernières années, un nombre croissant de protocoles de couche application, comme les protocoles (SIP, Session Initiation Protocol) [RFC3261], (RTP, Real Time Protocol) [RFC3550], (MGCP, Media Gateway Control Protocol) [RFC3435] et une variété de protocoles de jeu ont été conçus pour employer le protocole UDP. SSL/TLS est incapable d’offrir ces services de sécurité à ces types d’applications.