FR 2887049 A1 20061215 FR 0506023 A 20050614 Procédé de protection contre le piratage d'un terminal client utilisant une connexion sécurisée avec un serveur sur un réseau public 1. Domaine de l'invention Le domaine de l'invention est celui de la sécurité sur les réseaux informatiques, pour la plupart basés sur des technologies de communication et d'échange entre terminaux clients et serveurs s'appuyant sur le protocole Internet, plus connu sous son nom anglophone d' Internet Protocol (IP) . Plus précisément, l'invention concerne l'accroissement du niveau de sécurité dans les échanges entre terminaux clients et/ou serveurs pour des transactions à caractère sensible, nécessitant une parfaite identification et authentification entre les terminaux qu'elles impliquent, par exemple dans le cadre de transactions sécurisées relatives à l'accès à des services bancaires ou de commerce électronique en ligne. En effet, force est de constater que le protocole n'a pas été conçu à l'origine pour assurer un niveau de sécurité convenable pour les communications sur les réseaux mondiaux interconnectés ensemble. Il en résulte alors que les protocoles couramment utilisés, au niveau réseau, n'assurent en l'état aucune authentification, ni confidentialité des données échangées entre deux clients communiquant sur le réseau communément appelé l' Internet. 2. État de la technique, Afin de pallier les problèmes de sécurité rencontrés principalement sur des réseaux de communication publics et à qualité de service variable, des protocoles sécurisés, généralement mis en oeuvre au niveau applicatif, ont été conçus de manière à apporter des mécanismes d'authentification et de confidentialité dans les échanges et les transactions initiés entre terminaux distants connectés sur ces réseaux. Le protocole le plus connu et le plus utilisé sur le réseau Internet est le protocole SSL, pour Secure Socket Layer en anglais, ou couche de connexion sécurisée en français, encore appelé TLS, pour Transport Layer Security en anglais, sous son nom standardisé. Il est parfaitement adapté aux utilisations courantes de l'Internet comme la navigation sur des sites Web. Les protocoles SSL et TLS sont très utilisés dans les applications de commerce électronique ou de banque en ligne. De par la valeur des applications qu'ils visent à protéger, ils font l'objet d'attaques visant à contourner leur niveau de sécurité (récupération d'informations dans la communication SSL/TLS, typiquement des identifiants de connexion ou des numéros de carte bancaire). Proposé à l'origine par Netscape (marque déposée) et des organismes financiers, SSL est destiné à sécuriser les communications, en utilisant la norme X509, à travers les réseaux TCP/IP, mais aussi les communications s'appuyant sur les protocoles HTTP, FTP et Telnet. SSL et TLS ne demandent pas d'adaptation particulière des éléments du réseau, contrairement à un protocole comme IPsec. Il existe dans SSL et TLS deux niveaux de sécurisation: seul le serveur possède un certificat; - le serveur et le terminal client sont tous deux munis d'un certificat: le client et le serveur peuvent alors s'authentifier de manière mutuelle. Pour pallier les problèmes de sécurité transactionnelle entre terminaux clients et serveurs connectés au moyen d'un réseau type Internet, lorsqu'un terminal client se connecte à un site marchand sécurisé par SSL et hébergé par un serveur, ce dernier lui adresse un certificat contenant sa clé publique, signé par une autorité de certification (AC), ainsi qu'un ensemble de mécanismes cryptographiques supportés par le serveur. Le client vérifie ensuite la validité du certificat, puis crée une clé secrète aléatoirement. Il chiffre cette clé secrète à l'aide de la clé publique du serveur, puis lui envoie le résultat. Le serveur déchiffre la clé de session avec sa clé privée. Cette clé secrète devient la clé de session temporaire. Les deux terminaux possèdent alors une clé commune secrète, laquelle permet de chiffrer les échanges pendant la durée d'une session, au moyen d'un chiffrement symétrique rapide. A titre d'information, il est ici précisé que dans la suite de la description et des revendications, tout ce qui concerne le protocole SSL peut se transposer aisément au protocole TLS (pour Transport Layer Security en anglais, ou sécurisation de la couche de transport, en français) qui correspond à la version normalisée de la version 3.0 du protocole SSL et qui a été repris par l'IETF ( Internet Engineering Task Force en anglais), qui est un groupe dont les membres contribuent à l'ingénierie et à l'évolution des technologies de l'Internet. Comme évoqué précédemment, le protocole SSLITLS repose donc sur un processus d'authentification par clé publique et d'échanges de certificats entre terminaux clients et serveur. La cryptographie asymétrique permet donc d'assurer que le message envoyé demeure confidentiel, et ce, sans être contraint d'utiliser, auparavant, une voie sûre afin de s'échanger les clés. La première clé demeure privée et secrète et n'est généralement connue que par son détenteur. L'autre clé est publique et figure habituellement dans un répertoire électronique. Cependant, la plupart du temps, l'usage montre que le destinataire ne va pas chercher la clé publique de son correspondant dans un répertoire public, éventuellement accessible à distance. Ce dernier la lui transmet au contraire le plus souvent en même temps que d'autres données. La question qui se pose alors est comment être sûr que la clé publique reçue appartient bien à l'expéditeur, et non pas à un pirate informatique ? Pour répondre à cette question, le certificat numérique a été créé. Il permet d'associer de manière sûre une clé publique et le terminal qui la détient. Il est signé par une autorité de certification (AC) reconnue et indépendante. La vérification de la signature donne ainsi la certitude que le certificat présenté a bien été certifié par une autorité de certification en laquelle le client a décidé de faire confiance. Techniquement cela se traduit par le fait que l'utilisateur a sauvegardé la clé publique de l'AC sur son terminal. Le format des certificats numériques est normalisé dans la norme X509 (RFC 2459). Un certificat contient un certain nombre d'informations, parmi lesquelles on peut citer à titre d'exemples illustratifs: la version du certificat, laquelle indique à quelle version de la norme X509 correspond ce certificat; le numéro de série du certificat; l'algorithme de signature utilisé, lequel permet d'identifier le type de la signature utilisée; l'émetteur du certificat, sous la variable Distinguished Name (DN) de l'autorité de certification qui a émis ce certificat; la date de début de validité de certificat; la date de fin de validité de certificat; le détenteur de la clef publique du certificat; la clé publique, décrite sous la forme d'une pluralité d'informations sur la clef publique du certificat; les contraintes de base: extensions génériques optionnelles pouvant être associées au certificat; l'objet d'utilisation de la clé ; la signature numérique de l'autorité de certification ayant validé l'ensemble des informations susmentionnées. Par ailleurs, vérifier la validité du certificat signifie principalement: contrôler sa date de validité ; - contrôler le niveau de confiance à l'encontre de l'émetteur du certificat; - contrôler que l'objet du certificat est bien celui de l'émetteur (par exemple le nom du serveur web www.mabanque.com auquel on est connecté se retrouve dans le champ Objet du certificat) ; contrôler que le certificat n'a pas été révoqué, c'est-à-dire que l'AC émettrice n'a pas mis le certificat sur des listes d'opposition (consultables sur le réseau). Toutefois, lorsqu'un des contrôles réalisés sur les informations d'un certificat échoue, la plupart des navigateurs demandent à l'utilisateur du terminal client s'il souhaite néanmoins valider l'authentification du serveur. En effet de nombreux serveurs sont dotés de certificats périmés, mais qu'ils ont conservés en mémoire, ou encore, de certificats dont l'objet (par exemple http://www.mabanque.com) est différent de l'adresse par laquelle le serveur est accessible (par exemple, plusieurs noms comme http://www.mabanque.fr et http://www.mabanque.com). C'est pourquoi les navigateurs affichent une fenêtre sur l'écran de l'utilisateur et lui proposent, après une mise en garde absconse, s'il souhaite valider néanmoins l'identité du serveur. Le protocole SSL/TLS est aujourd'hui l'un des protocoles de sécurité les plus utilisés sur Internet, notamment pour ce qui concerne la consultation de sites marchands ou services bancaires. Les échanges définis par le protocole SSL se déroulent en deux phases: 1) Première phase: authentification du serveur: suite à une requête d'un terminal client, le serveur envoie son certificat au terminal client et lui propose une liste d'algorithmes cryptographiques pouvant être utilisés. Le terminal client vérifie la validité du certificat du serveur selon la procédure décrite ci-dessus: contrôle automatique de la date de validité, de l'émetteur, de l'objet et de la non révocation, puis demande à l'utilisateur s'il souhaite outrepasser le contrôle en cas d'échec. 2) Deuxième phase: authentification (optionnelle) du terminal client: le serveur (et seulement lui) peut demander au terminal client de s'authentifier en lui demandant tout d'abord son certificat. Si la vérification du certificat échoue, alors l'entité qui détecte l'anomalie envoie immédiatement une alerte à l'autre entité. Par exemple, les messages suivants sont prévus dans la norme: Unknown_ca : l'autorité de certification ne fait pas partie de la liste des AC de confiance; Certificate_revoked : le certificat a été mis en opposition par son AC émettrice; Certificate_expired : la date courante est postérieure à la date de validité ; Bad_certificate : la vérification de la signature du certificat a échoué; Certificate unkown : autres erreurs sur les certificats. Bien que le protocole SSL offre un bon niveau de sécurité, il est possible d'exploiter une erreur humaine pour réaliser une attaque de type Man-in-the- Middle , ou attaque par le milieu. Comme illustré sur la figure 2, et par comparaison avec une situation normale (figure 1), le principe d'une telle attaque est relativement simple: le pirate informatique vient se placer entre le terminal client de l'utilisateur et le serveur offrant le service auquel l'utilisateur souhaite accéder. A la manière d'un relais, le pirate, au moyen d'un terminal d'ordinateur va usurper à la vue du terminal client la fonction de serveur, et se faire passer pour le terminal client auprès du serveur. Dans le cadre d'une telle attaque Man in the middle , le pirate peut intercepter toutes les informations émises par le terminal client, injecter ou modifier du trafic à la volée . Devant ce type d'attaque informatique, les mécanismes de certificats utilisés dans le protocole SSL, même s'ils n'empêchent pas un détournement de trafic, offrent certaines garanties de sécurité à l'utilisateur. En effet, comme le serveur est normalement le seul à connaître la clé privée associée au certificat présenté au terminal client, le pirate informatique réalisant une attaque du type Man in the Middle pourra relayer le trafic, mais celui-ci étant chiffré, il ne pourra pas le lire et donc accéder à son contenu. Comme l'attaquant se retrouve au milieu des communications, il lui est possible de réaliser une session SSL avec le client en présentant un certificat autre que celui du serveur légitime. A ce niveau, la sécurité de la connexion ne va alors plus reposer que sur l'utilisateur à qui il revient de détecter que le certificat présenté par son navigateur Web (dans le cas d'une connexion SSL classique via un navigateur) n'est pas valide, ou a été usurpé. Généralement, les navigateurs Web vont détecter une anomalie dans le certificat, celui-ci ne correspondant pas à celui attendu (par exemple, détection d'une différence entre le nom de domaine totalement qualifié ou Fully Qualified Domain Name en anglais, du site Web saisi par l'utilisateur via l'URL tapée, et le champ correspondant du certificat présenté par le serveur). Le navigateur de l'utilisateur reporte alors à ce dernier un message lui notifiant qu'un problème potentiel de confiance est détecté. Le principe de l'attaque repose sur la difficulté pour un utilisateur novice ou de niveau moyen en informatique de comprendre la signification d'un tel message et la portée de son acte s'il choisit d'ignorer ce message en acceptant un certificat invalide présenté par un pirate informatique, ce dernier pouvant alors accéder au contenu de la communication. Cette attaque n'exploite pas une faille du protocole SSL, mais une faille humaine, malheureusement la plus courante. Ainsi, et comme illustré sur la figure 3, le client a été trompé par le pirate qui lui a fourni un mauvais certificat: la session SSL est donc maîtrisée par l'attaquant. Comme illustré sur la figure 3, la liaison SSL (1) numérotée est dans ce cas totalement accessible par le pirate, qui assure en fait la terminaison de cette connexion. Le pirate est alors en mesure d'établir une connexion (2) avec le serveur légitime. Il pourra rejouer les données fournies par l'utilisateur (jouant le rôle de proxy ou de relais) et ainsi complètement masquer son intervention aux yeux d'un utilisateur standard. On soulignera donc qu'un inconvénient majeur repose sur le fait qu'il n'existe aujourd'hui aucun moyen permettant d'interdire systématiquement les connexions SSL/TLS avec un serveur qui présente un certificat invalide ou falsifié par un pirate. L'utilisateur a toujours la possibilité de refuser un certificat pour lequel un doute subsiste, mais la réalité des comportements des utilisateurs démontre que ces derniers se posent souvent peu la question du piratage et acceptent sans grande méfiance un certificat dont ils ne peuvent garantir la provenance, ou pour lequel le navigateur a remonté un message d'alerte de sécurité. C'est cette propriété qui peut mener à des attaques effectives visant à tromper l'utilisateur. 3. Objectifs de l'invention L'invention décrite ici propose un mécanisme permettant de forcer une politique de sécurité sur un réseau donné de manière à éviter la problématique des erreurs utilisateurs, telle que précitée. Un objectif de l'invention est de fournir une technique qui permette de détecter une attaque d'un pirate informatique présentant à un utilisateur un certificat frauduleux, de façon à réaliser une attaque du type Man in the Middle . Un autre objectif de l'invention consiste à fournir une technique qui soit indépendante du comportement de l'utilisateur au travers de son terminal client, quelle que soit la vulnérabilité de cet utilisateur face à un pirate informatique. Un objectif supplémentaire de l'invention consiste à fournir une telle technique qui permette d'isoler le terminal client du réseau de communication, dès lors qu'une attaque d'un pirate est détectée. Un dernier objectif de l'invention est de fournir une telle technique qui soit relativement simple de mise en oeuvre et relativement peu coûteuse, en termes d'exploitation. 4. Résumé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de protection contre le piratage d'une connexion (12) réseau entre un terminal (10) client et un serveur (11), le terminal (10) client étant connecté au serveur (11) via une connexion (12) sur un réseau de communication. Selon l'invention, un tel procédé comporte: une étape de supervision continue des messages échangés entre le terminal client et le serveur au travers du réseau de communication, l'étape de supervision comportant au moins: ^ une sous-étape (60) de capture d'au moins certains messages échangés sur le réseau entre le terminal client et le serveur; ^ une sous-étape (61) d'analyse d'au moins une partie du contenu des messages capturés; ^ une sous-étape (64) d'identification à partir de la sous-étape (61) d'analyse, des messages correspondant à l'initiation d'une connexion sécurisée entre le terminal client et ledit serveur; ^ une sous-étape (62) de vérification de la validité d'au moins un certificat transmis par le serveur (11) audit terminal (10) client, le certificat ayant été capturé à la sous-étape d'identification; une étape (63) de réaction et de protection du terminal (10) client dès lors que la validité du certificat serveur n'a pu être vérifiée. Une telle approche technique selon l'invention permet avantageusement d'anticiper tout risque qu'un utilisateur du terminal client puisse accepter d'outrepasser le contrôle de la validité du certificat du serveur, lorsque le contrôle a échoué à l'étape d'identification et d'authentification du serveur par le terminal client. Avantageusement, la sous-étape (62) de vérification de la validité d'au moins un certificat transmis par le serveur (11) au terminal (10) client, est une étape de vérification d'au moins un critère prédéterminé attaché au certificat serveur et appartenant au groupe comprenant au moins: une date de validité du certificat; un niveau de confiance associé à l'autorité de certification ayant émis le certificat du serveur; une valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine du serveur et l'adresse réseau du service hébergé par le serveur; une valeur de booléen indiquant si le certificat transmis au terminal client par le serveur n'a pas été révoqué et/ou si le certificat du serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur le réseau de communication. Préférentiellement, la sous-étape (63) de réaction et de protection du terminal client est exécutée dès qu'un au moins des critères prédéterminés concernant le certificat serveur à vérifier n'a pu être vérifié à la sous-étape (62) de vérification. De façon également préférentielle, la sous-étape (63) de réaction et de protection du terminal client est suivie d'une étape de coupure (65) volontaire de la connexion réseau en cours établie entre le terminal client et le serveur. Il s'agit en effet d'empêcher qu'un utilisateur novice ou bien peu habitué à des messages l'invitant à valider s'il le souhaite l'établissement d'une connexion sécurisée à partir d'un certificat périmé, ou dont il ne sera pas en mesure de pouvoir certifier l'origine, puisse subir une attaque d'un pirate informatique en acceptant par inadvertance un certificat pirate. De façon avantageuse, la sous-étape de coupure (65) volontaire de la connexion réseau en cours utilise au moins un paramètre (66) de connexion entre le terminal client et le serveur obtenu durant la sous-étape (61) d'analyse des messages échangés, les paramètres appartenant au groupe comprenant au moins: - une adresse IP source; une adresse IP de destination; au moins un port TCP source; au moins un port TCP de destination; les deux numéros de séquence TCP pour une coupure de connexion s'appuyant sur le protocole TCP/IP. De façon préférentielle, ladite connexion est du type appartenant au groupe comprenant au moins: une connexion SSL ( secure socket layer en anglais ou couche de connexion sécurisée en français) ; une connexion TLS ( Transport layer security en anglais ou couche de transport sécurisée en français) ; - une connexion SHTTP ( Secure HTTP en anglais, ou HTTP sécurisé en français) ; le réseau de communication pouvant être aussi bien un réseau privé qu'un réseau public du type réseau TCP/IP, ou bien encore une association des deux types précédents, par exemple. L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour l'exécution des étapes du procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur, tel que précité, lorsque le programme est exécuté sur un ordinateur. L'invention concerne aussi et de façon avantageuse, un module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) réseau entre un terminal (10) client et un serveur (11). Préférentiellement, un tel module selon l'invention comprend: des moyens (50) de capture d'au moins certains messages échangés sur le réseau entre le terminal (10) client et le (11) serveur, depuis au moins un noeud du réseau situé entre ledit terminal (10) client et ledit serveur (11); des moyens (51) d'analyse d'au moins une partie du contenu des messages capturés; des moyens d'identification (54) à partir des résultats d'analyse, des messages correspondant à l'initiation d'une connexion sécurisée par échange d'au moins un certificat entre le terminal (10) client et le serveur (11) ; des moyens (52) de vérification de la validité de l'un au moins des certificats ayant été transmis par le serveur (11) au terminal (10) client; des moyens (55) de protection du terminal (10) client, activés dès lors que les moyens (52) de vérification n'ont pu vérifier la validité du certificat transmis par le serveur. De façon avantageuse, les moyens (52) de vérification de la validité d'au moins un certificat transmis par le serveur (11) au terminal (10) client, sont des moyens de vérification d'au moins un critère prédéterminé attaché à l'un au moins des certificats à vérifier et appartenant au groupe comprenant au moins: une date de validité du certificat; un niveau de confiance associé à l'autorité de certification ayant émis le certificat du serveur; une valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine du serveur et l'adresse réseau du service hébergé par le serveur; une valeur de booléen indiquant si le certificat transmis au terminal client par le serveur n'a pas été révoqué et/ou si le certificat du serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur le réseau. Préférentiellement, les moyens (55) de protection du terminal (10) client activent des moyens de coupure (56) volontaire de la connexion réseau en cours entre le terminal (10) client et le serveur (11) sur le réseau de communication, et/ou de déclenchement d'au moins une alerte selon laquelle une tentative d'usurpation de l'identité du serveur (11) par un terminal (13) pirate est détectée. Avantageusement, les moyens de coupure (56) volontaire de la connexion réseau en cours tiennent compte d'au moins un paramètre de connexion entre le terminal (10) client et le serveur (11) préalablement déterminé par les moyens (51) d'analyse, les paramètres appartenant au groupe comprenant au moins: une adresse IP source; une adresse IP de destination; au moins un port TCP source; au moins un port TCP de destination; les deux numéros de séquence TCP pour une coupure de connexion s'appuyant sur le protocole TCP/IP. De façon également avantageuse, la connexion établie au travers dudit 10 réseau est du type appartenant au groupe comprenant au moins: une connexion SSL ( secure socket layer en anglais ou couche de connexion sécurisée en français) ; une connexion TLS ( Transport layer security en anglais ou couche de transport sécurisée en français) ; une connexion SHTTP ( Secure HTTP en anglais, ou HTTP sécurisé en français) ; le réseau de communication pouvant un réseau privé ou bien un réseau public du type réseau TCP/IP, ou bien une association des deux types. Dans un mode de réalisation préféré du module (40) selon l'invention, ce dernier comprend en outre des moyens (53) de décision manuels ou automatiques aptes à initier l'activation des moyens (55) de protection du terminal client lorsque le certificat transmis par le serveur n'est pas valide, les moyens de décision servant donc d'interface entre les moyens (52) de vérification de la validité du certificat et les moyens (55) de protection. L'invention concerne également un pare-feu (42) permettant de filtrer les paquets de données qu'un terminal (10) client échange avec au moins un serveur (11) au travers un réseau de communication, et comportant au moins un module (40) apte à superviser et à contrôler la validité et/ou la légitimité d'une connexion réseau établie entre le terminal (10) client et l'un au moins des serveurs (11). Il est bien entendu qu'un tel module (40) selon l'invention pourra être intégré à tout autre type de composant physique et/ou logiciel servant de relais à des paquets d'information sur un réseau de communication, ou bien servant à filtrer et/ou à écouter de tels paquets d'information depuis un noeud d'interconnexion du réseau de communication considéré. L'invention concerne enfin un système de protection contre le piratage d'une connexion (12) entre au moins un terminal (10) client et au moins un serveur (11), l'un au moins des terminaux (10) clients étant connectés à l'un au moins des serveurs (1l) via une connexion (12) sur un réseau de communication. Un tel système selon l'invention comprend de façon avantageuse au moins un module (40) apte à superviser et à contrôler la validité et/ou la légitimité d'une connexion réseau établie entre l'un au moins des terminaux (10) clients avec l'un au moins des serveurs (11). Préférentiellement, l'un au moins des modules (40) aptes à superviser et à contrôler la validité et/ou la légitimité d'une connexion réseau établie entre l'un au moins des terminaux (10) client et l'un au moins des serveurs (11) distants est positionné au niveau d'un noeud d'interconnexion réseau, du type appartenant au groupe comprenant: un pare-feu séparant au moins deux réseaux de communication; un routeur réseau; une passerelle réseau. Un tel positionnement du module (40) selon l'invention sur le réseau de communication considéré autorise ainsi de façon avantageuse une plus grande efficacité une vue complète des communications et des messages échangés entre les terminaux clients à protéger et les serveurs utilisant une connexion suivant le protocole sécurisé TLS/SSL, pouvant être obtenue. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple illustratif et non limitatif, faite 30 en référence aux dessins annexés parmi lesquels: la figure 1 présente une connexion normale sur un réseau de communication, entre un terminal client et un serveur; la figure 2 illustre le principe général d'une attaque de type man in the middle durant laquelle un pirate usurpe la fonction de serveur à la vue d'un 5 terminal client; la figure 3 illustre le principe général d'une attaque de type man in the middle dans le cadre d'une connexion sécurisée SSL; la figure 4 donne un exemple d'architecture du système selon l'invention; la figure 5 présente les différents sous-modules composant le module (40) selon l'invention apte à superviser et à contrôler la légitimité d'une connexion (41) réseau entre un terminal (10) client et unserveur (11) selon un mode de réalisation de l'invention; la figure 6 est un organigramme des grandes étapes du procédé de protection contre le piratage d'une connexion (12) sécurisée entre un terminal (10) client 15 et un serveur (11), selon un mode de réalisation de l'invention. 6. Description d'un mode de réalisation préféré de l'invention La présente invention concerne donc un procédé et un dispositif de protection contre le piratage d'une connexion entre un terminal client et un serveur. L'originalité du procédé selon cette invention réside essentiellement dans la façon de protéger efficacement l'utilisateur qui ne pourra plus faire d'erreurs lorsqu'il interprète mal les messages d'alerte de sécurité renvoyés par son navigateur, au risque d'accepter le certificat d'un pirate informatique. La méthode offre pour avantage d'être transparente, tout en pouvant s'appliquer à n'importe quel type de réseau, la seule contrainte consistant en la nécessité de pouvoir intercepter les paquets d'information correspondant aux messages échangés entre un terminal client et un serveur donnés, sur le réseau de communication sous-jacent. Aucune limitation sur l'architecture réseau ni sur la configuration des 30 postes clients n'est donc imposée par l'invention. Le but de l'invention réside dans la capacité du procédé et du dispositif de réaliser une coupure de connexion SSL/TLS, lorsque celle-ci n'apparaît pas valide, c'est-à-dire lorsque le certificat du serveur ne correspond pas à celui attendu par le terminal client de l'utilisateur -différence détectée dans le nom de domaine complet qualifié ( Fully Qualified Domain Name ) qui montre que le site Web saisi par l'utilisateur est différent du contenu du champ correspondant du certificat, ou bien dès lors qu'un message de notification soulève l'occurrence d'un problème potentiel de confiance concernant la validité de l'émetteur. En effet, une attaque particulièrement usitée a pour principe d'intercepter les communications des clients voulant réaliser une connexion SSL/TLS, et de leur présenter un certificat invalide qui sera alors accepté par les utilisateurs pour des raisons de non compréhension de l'alerte: le pirate se fait passer pour le site Web sur lequel l'utilisateur comptait aller. L'invention propose de résoudre cette problématique de piratage au moyen d'une détection des attaques au moment de leur survenue, puis en réalisant une coupure de la connexion réseau SSL/TLS, dès lors qu'une attaque est détectée. Il est donc nécessaire que le dispositif déployé soit positionné judicieusement sur un réseau à protéger de manière à avoir une vue complète du trafic généré par les utilisateurs entre leur terminal client et un serveur accessible sur le même réseau, et de pouvoir ainsi générer un évènement permettant d'isoler le terminal client du réseau, avant que le pirate informatique n'ait pu récupérer les données sensibles auprès de l'utilisateur. Un tel évènement peut prendre la forme, par exemple et de façon non limitative, d'une coupure du terminal client au réseau, de façon à mettre fin volontairement à la session qui aurait abouti irrévocablement à la transmission de données sensibles par l'utilisateur au pirate informatique ayant usurpé le certificat du serveur. La figure 6 illustre les étapes d'un procédé selon un mode de réalisation de l'invention. Une première étape (60) consiste à capturer le trafic généré sur le réseau de communication écouté (typiquement Ethernet), depuis un noeud du réseau situé entre le terminal client et le serveur et bien positionné typiquement à un point d'interconnexion de un ou plusieurs réseaux - de façon à pouvoir obtenir une vue complète des communications et des messages échangés entre les terminaux clients à protéger et les serveurs externes utilisant une connexion suivant le protocole sécurisé TLS/SSL. Le dispositif capturant le trafic et connecté par exemple à un noeud du réseau peut être un routeur ou un pare-feu 42 (ou firewall en anglais) séparant le réseau privé d'une entreprise d'un réseau public du type Internet, ou bien encore tout autre composant physique et/ou logiciel pouvant constituer un point de passage des messages transitant sur le réseau (un routeur, par exemple), ou bien apte à écouter les communications sur le réseau (un agent logiciel, un agent communicant, par exemple) Une deuxième étape (61) consiste ensuite à analyser le trafic capturé et à repérer dans ce dernier le trafic s'appuyant sur le protocole SSL/TLS entre un terminal client et un serveur, de façon à ne cibler que les connexions qui doivent donner lieu à une authentification par certificat du serveur au minimum en vue de l'échanges de données sensibles (codes bancaires, par exemple). Une troisième étape (64) consiste à identifier les messages correspondant à l'initiation d'une connexion sécurisée et à extraire des messages échangés au format du protocole SSL/TLS le certificat transmis par le serveur au terminal client. Une quatrième étape (62) consiste à vérifier la validité du certificat, de façon à pouvoir valider et certifier la validité de ce certificat, relativement à son 25 émetteur. Cette étape permet, en fonction du certificat récupéré à l'étape d'identification (64), de vérifier la validité du certificat en fonction de plusieurs critères, parmi lesquels: la date de validité du certificat; le niveau de confiance associé à l'autorité de certification ayant émis le certificat du serveur; la valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine du serveur et l'adresse réseau, par exemple l'adresse Internet, du service hébergé par le serveur; la valeur cle booléen indiquant si le certificat transmis au terminal client par le serveur n'a pas été révoqué c'est-à-dire si le certificat du serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur le réseau. Enfin, une cinquième étape (63) est exécutée, dès lors que le résultat de l'étape de vérification de la validité du certificat du serveur n'a pu aboutir positivement, au vu des critères de vérification du certificat considéré. Elle consiste à décider de la protection à apporter au terminal serveur. A titre d'exemple illustratif et non limitatif, on précise ici le type d'évènement pouvant être généré lors d'une sixième étape (65) dès lors que le certificat du serveur ne peut être valablement vérifié et/ou que son émetteur ne peut être valablement reconnu et/ou identifié avec un bon niveau de confiance. Les sessions sécurisées SSL/TLS entre terminaux client et serveur sont basées sur le plus souvent sur le protocole TCP. Ainsi, de façon relativement simple, et de façon à pouvoir isoler momentanément le terminal client du réseau et donc du terminal pirate usurpateur, une coupure de la connexion TCP/IP est réalisée entre le terminal client et le terminal serveur pirate. Par exemple, il est possible de réaliser une coupure d'une connexion TCP à la volée en émettant un paquet de réinitialisation (RST) de la connexion, entre le serveur pirate et le terminal client (ou vice-versa), en utilisant les bons paramètres (adresses IP source et destination, ports source et destination, numéros de séquence, etc.). Plus précisément et comme illustré sur la figure 5, l'invention met en oeuvre un module (40) comprenant: - un module (50) de capture de trafic; un module (51) d'analyse de trafic; - un module (54) d'identification; un module (52) de vérification de la validité du certificat serveur; - un module (53) de décision; - un module (55) de protection. Le module (50) de capture de trafic a la charge de capturer le trafic sur le réseau écouté (typiquement Ethernet). Pour ce faire, la technique la plus usitée consiste à utiliser des outils à base de PCAP (pour Packet Capture en anglais ou capture de paquets en français) qui permettent de capturer tout ou partie des informations transitant à travers un réseau informatique. Des bibliothèques spécifiques, telle libcap existent, lesquelles permettent aisément de réaliser ce type d'écoute de trafic. A la suite de quoi, il est parfaitement possible de transmettre l'ensemble des paquets capturés au module d'analyse de trafic qui sera ainsi en mesure d'analyser et d'interpréter le contenu des paquets reçus. Le positionnement du module (50) de capture de trafic sur le réseau à écouter est déterminant. Il n'est possible en effet d' écouter les informations transitant à travers un réseau informatique que si l'équipement réalisant l'écoute y accède physiquement. Par conséquent, il est préférable de positionner le module de capture de trafic au niveau d'une interconnexion réseau (un noeud réseau par exemple) par laquelle tous les paquets devront transiter. Par exemple, dans le cadre d'une entreprise il apparaît judicieux de positionner l'invention au niveau du pare-feu (42) d'interconnexion séparant le réseau de l'entreprise du réseau Internet. Un tel positionnement est illustré sur la figure 4. Le module (51) d'analyse de trafic a la charge d'analyser le trafic capturé par le module (50) de capture de trafic et de repérer le trafic SSL/TLS entre un terminal client et un serveur. Ce module (51) est capable de comprendre les protocoles SSL/TLS. Le module d'analyse de trafic est capable d'identifier des paramètres déterminés entre un terminal client et un serveur, typiquement au travers des informations suivantes: - adresse IP du terminal client; -adresse IP du serveur; ports TCP source et destination entre lesquels la communication est établie; - les deux numéros de séquence TCP; - le certificat du serveur présenté au terminal client. De la même manière, ce module est aussi capable de récupérer le nom de machine (début de l'URL "Uniform Resource Locator") par exemple et de manière non exclusive grâce à une analyse des paquets DNS (pour Domain Name Service en anglais, ou service de nom de domaine en français) qui permettent de résoudre un nom en une adresse IP. En effet, la connexion depuis le terminal client est une connexion TCP/IP d'une adresse IP source vers une adresse IP destination. Il est donc possible grâce au module d'analyse de récupérer la requête DNS émise par le terminal client afin de connaître l'adresse réseau du serveur auprès duquel le terminal client compte se connecter. Le module d'identification (54) est apte à partir des résultats d'analyse à reconnaître l'initiation d'une connexion sécurisée et à en extraire le certificat qui est présenté au terminal client par le serveur. Le certificat ainsi que les informations extraites par le module (51) d'analyse de trafic sont alors transmises au module (52) de vérification de la validité du certificat serveur. Le module (52) de vérification de validité du certificat serveur récupère les informations issues du module d'analyse de trafic et du module d'identification. Le but est maintenant de valider que la connexion en cours est légitime. La vérification de légitimité de la connexion est réalisée de la même manière que celle effectuée par le terminal client, à savoir la vérification des paramètres suivants: la date de validité du certificat; le niveau de confiance associé à l'autorité de certification ayant émis le certificat du serveur; la valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine du serveur et l'adresse réseau, par exemple l'adresse Internet, du service hébergé par le serveur; la valeur de booléen indiquant si le certificat transmis au terminal client par le serveur n'a pas été révoqué c'est-à-dire si le certificat du serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur le réseau. La vérification de la date de validité du certificat est réalisée facilement par une lecture du champ (date de validité) approprié dans le certificat du serveur. L'opérateur du procédé peut définir les autorités de certification qu'il considère comme étant de confiance. Cette liste peut être différente de celle du navigateur de l'utilisateur. La vérification du niveau de confiance associé à l'autorité de certification est réalisée facilement par une lecture du champ (AC émettrice) approprié dans le certificat serveur. La correspondance entre le nom de domaine du serveur et l'adresse réseau est réalisée facilement grâce au champ approprié ( Distinguished Name en anglais) dans le certificat du serveur avec les informations issues du module d'analyse de trafic. La vérification de la révocation du certificat du serveur s'effectue aisément au moyen d'une connexion avec le serveur de révocation de l'autorité de certification du certificat serveur. A la suite de quoi, il sera possible pour ce module de vérifier si le certificat du serveur a été révoqué ou pas. En effet, les navigateurs des terminaux clients ne vérifient pas forcément les listes de révocation des certificats des terminaux serveurs. Le procédé permet alors de résoudre cette problématique. Le module (52) de vérification de validité du certificat serveur transmet au module de décision alors le résultat final de son analyse avec des informations supplémentaires, parmi lesquelles: le résultat de l'analyse: les paramètres du certificat serveur sont tous vérifiés, ou non; l'adresse IP source; - l'adresse IP destination; les ports source et destination; les deux numéros de séquence TCP. Le module (53) de décision a en charge de décider de couper ou non la connexion en fonction du résultat précédent. Une telle coupure peut être décidée automatiquement ou manuellement. En effet, il est alors possible de dire à ce module soit de couper toutes les connexions lorsqu'une connexion invalide a été détectée; ou alors d'avertir un administrateur de sécurité afin qu'il décide de lui-même d'activer la coupure ou non. Bien entendu, pour plus d'efficacité, il est préférable d'avoir une action rapide et donc de pouvoir entreprendre une contre-mesure rapidement. Si la décision d'entreprendre une contre-mesure a été prise, que cela soit fait automatiquement ou manuellement, alors le module de décision envoie directement les informations suivantes au module de protection: l'adresse IP source; l'adresse IP destination; les ports source et destination; les deux numéros de séquence TCP. Le module (55) de protection a en charge d'engager une contre-mesure en fonction des informations issues du module de décision, ainsi que des méthodes de contre-mesure qui sont implantées dans son logiciel. Il est par exemple tout à fait possible d'injecter des paquets de coupure de connexion (RST) TCP qui permettent alors à la session TCP d'être terminée brutalement. Ceci est réalisable facilement lorsque le module a la connaissance des informations suivantes: - l'adresse IP source; l'adresse IP de destination; - les ports source et destination; - les deux numéros de séquence TCP. Ce module (55) est en mesure de créer les paquets nécessaires à cet effet grâce à des bibliothèques disponibles en libre service sur Internet comme la libnet . Il suffit alors de créer des paquets conformes en fonction des paramètres précités, et d'envoyer deux paquets TCP RST, le premier vers la source et le deuxième vers la destination. Ces derniers seront alors acceptés par les piles TCP/IP des terminaux client et serveur, coupant alors la connexion sécurisée SSL/TLS de manière très simple et non gênante pour l'utilisateur final, ce dernier ayant uniquement l'impression que le site Web sur lequel il se connecte ne fonctionne pas ou est indisponible. REVENDICATIONS 1. Procédé de protection contre le piratage d'une connexion (12) entre un terminal (10) client et un serveur (11), ledit terminal (10) client étant connecté audit serveur (11) via une connexion (12) sur un réseau de communication, caractérisé en ce qu'il comporte: une étape de supervision continue des messages échangés entre ledit terminal client et ledit serveur au travers dudit réseau de communication, ladite étape de supervision comportant au moins: ^ une sous-étape (60) de capture d'au moins certains messages échangés sur ledit réseau entre ledit terminal client et ledit serveur; ^ une sous-étape (61) d'analyse d'au moins une partie du contenu desdits messages capturés; ^ une sous-étape (64) d'identification à partir de ladite sous-étape d'analyse, des messages correspondant à l'initiation d'une connexion sécurisée entre ledit terminal client et ledit serveur; ^ une sous-étape (62) de vérification de la validité d'au moins un certificat transmis par ledit serveur audit terminal client, ledit certificat ayant été capturé à ladite sous-étape d'identification; une étape (63) de réaction et de protection dudit terminal client dès lors que la validité dudit certificat n'a pu être vérifiée. 2. Procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon la revendication 1, caractérisé en ce que ladite sous-étape (62) de vérification de la validité d'au moins un certificat transmis par ledit serveur audit terminal client, est une étape de vérification d'au moins un critère prédéterminé concernant ledit au moins un certificat et appartenant au groupe comprenant au moins: une date de validité dudit certificat; 15 20 un niveau de confiance associé à l'autorité de certification ayant émis ledit certificat du serveur; une valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine dudit serveur et l'adresse réseau du service hébergé par 5 ledit serveur; une valeur de booléen indiquant si ledit certificat transmis audit terminal client par ledit serveur n'a pas été révoqué et/ou si ledit certificat dudit serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur ledit réseau. 3. Procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon la revendication 2, caractérisé en ce que ladite sous-étape (63) de réaction et de protection dudit terminal client est exécutée dès qu'un au moins des critères prédéterminés concernant ledit au moins un certificat à vérifier n'a pu être vérifié à ladite sous-étape (62) de vérification. 4. Procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite sous-étape (63) de réaction et de protection dudit terminal client est suivie d'une étape de coupure (65) volontaire de ladite connexion en cours entre ledit terminal client et ledit serveur sur ledit réseau de communication. 5. Procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon la revendication 4, caractérisé en ce que ladite sous-étape de coupure (65) volontaire de ladite connexion en cours utilise au moins un paramètre (66) de connexion entre ledit terminal client et ledit serveur obtenu durant ladite sous-étape (61) d'analyse desdits messages échangés, lesdits paramètres appartenant au groupe comprenant au moins: - une adresse IP source; - une adresse IP de destination; - au moins un port TCP source; - au moins un port TCP de destination; - les deux numéros de séquence TCP pour une coupure de connexion s'appuyant sur le protocole TCP/IP. 6. Procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite connexion est du type appartenant au groupe comprenant au moins: une connexion SSL ( secure socket layer en anglais ou couche de connexion sécurisée en français) ; une connexion TLS ( Transport layer security en anglais ou couche de transport sécurisée en français) ; une connexion SHTTP ( Secure HTTP en anglais, ou HTTP sécurisé en français) ; et en ce que ledit réseau est un réseau privé ou un réseau public du type réseau TCP/IP. 7. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour l'exécution des étapes du procédé de protection contre le piratage d'une connexion entre un terminal client et un serveur selon l'une quelconque des revendications 1 à 6 lorsque ledit programme est exécuté sur un ordinateur. 8. Module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) entre un terminal (10) client et un serveur (11), caractérisé en ce qu'il comprend: des moyens (50) de capture d'au moins certains messages échangés sur ledit réseau entre ledit terminal (10) client et ledit (11) serveur, depuis au moins un noeud dudit réseau situé entre ledit terminal (10) client et ledit serveur (Il) ; des moyens (51) d'analyse d'au moins une partie du contenu desdits messages capturés; des moyens d'identification (54) à partir des résultats d'analyse, des messages correspondant à l'initiation d'une connexion sécurisée par échange d'au moins un certificat entre ledit terminal (10) client et ledit serveur (11) ; - des moyens (52) de vérification de la validité dudit au moins un certificat ayant été transmis par ledit serveur (11) audit terminal (10) client; des moyens (55) de protection dudit terminal (10) client activés dès lors que lesdits moyens (52) de vérification n'ont pu vérifier la validité dudit au moins un certificat transmis par ledit serveur. 9. Module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) entre un terminal (10) client et un serveur (11), selon la revendication 8, caractérisé en ce que lesdits moyens (52) de vérification de la validité d'au moins un certificat transmis par ledit serveur (11) audit terminal (10) client, sont des moyens de vérification d'au moins un critère prédéterminé attaché audit au moins un certificat et appartenant au groupe comprenant au moins: une date de validité dudit certificat; un niveau de confiance associé à l'autorité de certification ayant émis ledit certificat dudit serveur; une valeur de booléen indiquant s'il existe une correspondance entre le nom de domaine dudit serveur et l'adresse réseau du service hébergé par ledit serveur; une valeur de booléen indiquant si ledit certificat transmis audit terminal client par ledit serveur n'a pas été révoqué et/ou si ledit certificat dudit serveur n'est pas contenu dans une liste de certificats ayant fait l'objet d'une opposition, accessible sur ledit réseau. 10. Module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) entre un terminal (10) client et un serveur (11), selon l'une quelconque des revendications 8 et 9, caractérisé en ce que lesdits moyens (55) de protection dudit terminal (10) client activent des moyens de coupure (56) volontaire de ladite connexion en cours entre ledit terminal (10) client et ledit serveur (11) sur ledit réseau de communication, et/ou de déclenchement d'au moins une alerte selon laquelle une tentative d'usurpation de l'identité dudit serveur (11) par un terminal (13) pirate est détectée. 11. Module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) entre un terminal (10) client et un serveur (11), selon la revendication 10, caractérisé en ce que lesdits moyens de coupure (56) volontaire de ladite connexion réseau en cours tiennent compte d'au moins un paramètre de connexion entre ledit terminal (10) client et ledit serveur (11) préalablement déterminé par lesdits moyens (51) d'analyse, lesdits paramètres appartenant au groupe comprenant au moins: une adresse IP source; une adresse IP de destination; au moins un port TCP source; au moins un port TCP de destination; les deux numéros de séquence TCP pour une coupure de connexion s'appuyant sur le protocole TCP/IP. 12. Module (40) apte à superviser et à contrôler la légitimité d'une connexion (41) entre un terminal (10) client et un serveur (11), selon l'une quelconque des revendications 8 à 11, caractérisé en ce que ladite connexion établie est du type appartenant au groupe comprenant au moins: une connexion SSL ( secure socket layer en anglais ou couche de connexion sécurisée en français) ; une connexion TLS ( Transport layer security en anglais ou couche de transport sécurisée en français) ; une connexion SHTTP ( Secure HTTP en anglais, ou HTTP sécurisé en français) ; et en ce que ledit réseau est un réseau privé ou un réseau public du type réseau TCP/IP. 13. Module (40) apte à superviser et à contrôler la légitimité d'une connexion réseau entre un terminal client et un serveur selon l'une quelconque des revendications 8 à 12, caractérisé en ce qu'il comprend en outre des moyens (53) de décision manuels ou automatiques aptes à initier l'activation desdits moyens (55) de protection dudit terminal client lorsque ledit certificat transmis par ledit serveur n'est pas valide, lesdits moyens de décision servant d'interface entre lesdits moyens (52) de vérification de la validité dudit certificat et lesdits moyens (55) de protection. 14. Pare-feu (42) permettant de filtrer les paquets de données qu'un terminal (10) client échange avec au moins un serveur (11) au travers un réseau de communication, caractérisé en ce qu'il comporte au moins un module (40) apte à superviser et à contrôler la validité et/ou la légitimité d'une connexion réseau établie entre ledit terminal (10) client et ledit au moins un serveur (11), selon l'une quelconque des revendications 8 à 13. 15. Système de protection contre le piratage d'une connexion (12) entre au moins un terminal (10) client et au moins un serveur (11), ledit au moins un terminal (10) client étant connecté audit au moins un serveur (11) via une connexion (12) sur un réseau de communication, caractérisé en ce qu'il comprend au moins un module (40) apte à superviser et à contrôler la validité et/ou la légitimité d'une connexion établie entre ledit au moins un terminal (10) client et ledit au moins un serveur (11), selon l'une quelconque des revendications 8 à 13. 16. Système de protection contre le piratage d'une connexion (12) entre au moins un terminal (10) client et au moins un serveur (11), selon la revendication 15, caractérisé en ce que ledit au moins un module (40) apte à superviser et à contrôler la validité et/ou la légitimité d'une connexion réseau établie entre ledit au moins un terminal (10) client et ledit au moins un serveur (11) distant est positionné au niveau d'un noeud d'interconnexion réseau, du type appartenant au groupe comprenant: un pare-feu séparant au moins deux réseaux de communication; un routeur réseau; une passerelle réseau.