WO2006134072A1 - Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public - Google Patents

Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public Download PDF

Info

Publication number
WO2006134072A1
WO2006134072A1 PCT/EP2006/063032 EP2006063032W WO2006134072A1 WO 2006134072 A1 WO2006134072 A1 WO 2006134072A1 EP 2006063032 W EP2006063032 W EP 2006063032W WO 2006134072 A1 WO2006134072 A1 WO 2006134072A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
client terminal
connection
certificate
network
Prior art date
Application number
PCT/EP2006/063032
Other languages
English (en)
Inventor
Laurent Butti
Olivier Charles
Franck Veysset
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2006134072A1 publication Critical patent/WO2006134072A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218—Distributed architectures, e.g. distributed firewalls

Definitions

  • IP Internet Protocol
  • the invention relates to increasing the level of security in the exchanges between client terminals and / or servers for transactions of a sensitive nature, requiring perfect identification and authentication between the terminals they imply, for example in the context secure transactions relating to access to online banking or e-commerce services.
  • the currently used protocols do not provide any authentication or confidentiality of the data exchanged between two clients communicating on the network commonly called the Internet.
  • secure protocols In order to overcome the security problems encountered mainly on public communication networks and variable quality of service, secure protocols, generally implemented at the application level, have been designed to provide authentication and confidentiality mechanisms in exchanges and transactions initiated between remote terminals connected to these networks.
  • SSL Secure Socket Layer
  • TLS Transport Layer Security
  • SSL and TLS are widely used in e-commerce or online banking applications. Because of the value of the applications they aim to protect, they are under attack to circumvent their level of security (information retrieval in SSL / TLS communication, typically login credentials or card numbers banking).
  • SSL is intended to secure communications, using the standard
  • SSL and TLS do not require special adaptation of network elements, unlike a protocol like IPsec. There are two levels of security in SSL and TLS:
  • the server and the client terminal are both equipped with a certificate: the client and the server can then authenticate each other.
  • a client terminal connects to an SSL-secured merchant site hosted by a server
  • the latter sends it a certificate containing its public key, signed by a Certificate Authority (CA), as well as a set of cryptographic mechanisms supported by the server.
  • CA Certificate Authority
  • the client checks the validity of the certificate and then creates a secret key randomly.
  • the SSL / TLS protocol is therefore based on a process of authentication by public key and certificate exchanges between client terminals and server.
  • Asymmetric cryptography thus ensures that the message sent remains confidential, without being forced to use a "safe" channel beforehand to exchange the keys.
  • the first key remains private and secret and is generally known only by its holder.
  • the other key is public and is usually in an electronic directory.
  • the question then is how to be sure that the public key received belongs to the sender, not to a hacker?
  • the digital certificate has been created. It allows to securely associate a public key and the terminal that holds it.
  • CA recognized and independent certification authority
  • a certificate contains a number of information, some of which can be cited as illustrative examples:
  • the public key described in the form of a plurality of information on the public key of the certificate
  • checking the validity of the certificate mainly means: - checking its validity date
  • the SSL / TLS protocol is today one of the most used security protocols on the Internet, particularly as regards the consultation of merchant sites or banking services.
  • First phase authentication of the server: following a request from a client terminal, the server sends its certificate to the client terminal and proposes a list of cryptographic algorithms that can be used.
  • the client terminal verifies the validity of the server certificate according to the procedure described above: automatic checking of the validity date, the issuer, the object and the non-revocation, then asks the user if wants to override the control in case of failure.
  • Second phase (optional) authentication of the client terminal: the server (and only it) can ask the client terminal to authenticate itself by first asking for its certificate. If the certificate verification fails, then the entity that detects the anomaly immediately sends an alert to the other entity.
  • the following messages are provided in the standard:
  • the SSL protocol offers a good level of security, it is possible to exploit a human error to perform a "Man-in-the-Middle” attack, or attack by the medium.
  • the principle of such an attack is relatively simple: the hacker is placed between the user's client terminal and the server offering the service the user wants to access. In the manner of a relay, the hacker, by means of a computer terminal will impersonate the client terminal server function, and impersonate the client terminal to the server.
  • the hacker can intercept all the information sent by the client terminal, inject or modify traffic "on the fly”.
  • the certificate mechanisms used in the SSL protocol offer certain guarantees of security to the user. Indeed, since the server is normally the only one to know the private key associated with the certificate presented to the client terminal, the hacker performing an attack of the type "Man in the Middle” will be able to relay the traffic, but this one being encrypted, it will not be able to read it and thus to access its contents.
  • the security of the connection will then rest only on the user who is responsible for detecting that the certificate presented by his Web browser (in the case of a conventional SSL connection via a browser) is not valid, or was usurped.
  • Web browsers will detect an anomaly in the certificate, which does not correspond to that expected (for example, detection of a difference between the fully qualified domain name or "Fully Qualified Domain Name" in English, the site Web entered by the user via FURL typed, and the corresponding field of the certificate presented by the server).
  • the browser of the user then reports to the latter a message notifying him that a potential problem of confidence is detected.
  • the principle of the attack is based on the difficulty for a novice or average computer user to understand the meaning of such a message and the scope of his act if he chooses to ignore this message by accepting an invalid certificate presented by a hacker, the latter can then access the content of the communication.
  • the client was deceived by the hacker who gave him a bad certificate: the SSL session is controlled by the attacker.
  • the numbered SSL link (1) is in this case totally accessible by the attacker, who in fact provides the termination of this connection.
  • the hacker is then able to establish a connection (2) with the legitimate server. It will be able to replay the data provided by the user (playing the role of "proxy” or relay) and thus completely hide his intervention in the eyes of a standard user.
  • the invention described here proposes a mechanism for forcing a security policy on a given network so as to avoid the problem of user errors, as mentioned above.
  • An object of the invention is to provide a technique that makes it possible to detect an attack by a hacker presenting to a user a fraudulent certificate, so as to perform a "Man in the Middle" type attack.
  • Another object of the invention is to provide a technique that is independent of the behavior of the user through its client terminal, regardless of the vulnerability of this user to a hacker.
  • An additional object of the invention is to provide such a technique that allows to isolate the client terminal of the communication network, as soon as an attack of a pirate is detected.
  • a final objective of the invention is to provide such a technique which is relatively simple to implement and relatively inexpensive in terms of operation. 4. Summary of the invention These objectives, as well as others which will appear later, are achieved according to the invention by means of a method of protection against hacking of a network connection (12) between a client terminal (10) and a client. server (11), the terminal
  • such a method comprises:
  • the supervision step comprising at least:
  • Such a technical approach according to the invention advantageously makes it possible to anticipate any risk that a user of the client terminal may accept to go beyond the control of the validity of the server's certificate, when the control has failed at the identification stage and authentication of the server by the client terminal.
  • the substep (62) for verifying the validity of at least one certificate transmitted by the server (11) to the client terminal (10) is a step of verifying at least one predetermined criterion attached to the server certificate and belonging to the group comprising at least:
  • the sub-step (63) of reaction and protection of the client terminal is executed as soon as at least one of the predetermined criteria relating to the server certificate to be verified could not be verified in the verification sub-step (62). .
  • the sub-step (63) for reaction and protection of the client terminal is followed by a step of voluntarily cutting (65) the current network connection established between the client terminal and the server.
  • a step of voluntarily cutting (65) the current network connection established between the client terminal and the server is in fact to prevent a new user or unaccustomed to messages inviting him to validate if he wishes to establish a secure connection from an expired certificate, or which he will not be able to certify origin, may be attacked by a hacker by inadvertently accepting a hacker certificate.
  • the voluntary substep (65) sub-step of the current network connection uses at least one connection parameter (66) between the client terminal and the server obtained during the substep (61) for analyzing the network connection. messages exchanged, the parameters belonging to the group comprising at least:
  • connection termination based on the TCP / IP protocol.
  • said connection is of the type belonging to the group comprising at least:
  • the communication network can be a private network as well as a public network of the TCP / IP network type, or a combination of the two previous types, for example.
  • the invention also relates to a computer program product downloadable from a communication network and / or recorded on a computer-readable and / or executable medium by a processor, comprising program code instructions for executing the steps of the method protection against hacking a connection between a client terminal and a server, as mentioned above, when the program is run on a computer.
  • the invention also relates advantageously to a module (40) able to supervise and control the legitimacy of a network connection (41) between a client terminal (10) and a server (11).
  • a module according to the invention comprises:
  • the means (52) for verifying the validity of at least one certificate transmitted by the server (11) to the client terminal (10) are means for verifying at least one predetermined criterion attached to the at least one certificate to be verified and belonging to the group comprising at least:
  • Boolean value indicating whether there is a correspondence between the server's domain name and the network address of the service hosted by the server; a Boolean value indicating whether the certificate transmitted to the client terminal by the server has not been revoked and / or the server certificate is not contained in a list of certificates that have been objected to, accessible on the network.
  • the means (55) for protecting the client terminal (10) activate means for intentionally cutting (56) the current network connection between the client terminal (10) and the server (11) on the communication network, and / or triggering at least one alert according to which an attempt to impersonate the server (11) by a hacker terminal (13) is detected.
  • the voluntary breaking means (56) of the current network connection take account of at least one connection parameter between the terminal (10) client and the server (11) previously determined by the means (51) of analysis, the parameters belonging to the group comprising at least:
  • connection established through said network is of the type belonging to the group comprising at least:
  • the communication network may be a private network or a public network of the TCP / IP network type, or a combination of the two types.
  • the latter further comprises manual or automatic decision means (53) capable of initiating the activation of the means (55) for protecting the client terminal when the certificate transmitted by the server is not valid, the decision means thus serving as an interface between the means (52) for checking the validity of the certificate and the means (55) of protection.
  • the invention also relates to a firewall (42) for filtering the data packets that a client terminal (10) exchanges with at least one server (11) through a communication network, and comprising at least one module ( 40) capable of supervising and controlling the validity and / or the legitimacy of a network connection established between the client terminal (10) and at least one of the servers (11).
  • such a module (40) can be integrated into any another type of physical and / or software component serving as a relay for information packets on a communication network, or for filtering and / or listening to such information packets from an interconnection node of the communication network considered.
  • the invention finally relates to a protection system against the hacking of a connection (12) between at least one client terminal (10) and at least one server (11), at least one of the client terminals (10) being connected at least one of the servers (11) via a connection (12) on a communication network.
  • Such a system according to the invention advantageously comprises at least one module (40) capable of supervising and checking the validity and / or the legitimacy of a network connection established between at least one of the client terminals (10) with at least one of the servers (11).
  • At least one of the modules (40) capable of supervising and checking the validity and / or the legitimacy of a network connection established between at least one of the client terminals (10) and at least one of the remote servers (11) are located at a network interconnection node, of the type belonging to the group comprising:
  • firewall separating at least two communication networks
  • FIG. 2 illustrates the general principle of a "man in the middle" type attack during which a hacker usurps the server function in the view of a client terminal;
  • FIG. 3 illustrates the general principle of a man-in-the-middle attack as part of a secure SSL connection
  • FIG. 4 gives an example of architecture of the system according to the invention.
  • FIG. 5 presents the various sub-modules composing the module (40) according to the invention able to supervise and control the legitimacy of a connection.
  • FIG. 6 is a flowchart of the major steps of the method of protection against hacking of a secure connection (12) between a client terminal (10) and a server (11), according to one embodiment of the invention.
  • the present invention thus relates to a method and a device for protecting against the hacking of a connection between a client terminal and a server.
  • the originality of the method according to this invention essentially lies in the way of effectively protecting the user who will no longer be able to make mistakes when he misinterprets the safety alert messages returned by his browser, at the risk of accepting the certificate of a hacker.
  • the method offers the advantage of being transparent, while being applicable to any type of network, the only constraint consisting in the need to be able to intercept the information packets corresponding to the messages exchanged between a client terminal and a client. given server, on the underlying communication network.
  • the object of the invention lies in the ability of the method and the device to perform an SSL / TLS connection break, when it does not appear to be valid, that is to say when the server certificate does not match.
  • the one expected by the user's endpoint - the difference detected in the Fully Qualified Domain Name ("qualified domain name") which shows that the website entered by the user is different from the content of the corresponding field of the certificate, or when a notification message raises the occurrence of a potential problem of trust regarding the validity of the issuer.
  • a particularly used attack has the principle of intercepting the communications of customers wanting to make an SSL / TLS connection, and present them with an invalid certificate which will then be accepted by the users for reasons of not understanding the alert: the hacker pretends to be the site
  • the invention proposes to solve this problem of piracy by means of an attack detection at the time of their occurrence, then by making a cut of the SSL / TLS network connection, as soon as an attack is detected.
  • the deployed device prefferably positioned on a network to be protected so as to have a complete view of the traffic generated by the users between their client terminal and a server accessible on the same network, and thus to be able to generate an event allowing to isolate the client terminal of the network, before the hacker could recover the sensitive data from the user.
  • Such an event may take the form, for example and without limitation, of a termination of the client terminal to the network, so as to voluntarily terminate the session which would have irrevocably led to the transmission of sensitive data by the user to hacker who spoofed the server certificate.
  • a first step (60) is to capture the traffic generated on the listened communication network (typically Ethernet), from a node of the network located between the client terminal and the server and well positioned - typically at an interconnection point of one or multiple networks - so that a complete view of the communications and messages exchanged between the client terminals to be protected and the external servers using a secure TLS / SSL protocol connection can be obtained.
  • the listened communication network typically Ethernet
  • the device capturing the traffic and connected for example to a node of the network may be a router or a firewall 42 (or "firewall" in English) separating the private network of a company from a public network of the Internet type, or well still any other physical component and / or software that can constitute a passage point for messages passing over the network (a router, for example), or able to listen to communications on the network (a software agent, a communicating agent, by example)
  • a second step (61) then consists of analyzing the captured traffic and locating therein the traffic relying on the SSL / TLS protocol between a client terminal and a server, so as to target only the connections that must give rise at least server certificate authentication for the exchange of sensitive data (eg bank codes).
  • sensitive data eg bank codes
  • a third step (64) consists of identifying the messages corresponding to the initiation of a secure connection and extracting messages exchanged in SSL / TLS format from the certificate transmitted by the server to the client terminal.
  • a fourth step (62) is to verify the validity of the certificate, so as to validate and certify the validity of this certificate, relative to its issuer.
  • This step makes it possible, depending on the certificate retrieved at the identification step (64), to check the validity of the certificate according to several criteria, among which: the validity date of the certificate; - the level of trust associated with the CA issuing the server certificate;
  • a fifth step (63) is executed, since the result of the verification step of the validity of the server certificate could not succeed positively, given the verification criteria of the certificate in question. It consists in deciding on the protection to be provided to the server terminal.
  • the type of event that can be generated during a sixth step (65) is specified here since the server's certificate can not be validly verified and / or its transmitter can not be validated. be validly recognized and / or identified with a good level of trust.
  • Secure SSL / TLS sessions between client and server endpoints are usually based on the TCP protocol.
  • TCP protocol the protocol for temporarily isolate the client terminal network and therefore the usurper hacker terminal
  • the invention implements a module (40) comprising: a module (50) for capturing traffic; a module (51) for analyzing traffic;
  • the traffic capture module (50) is responsible for capturing the traffic on the network being listened to (typically Ethernet). To do this, the most common technique is to use PCAP-based tools (for "Packet Capture” in English or capture packages in French) that capture all or part of the information transiting through a computer network.
  • PCAP-based tools for "Packet Capture” in English or capture packages in French
  • the positioning of the module (50) for capturing traffic on the network to be listened to is decisive. It is indeed possible to "listen" the information transiting through a computer network that if the equipment performing the listening physically access. Therefore, it is preferable to position the traffic capture module at a network interconnection (a network node for example) through which all packets will transit. For example, in the context of a company it seems advisable to position the invention at the level of the interconnection firewall (42) separating the network of the company from the Internet network. Such a positioning is illustrated in FIG. 4.
  • the traffic analysis module (51) is responsible for analyzing the traffic captured by the traffic capture module (50) and for locating the SSL / TLS traffic between a terminal. client and a server.
  • This module (51) is capable of understanding the SSL / TLS protocols.
  • the traffic analysis module is capable of identifying determined parameters between a client terminal and a server, typically through the following information:
  • this module is also able to recover the machine name (beginning of the "Uniform Resource Locator” URL) for example and non-exclusively thanks to a DNS packet analysis (for "Domain Name Service” in English, or French domain name service) that resolve a name into an IP address.
  • the connection from the client terminal is a TCP / IP connection from a source IP address to an address
  • the analysis module it is therefore possible thanks to the analysis module to retrieve the DNS request sent by the client terminal in order to know the network address of the server from which the client terminal intends to connect.
  • the identification module (54) is adapted from the analysis results to recognize the initiation of a secure connection and to extract the certificate that is presented to the client terminal by the server.
  • the certificate as well as the information extracted by the traffic analysis module (51) are then transmitted to the module (52) for verifying the validity of the server certificate.
  • the validity check module (52) of the server certificate retrieves information from the traffic analysis module and the identification module. The goal now is to validate that the current connection is legitimate.
  • the verification of legitimacy of the connection is performed in the same way as that performed by the client terminal, namely the verification of the following parameters:
  • the Boolean value indicating whether there is a correspondence between the server's domain name and the network address, for example the Internet address, of the service hosted by the server; the boolean value indicating whether the certificate transmitted to the terminal client by the server has not been revoked, that is to say if the server certificate is not contained in a list of certificates that have been the subject of an opposition, accessible on the network.
  • Verification of the validity date of the certificate is easily achieved by reading the appropriate field (validity date) in the server certificate.
  • the process operator can define which CAs he considers to be trusted. This list may be different from that of the user's browser.
  • the verification of the level of confidence associated with the certification authority is easily achieved by reading the appropriate field (issuing CA) in the server certificate.
  • the correspondence between the server's domain name and the network address is easily achieved by means of the appropriate field ("Distinguished Name") in the server certificate with the information from the traffic analysis module. Verification of server certificate revocation is easily accomplished through a connection to the server certificate CA revocation server. As a result, it will be possible for this module to check whether the server certificate has been revoked or not. In fact, the browsers of the client terminals do not necessarily check the lists of revocation of server terminal certificates. The method then makes it possible to solve this problem.
  • the validity check module (52) of the server certificate then transmits to the decision module the final result of its analysis with additional information, among which:
  • the parameters of the server certificate are all checked, or not;
  • the decision module (53) is in charge of deciding whether or not to cut the connection according to the previous result. Such a break can be decided automatically or manually. Indeed, it is then possible to tell this module is to cut all connections when an invalid connection has been detected; or notify a security administrator so that he or she decides to activate the cutoff or not. Of course, for more efficiency, it is better to have a fast action and therefore to be able to undertake a countermeasure quickly. If the decision to take a countermeasure has been taken, whether done automatically or manually, then the decision module sends the following information directly to the protection module:
  • the protection module (55) is responsible for initiating a countermeasure based on the information from the decision module, as well as the countermeasure methods that are implemented in its software. It is for example quite possible to inject TCP connection termination packets (RST) which then allow the TCP session to be terminated abruptly. This is easily achievable when the module is aware of the following information: - the source IP address;
  • This module (55) is able to create the necessary packages for this purpose through self-service libraries available on the Internet such as "libnet”. It is then sufficient to create conforming packets according to the aforementioned parameters, and to send two TCP RST packets, the first to the source and the second to the destination. The latter will then be accepted by the TCP / IP stacks of the client and server terminals, thus cutting the SSL / TLS secure connection in a very simple and non-awkward way for the end user, the latter only having the impression that the website on which it connects does not work or is unavailable.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de protection contre le piratage d'une connexion (12) entre un terminal (10) client et un terminal (11) serveur, le terminal (10) client étant connecté au terminal (11) serveur 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, 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, depuis au moins un nœud du réseau situé 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 d'analyse, des messages correspondant à l'initiation d'une connexion sécurisée entre le terminal client et le serveur ; une sous-étape (62) de vérification de la validité d'au moins un certificat transmis par le serveur au terminal client, le certificat ayant été capturé à la sous-étape (60) de capture des messages échangés; et une étape (63) de réaction et de protection du terminal client dès lors que la validité du certificat n'a pu être vérifiée.

Description

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 œuvre 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. II 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 SSL/TLS 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 à rencontre 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 FURL 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 œuvre 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. II 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 nœud 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 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 nœud 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 (11) 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 nœud 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 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 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 un serveur (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 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 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 nœud 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 nœud 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 é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 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. 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 œuvre 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 nœud 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. II 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.

Claims

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; - 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 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 nœud dudit réseau situé entre ledit terminal (10) client et ledit serveur (11) ;
- 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 nœud 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.
PCT/EP2006/063032 2005-06-14 2006-06-08 Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public WO2006134072A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506023A FR2887049A1 (fr) 2005-06-14 2005-06-14 Procede de protection contre le piratage d'un terminal client utilisant un connexion securisee avec un serveur sur un reseau public
FR0506023 2005-06-14

Publications (1)

Publication Number Publication Date
WO2006134072A1 true WO2006134072A1 (fr) 2006-12-21

Family

ID=35841920

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/063032 WO2006134072A1 (fr) 2005-06-14 2006-06-08 Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public

Country Status (2)

Country Link
FR (1) FR2887049A1 (fr)
WO (1) WO2006134072A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370007A (zh) * 2007-08-13 2009-02-18 北京三星通信技术研究有限公司 Wimax网络中对定位业务增强安全性和保护隐私权的方法
CN102916872A (zh) * 2011-08-02 2013-02-06 李帜 一种通信代理网关

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002011390A2 (fr) * 2000-07-31 2002-02-07 Andes Networks, Inc. Ameliorations apportees a des communications securisees

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002011390A2 (fr) * 2000-07-31 2002-02-07 Andes Networks, Inc. Ameliorations apportees a des communications securisees

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BELLOVIN S M: "DISTRIBUTED FIREWALLS", ;LOGIN:, November 1999 (1999-11-01), XP002313944 *
DJORDJEVIC I ET AL: "CERTIFICATE-BASED DISTRIBUTED FIREWALLS FOR SECURE E-COMMERCE TRANSACTIONS", JOURNAL OF THE INSTITUTION OF BRITISH TELECOMMUNICATIONS ENGINE ERS, BRITISH TELECOMMUNICATIONS ENGINEERING, LONDON, GB, vol. 2, no. 3, July 2001 (2001-07-01), pages 14 - 19, XP001107572, ISSN: 1470-5826 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370007A (zh) * 2007-08-13 2009-02-18 北京三星通信技术研究有限公司 Wimax网络中对定位业务增强安全性和保护隐私权的方法
CN102916872A (zh) * 2011-08-02 2013-02-06 李帜 一种通信代理网关

Also Published As

Publication number Publication date
FR2887049A1 (fr) 2006-12-15

Similar Documents

Publication Publication Date Title
EP2850770B1 (fr) Aiguillage du trafic de sécurité de la couche de transport utilisant une identification de nom de service
US10157280B2 (en) System and method for identifying security breach attempts of a website
US20170223054A1 (en) Methods and Apparatus for Verifying Transport Layer Security Server by Proxy
FR2844941A1 (fr) Demande d'acces securise aux ressources d'un reseau intranet
US20170063557A1 (en) Detection of fraudulent certificate authority certificates
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
WO2008145558A2 (fr) Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant
EP2484084A2 (fr) Procede et dispositifs de communications securisees contre les attaques par innondation et denis de service (dos) dans un reseau de telecommunications
Badra et al. Phishing attacks and solutions
US20170026184A1 (en) Detection of fraudulent digital certificates
Schwittmann et al. Domain impersonation is feasible: a study of ca domain validation vulnerabilities
Tally et al. Anti-phishing: Best practices for institutions and consumers
Haber et al. Attack vectors
WO2006134072A1 (fr) Procede de protection contre le piratage d'un terminal client utilisant une connexion securisee avec un serveur sur un reseau public
Wozak et al. End-to-end security in telemedical networks–a practical guideline
WO2009041804A2 (fr) Messagerie instantanée sécurisée
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
WO2010142740A1 (fr) Dispositif et procédé d'accès sécurisé à un service distant
WO2004017269A1 (fr) Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication
EP2109284A1 (fr) Mécanisme de protection contre les attaques de refus de service par réacheminement de trafic.
CN114257437B (zh) 远程访问方法、装置、计算设备及存储介质
Beck et al. Phishing in finance
FR2814880A1 (fr) Circuit d'inversion pour les conventions directe et indirecte d'un module electronique
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
Qureshi Analysis of Network Security Through VAPT and Network Monitoring

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06763601

Country of ref document: EP

Kind code of ref document: A1