WO2024068722A1 - Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants - Google Patents

Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants Download PDF

Info

Publication number
WO2024068722A1
WO2024068722A1 PCT/EP2023/076686 EP2023076686W WO2024068722A1 WO 2024068722 A1 WO2024068722 A1 WO 2024068722A1 EP 2023076686 W EP2023076686 W EP 2023076686W WO 2024068722 A1 WO2024068722 A1 WO 2024068722A1
Authority
WO
WIPO (PCT)
Prior art keywords
client device
server
relay node
dns
name resolution
Prior art date
Application number
PCT/EP2023/076686
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2024068722A1 publication Critical patent/WO2024068722A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • 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/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/59—Network arrangements, protocols or services for addressing or naming using proxies for addressing
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1475—Passive attacks, e.g. eavesdropping or listening without modification of the traffic monitored

Definitions

  • the invention belongs to the general field of telecommunications.
  • DNS Domain Name System
  • the DNS system is a fundamental component in the provision of IP services. Indeed, it makes it possible to associate a resource (such as a domain name, a URI (for “Uniform Resource Identifier” in English), etc.) with one or more IP addresses which allow a device (such as example a terminal) to access this resource.
  • a resource such as a domain name, a URI (for “Uniform Resource Identifier” in English), etc.
  • a server reachable in IPv4 publishes a type “A” DNS record (or RR for “Resource Record” in English) with the DNS system, while a server reachable in IPv6 publishes a record DNS type “AAAA” (or “Quad A Resource Record” in English); a server reachable in IPv4 and IPv6 publishes both types of recording.
  • a device wishes to establish communication with a so-called “recipient” server identified by a domain name (or FQDN for “Fully Qualified Domain Name” in English)
  • the DNS client embedded in the device sends a resolution request domain names (known as DNS query) to a server of the DNS system (or DNS server for the sake of simplification) by specifying in the query the type of registration desired (A or AAAA).
  • DNS query a resolution request domain names
  • AAAA type of registration desired
  • a device supporting both IPv4 and IPv6 protocols sends two DNS queries to a DNS server (one indicating a type A record, the other a type AAAA record).
  • the DNS server Upon receipt of this request, the DNS server responds to the device by sending it at least one IP address associated with the domain name to which the request relates if an entry corresponding to this domain name is available. If it does not have such an entry, the DNS server relays the request to another server according to the DNS hierarchy known to those skilled in the art. The response received from this other server is then relayed by the DNS server initially requested to the device originating the DNS request. The device extracts the IP address or addresses contained in the response and establishes communication with the recipient server typically using one of these IP addresses.
  • DNS communications These exchanges between the device and the DNS server (hereinafter referred to as “DNS communications” for the sake of simplification) are conventionally implemented in the clear, according to a mode called Do53 (or “unencrypted DNS” in English).
  • Do53 or “unencrypted DNS” in English. This unencrypted mode makes it possible for entities located on the DNS communications path to access sensitive information, for example for profiling purposes. Do53 therefore presents a risk of violating users' privacy.
  • the invention notably improves the aforementioned situation by proposing a method for processing a first name resolution request coming from a client device, this method being implemented by a name resolution server and comprising a sending to the client device a response to the first request comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request.
  • the processing method is remarkable in that it further comprises sending to the client device a plurality of elements comprising: at least one address of at least one relay node selected by the name resolution server to which the device client must send all or part of its messages containing data intended for the recipient server; and at least one scrambling instruction to be applied by the client device to said messages before sending them to said at least one relay node.
  • the invention also relates to a name resolution server configured to send a response to a first name resolution request coming from a client device, this response comprising at least one piece of information relating to a so-called resulting recipient server. of a resolution of the first request.
  • the name resolution server is remarkable in that it is further configured to send to the client device a plurality of elements comprising: at least one address of at least one relay node selected by the name resolution server to which the client device must send all or part of its messages containing data intended for the recipient server; and at least one scrambling instruction to be applied by the client device to said messages before sending them to said at least one relay node.
  • the invention also relates to a communication method implemented by a client device, comprising reception, from a name resolution server, of a response to a first name resolution request sent by the client device, this response comprising at least one piece of information relating to a so-called recipient server resulting from a resolution of the first request.
  • the communication method is remarkable in that it further comprises: reception of a plurality of elements, coming from the name resolution server, comprising: o at least one address of at least one relay node selected by the name resolution server to which the client device must send all or part of its messages containing data intended for the recipient server; and o at least one scrambling instruction to be applied by the client device to said messages before sending them to said at least one relay node; and applying said scrambling instruction to said messages.
  • the invention also relates to a client device configured to receive, from a name resolution server, a response to a first name resolution request sent by the client device, this response comprising at least one information relating to a so-called recipient server resulting from a resolution of the first request.
  • the client device is remarkable in that it is further configured to: receive a plurality of elements, coming from the name resolution server, comprising: o at least one address of at least one relay node selected by the name resolution server to which the client device must send all or part of its messages containing data intended for the recipient server; and o at least one scrambling instruction to be applied by the client device to said messages before sending them to said at least one relay node; and applying said scrambling instruction to said messages.
  • the invention also relates to a message processing method implemented by a relay node selected by a name resolution server for a client device and a recipient server, this method comprising: an acquisition at least one piece of information relating to at least one scrambling instruction applied by the client device to messages containing data intended for the recipient server before sending them to the relay node; upon receipt of at least one scrambled message containing data intended for the recipient server and addressed to the relay node by the client device, deletion, using said at least one piece of acquired information, of the scrambling applied by the client device; and a transfer of said at least one message obtained after removing the interference to the destination server.
  • the invention also relates to a relay node in a communications network selected by a name resolution server for a client device and a destination server, this relay node being configured to: acquire at least one piece of information relating to the minus one scrambling instruction applied by the client device to messages containing data intended for the recipient server before sending them to the relay node; upon receipt of at least one scrambled message containing data intended for the recipient server and addressed to the relay node by the client device, using said at least one acquired piece of information, remove the scrambling applied by the client device; and transfer said at least one message obtained after removing the interference to the destination server.
  • the invention therefore proposes a solution which makes it possible to prevent access to sensitive information by equipment which is close to the client device (from the point of view of the network topology).
  • the solution particularly applies to the level of the access network used by a client device (e.g. public or private WLAN (“Wireless Local Area Network” in English), mobile network, etc.) by relying on a plurality of network entities (name resolution server(s), relay node(s), to prevent malicious actions likely to be implemented during DNS communications, or more generally during communications related to resolving resources such as URIs, domain names, etc. These resources are more generally referred to as “names” in the remainder of this document.
  • the invention has a preferred but non-limiting application when the communications in question are encrypted; no limitation is attached to the encryption scheme then envisaged to transport the messages exchanged during these communications (for example, for DNS, DoT, DoD, DoQ, DoH, DoC communications).
  • the client device which may for example be a terminal, a CPE (for “Customer Premises Equipment” in English), an STB type decoder (for “Set Top Box” in English), etc.), nor to that of the relay node selected by the name resolution server (which may in particular be a server, a router, etc.).
  • the solution proposed by the invention is based more particularly on the selection, by a trusted name resolution server requested by the client device when it wishes to access a given service, typically provided by a so-called recipient server, from at least one relay node via which the client device will interact with the recipient server.
  • Multiple relay nodes can be advantageously used when communicating with a destination server, for example each relay node is used for a limited period of time.
  • a name resolution request may result in one or more communications with one or more recipient servers. Communications with these different recipient servers can be managed with one or more relay nodes.
  • the client device addresses messages containing the data that it intends to the recipient server (in other words containing the data that it wishes to send to it as part of access to the service). to a relay node, which is then responsible for relaying them to the destination server.
  • a relay node between the client device and the destination server has the effect of hiding the true recipient (i.e. the destination server) of the data sent by the client device when it accesses the service, since the address to which the messages are sent is that of the relay node and not that of the recipient server, in accordance with the invention.
  • the address of the recipient server is hidden in the content of the messages addressed to the relay node, for example in encrypted form by means of an encryption mechanism shared with the relay node. This makes it possible to make the identity of the recipient server inaccessible in the event of interception of messages between the client device and the relay node, while allowing the relay node to relay these messages to the recipient server.
  • the messages addressed to said at least one relay node include, in encrypted form, data intended for the recipient server and an address of the recipient server.
  • the introduction of a relay node between the client device and the recipient server makes it possible to mask the true source of the messages (that is to say the identity of the client device), in the event of interception and inspection of these messages by a malicious entity located beyond the relay node (in the direction of the client device towards the recipient server).
  • This difficulty in obtaining by statistical analysis of sensitive data traffic is increased when the use of one (or more) relay node(s) is combined with one or more (additional) scrambling actions implemented by the client device (possibly supplemented by scrambling actions implemented by the relay node(s). These scrambling actions are transmitted in the form of scrambling instructions to the client device by the resolution server and can be of different natures.
  • said at least one scrambling instruction transmitted by the name resolution server to the client device comprises a stuffing (or filling or even of “padding” in English) messages containing data intended for the recipient server before sending them to said at least one relay node, this instruction comprising at least one padding pattern to be used by the client device to scramble said messages or a padding technique. generation of at least one such padding pattern.
  • said at least one scrambling instruction comprises an instruction for stuffing said messages and the application of said at least one scrambling instruction to said messages comprises a stuffing of at least one at least one said message containing data intended for the recipient server and addressed to the relay node using a padding pattern provided in said padding instruction or generated by means of a generation technique provided in said padding instruction.
  • a message stuffing instruction may consist, in the context of a voice type communication service based on the exchange of small data packets between the client device and the destination server , to increase the length of the data packets sent to the relay node by the client device and intended for the destination server using a determined padding pattern, provided by the name resolution server, or generated by the client device according to a generation technique of padding patterns provided by the name resolution server.
  • the stuffing of messages by the client device makes it possible to trivialize the profile of the messages sent by the client device and thus to homogenize the traffic output from the client device.
  • the data, the padding pattern completing this data, and the address of the recipient server can be encrypted before being sent to the relay node. This further makes it possible to guarantee the authenticity and integrity of the messages exchanged between the client device and the relay node, and the information contained in these messages.
  • said at least one scrambling instruction comprises an instruction for establishment by the client device of at least one fictitious connection with and/or via said at least one relay node.
  • Such a fictitious connection is established in parallel with the connection used by the client device to transmit to the relay node the messages intended for the recipient server (hereinafter referred to as “main connection”). It can end at the relay node or be relayed by the latter to a dedicated server (i.e. capable of establishing and managing a fictitious connection properly and with full knowledge of the facts).
  • the client device can be configured to transmit fictitious data over this fictitious connection, that is to say which are not intended to be “consumed” (i.e. exploited, used) by the relay node and /or by the dedicated server which receives them. Likewise, any fictitious application data possibly transmitted by the dedicated server is not consumed by the relay and/or by the client device.
  • the method of processing a first name resolution request or the communication method may further comprise a step of notifying said at least one relay node of at least one piece of information relating to said at least one scrambling instruction.
  • This notification of the relay node by the name resolution server or by the client device allows the relay node to easily identify and remove the scrambling applied to the scrambled messages coming from the client device before their transmission to the destination server.
  • the information notified to the relay node may include the scrambling instruction itself, as ordered by the name resolution server to the client device, or only certain elements representative of this scrambling instruction, sufficient to enable the relay node to be able to suppress interference introduced by the client device.
  • the information in question when notified to the relay node by the client device, may be an indicator delimiting or identifying the stuffing reason contained in a message (for example, such an indicator may include an offset of bits or symbols also called “bit/symbol offset” in English).
  • the scrambling actions ordered by the name resolution server are advantageously taken into account by the relay node when it receives scrambled messages from the client device containing data intended for the recipient server, in order to identify and then remove the interference introduced by the client device before relaying the messages to the recipient server.
  • the relay node can also, upon receipt of at least one message from the recipient server and containing data intended for the client device, apply scrambling to said at least one message before transferring it to the client device, transparently. for the destination server.
  • the interference introduced by the relay node may be equivalent to that applied by the client device (in other words of the same nature, for example based on the same jamming patterns). This mode is called “symmetric jamming mode”.
  • the interference introduced by the relay node may be different from that applied by the client device; for example, message padding may only be applied in one direction, or different padding patterns may be applied in both directions, or emulation of dummy connections may be performed in one direction (e.g. from the client device to the relay node) while message padding is applied in the other direction (e.g. from the relay node to the client device), etc.
  • This mode is called “asymmetric jamming mode”. This difference in the jamming actions applied makes it possible to take into account the asymmetric nature of the traffic volume depending on its direction. In fact, a larger quantity of useful data is generally transmitted in the direction relay node towards client device.
  • the invention therefore makes it possible to guarantee respect for the confidentiality of communications established by client devices, and contributes to better preserving the privacy of users of these client devices and to limiting the risks of user profiling.
  • Network operators can incidentally, through the invention, offer value-added name resolution services (e.g. DNS services) and thus benefit from the trust of their users. Note that the users in question are not necessarily those to whom the operators provide network connectivity.
  • the introduction of a relay node between the client device and the recipient server aims to hide the true recipient of the messages sent by the client device, as well as the true source of these messages (when undue inspection of messages takes place beyond the relay node), making it difficult to implement statistical analysis of traffic from the client device.
  • This difficulty can be increased via a judicious choice of relay node(s) to used by a client device.
  • At least one said relay node can be selected by the name resolution server so that the relay node satisfies at least one condition among: preventing a correlation between this relay node and the destination server (for example, the same node relay can be used for several distinct recipient servers, or different relay nodes can be selected for the same client device and the same recipient server but for different communications between the client device and the recipient server); and/or maximize the number of client devices using said relay node.
  • Other conditions to be verified may be taken into account when selecting a relay node for a client device and a recipient server, such as optimizing the client devices using the selected relay node based on at least one criterion. given, such as load considerations or geographical considerations (which may relate in particular to the know-how of the operator and/or the engineering/configuration of the relay nodes).
  • a relay node may be selected because it satisfies a condition of (already) having a route to the destination server.
  • the criteria mentioned above are not exclusive; that is, the name resolution server can take into account several criteria simultaneously to select a relay node for the client device and the destination server.
  • the plurality of elements transmitted by the resolution server to the client device further comprises a first indication that at least one said relay node can be used by the client device to send at least a second name resolution request correlated to the first request.
  • the relay node in question used by the client device to transmit messages to the recipient server, but it is also responsible for resolving all or part of future name resolution requests from the client device correlated with the first query, for example relating to a name of a subdomain of a domain name on which the first query related.
  • This allows an additional degree of obfuscation to be introduced, making it difficult for a malicious entity to establish a link between a particular name resolution server and a client device.
  • each name resolution server involved in the communication of the client device with the destination server has only partial knowledge of the requests issued by the client device.
  • the plurality of elements transmitted by the resolution server to the client device may further comprise a second indication identifying the resolution requests name concerned by the first indication.
  • the plurality of elements transmitted by the resolution server to the client device further comprises at least one identifier of said at least one relay node selected by the name resolution server.
  • the identifier transmitted in the plurality of elements allows the client device to distinguish a particular relay node among the plurality of relay nodes sharing the same IP address.
  • the transmission of the identifier of the relay node selected by the name resolution server makes it possible to avoid maintaining at the level of the name resolution server states associating with each client device contacting it one or several relay nodes (in this case we speak of a stateless name resolution server).
  • the first request comprises at least one identifier of at least one relay node previously selected for the client device to which the client device sends all or part of its messages containing data intended for the destination server.
  • the relay node in question may have been selected for the client device and for the same recipient server (typically for the same communication with this recipient server), by the name resolution server to which the client device addresses the first query or by another name resolution server. Inserting the identifier of the relay node currently in use by the client device allows the name resolution server to which the first request is addressed, depending on the strategy adopted, to either reselect the same relay node (i.e. that is to say at least one said relay node selected by the name resolution server coincides with a relay node identified in the first request), for example to exploit an existing connection, or on the contrary, to knowingly select a different relay node, way to make it even more difficult to trace communications from the client device. It is in fact more difficult in the latter case to correlate the recipient server with the identity of the relay included in the first request.
  • this embodiment makes it possible to limit the information stored by the name resolution server (no state maintenance necessary, as explained previously), which reinforces the security of the mechanism implemented by the invention and limits the risks of tracking the client device based on its DNS communications.
  • the plurality of elements is sent to the client device or received by the client device in a response to the first resolution request.
  • This embodiment makes it possible to apply the invention without delay from the first resolution request. In addition, it advantageously makes it possible to limit the signaling required between the name resolution server and the client device to implement the invention.
  • first and second are solely intended to distinguish two successive name resolution requests, correlated with each other, for example a request relating to a domain name and a subsequent query relating to a subdomain of this domain name.
  • This use does not presuppose the absence of DNS exchanges or more generally of previous name resolution between the client device and the name resolution server, for example the sending by the client device and the resolution by the resolution server of names from a query for another domain name.
  • the sending of said plurality of elements by the name resolution server to the client device is conditioned by detection by the name resolution server of an option determined in the first request.
  • This embodiment offers the possibility to the user of the client device to choose whether or not he wishes to benefit from the protection mechanism proposed by the invention. For example, if the network used by the user's client device to access the service provided by the recipient server is a trusted network, the user can decide to deactivate the implementation of the invention. Conversely, if the network is not a trusted network, the user can decide to use the invention. It should be noted that this deactivation can also be carried out by the client device itself, automatically, that is to say without user intervention, in a transparent manner for the user.
  • the methods of processing a (first) request and messages, and/or communication are implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a name resolution server conforming to the invention and comprising instructions adapted to the implementation of a method for processing a first name resolution request as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a client device conforming to the invention and comprising suitable instructions to the implementation of a communication method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a relay node conforming to the invention and comprising suitable instructions to the implementation of a message processing method as described above.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions for a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
  • the program according to the invention can in particular be downloaded onto an Internet type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the processing and communication methods according to the invention.
  • the invention also relates to a system in a communications network comprising: a client device according to the invention; a name resolution server according to the invention; and at least one relay node according to the invention selected by the name resolution server for said client device.
  • the system according to the invention benefits from the same advantages mentioned above as the client device, the name resolution server and the relay node according to the invention.
  • processing and communications methods the name resolution server, the client device, the relay node and the system according to the invention in combination present all or part of the aforementioned characteristics.
  • Figure 1 represents, in its environment, a system in a network according to the invention, in a particular embodiment
  • Figure 2 schematically represents the hardware architecture of a computer that can host any of the entities according to the invention belonging to the system of Figure 1;
  • Figure 3 represents the functional modules of a name resolution server of the system of Figure 1, according to the invention.
  • Figure 4 represents the functional modules of a client device of the system of Figure 1, according to the invention.
  • FIG. 5 represents the functional modules of a relay node of the system of Figure 1, according to the invention.
  • Figure 6 represents in flowchart form the main steps of a method for processing a name resolution request as they are implemented by the name resolution server of Figure 3;
  • Figure 7 represents in flowchart form the main steps of a communication process as they are carried out by the client device of Figure 4;
  • Figure 8 represents in flowchart form the main steps of a message processing method as they are implemented by the relay node of Figure 5;
  • Figure 9 includes Figures 9A and 9B respectively representing an EAO option (for “EDNS (Extension Mechanisms for DNS) ASTRA (A DNS-driven Guard against STatistical Traffic Analysis) Option”) which can be used in a query for resolution of names and in the response to this request to implement the invention, in a particular embodiment;
  • EAO option for “EDNS (Extension Mechanisms for DNS) ASTRA (A DNS-driven Guard against STatistical Traffic Analysis) Option”
  • EDNS Extension Mechanisms for DNS
  • ASTRA A DNS-driven Guard against STatistical Traffic Analysis
  • Figure 10 partially and schematically illustrates a scrambled message addressed to the relay node of Figure 5 and containing data intended for the recipient server of Figure 1;
  • FIG. 11 Figure 11 schematically illustrates the changes in port numbers and source and destination addresses made by the relay node of Figure 5, in a particular alternative embodiment
  • Figure 12 includes Figures 12A and 12B representing the exchanges between the entities of system 1 of the figure depending on whether or not the client device of the system supports the “partial-offload” function.
  • Figure 1 represents a system 1 in an NW communications network, according to the invention, in a particular embodiment.
  • NW communications network may include one or more subnetworks, such as for example one or more access (sub)networks (for example a public or private network type WLAN, a mobile network, etc.), the Internet network, etc.
  • subnetworks for example a public or private network type WLAN, a mobile network, etc.
  • the Internet network etc.
  • the system 1 comprises: a client device 2, in accordance with the invention.
  • the client device 2 is a terminal of a user U such as a mobile telephone (for example of the "smartphone" type), connected to a public WLAN network AN 1 and to a network of AN2 mobile access via which he can access the Internet network.
  • the invention obviously applies to other fixed or mobile client devices (for example to a decoder such as an STB, a CPE, etc.), as well as to other networks (wired, wireless, etc.), the client device 2 can be connected simultaneously to one or more access networks, directly or via intermediate equipment such as a CPE; at least one trusted name resolution server for the client device 2 (typically, considered as such by the user U of the client device 2), in accordance with the invention, and generally referenced by 3.
  • a CPE intermediate equipment
  • the invention can, however, be applied in the context of the resolution of other IP resources referred to in this document generally by "names”, such as for example URIs, etc. ; and at least one relay node 4-1, 4-2, etc. in accordance with the invention, designated more generally under the reference 4 and interfacing with the name resolution servers 3, for example using the RESTCONF protocol described in the document IETF RFC 8040, January 2017. Of course, other protocols can be considered as a variant for this interface.
  • AD ASTRA procedure or mechanism for “Advanced DNS-driven protection Against Statistical TRaffic Analysis” in English
  • client device 2 uses to access the Internet network and more particularly any service S (e.g. voice communication service, web service, etc.) hosted or provided by a remote server 5 associated with (i.e. identified by) a given domain name (for example, for example, “service-s.com”), an access network which is not a trusted network for the client device 2.
  • service S e.g. voice communication service, web service, etc.
  • a remote server 5 associated with (i.e. identified by) a given domain name (for example, for example, “service-s.com”), an access network which is not a trusted network for the client device 2.
  • a given domain name for example, for example, “service-s.com”
  • Untrusted is for example a public network such as the AN1 public WLAN network, or a “visitor” network such as a hotel, bar, city network, etc. It indeed presents a risk for the client device 2 according to which its communications, in particular with a local DNS server 6 of the network in question, can be intercepted by a malicious third party entity and if necessary exploited by this entity, for example by carrying out a statistical analysis, to obtain information likely to compromise the privacy of user U.
  • the AD ASTRA mechanism is, however, deactivated here (although this is not obligatory), when the access network used by the client device 2 is a trusted network for the client device 2 (also designated by “Trusted Network” in English), such as the AN2 mobile network.
  • a trust network is typically a network which has been configured as such by the user U of the client device 2, or according to a default configuration, or which has been identified as such for example by using a verification mechanism. network identity, etc.
  • a trust network can also be dynamically determined by validating the network's assertions, in a manner known per se.
  • the client device 2 is then configured to use, when it wishes to access the service S via such a trusted network, a local trusted DNS server 7 (to the trusted network), announced by the trusted network, for example by means an announcement mechanism as described in document draft-ietf-add-dnr-13 published by the IETF and entitled “DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)”, August 2022
  • the DNS server 7 can be either a DNS server conforming to the invention or a DNS server known from the state of the art not implementing the invention.
  • the activation/deactivation of the AD ASTRA mechanism as a function of the level of trust granted to the access network used by the client device 2 can be configured by default at the level of the client device 2 (which allows activation or deactivation automatic of the mechanism according to the conditions of attachment to the network of the client device 2) or be decided dynamically, for example by interrogating the user U of the client device 2, via a user interface provided for this purpose.
  • the trusted DNS servers 3 belong to an L-DNS list of trusted DNS servers, configured for example by default on the client device 2 or defined by the user U of the client device 2 (for example via a user interface intended for this purpose). This configuration may have been carried out in particular by the network operator providing IP connectivity to the client device 2 (for example, its Internet service provider) or by the user U of the client device 2.
  • the L-DNS list only includes trusted DNS servers supporting the AD ASTRA mechanism.
  • the L-DNS list may also include trusted DNS servers that do not support this mechanism.
  • the DNS servers 3 included in the L-DNS list are located in the Internet network; although no limitation is attached to their location strictly speaking, preferably, the DNS 3 servers are not located in or announced by an “Untrusted” network (that is to say by a network which does not is not a trusted network for the client device 2).
  • the client device 2 embeds a DNS client referenced by CL (for example in an application such as its operating system or OS for "Operating System” in English, the DNS client CL which can be shared by several applications), which chooses according to a predefined local strategy (for example via a default configuration) the trusted DNS server(s) to be requested from the L-DNS list for each domain name resolution required when invocation of a service such as for example the service S provided by the remote server 5.
  • CL for example in an application such as its operating system or OS for "Operating System” in English, the DNS client CL which can be shared by several applications
  • This local strategy can in particular specify: a persistent choice mode according to which the same DNS server is chosen according to a local preference or on the basis of information characteristic of the capacities of the DNS servers in the L-DNS list, and requested for a specific period; a sequential choice mode, according to which the DNS client CL establishes a list of candidate L-CAND servers from the L-DNS list, which it orders according to one or more criteria.
  • the L-CAND list is established and ordered according to an encryption scheme supported where applicable by each DNS server; such an encryption scheme is for example a DoT, DoD, DoH, DoQ, or even DoC encryption scheme as mentioned above.
  • the L-CAND list can thus include all the DNS servers in the L-DNS list supporting the DoH encryption scheme, followed by all the DNS servers in the L-DNS list supporting the DoT encryption scheme.
  • the DNS servers are then requested by the DNS client CL in the order of the L-CAND list thus established.
  • criteria other than encryption schemes can be considered as a variant, such as for example the location of DNS servers, their processing capacity(s), etc. ; a random choice mode: a DNS server is chosen randomly by the DNS CL client for any new DNS resolution request. This random choice mode can also result in a random choice of the implemented encryption scheme; etc.
  • the client device 2 can embed one or more DNS CL clients capable of implementing such a strategy when they are activated.
  • the communications between the client device 2 (and more specifically its DNS CL client) and a trusted DNS server 3, selected by the DNS CL client of the client device 2 are encrypted. They comply, for example, with any of the DoT, DoD, DoH, DoQ, or DoC protocols.
  • the use of an encrypted DNS transport to transmit messages between the client device 2 and a DNS server 3 guarantees the authenticity and integrity of these messages.
  • the client device 2 exchanges directly with the trusted DNS server 3, selected by the DNS client CL, without the intervention of a relay (or “forwarder” in English ) DNS.
  • the invention also applies in the presence of a DNS forwarder located between the client device 2 and the trusted DNS server 3, selected by the DNS client CL. More specifically, if the DNS forwarder is trusted, the client device 2 sends its DNS requests to it; in this case, the DNS forwarder is configured to relay DNS requests from the client device 2 to the DNS server 3 selected by the DNS client CL. If the DNS forwarder is not trusted, client device 2 is configured to send its DNS requests directly to the DNS server 3 selected by the DNS CL client (and thus bypass the DNS forwarder).
  • the terminology “DNS request addressed by a client device” designates indifferently a DNS request coming directly from the client device or via a DNS forwarder as has just been mentioned.
  • the DNS server 3 in question is configured to, in addition to resolving the domain name in question (directly or indirectly by requesting another DNS server), select one or more relay nodes among the relay nodes 4 of system 1 to which(s) direct the client device 2 to send its messages containing data intended for the remote server 5 (recipient server within the meaning of the invention), transmitted within the framework of the service S.
  • Communications between the client device 2 and the relay node(s) 4 of the selected system 1, as well as between these relay nodes 4 and the DNS servers 3 having selected them, are encrypted in the embodiment described here, for example by means of the TLS protocol (for “Transport Layer Security” in English), version 1.3, possibly combined with the use of an ECH function (for “Encrypted Client Hello”).
  • TLS protocol for “Transport Layer Security” in English
  • ECH function for “Encrypted Client Hello”.
  • the client device 2, the DNS servers 3 and the relay nodes 4 have the hardware architecture of a computer 8 as represented schematically in Figure 2.
  • This hardware architecture is based on a PROC processor, a RAM memory MEM, a read only memory ROM, a non-volatile memory NVM, and COM means of communication allowing each of the aforementioned devices to communicate in particular with the other devices of system 1.
  • These COM means of communication can in particular relying on a wired or wireless communication interface, known per se and not described in detail here, and/or on one or more software interfaces such as an application programming interface (or API for “Application Programming Interface” in English) or a point-to-point communication interface, etc., and implement one or more encryption schemes as mentioned previously.
  • a wired or wireless communication interface known per se and not described in detail here
  • software interfaces such as an application programming interface (or API for “Application Programming Interface” in English) or a point-to-point communication interface, etc., and implement one or more encryption schemes as mentioned previously.
  • the non-volatile memory NVM (or alternatively the read-only memory ROM) of the computer 8 constitutes a recording medium in accordance with the invention, readable by the processor PROC, and on which a computer program is recorded. in accordance with the invention.
  • this computer program is referenced by PROG3 and includes instructions defining the main steps of a process for processing a (first) resolution request of name according to the invention.
  • this computer program is referenced by PROG2 and includes instructions defining the main steps of a communication method according to the invention.
  • PROG4 this computer program is referenced by PROG4 and includes instructions defining the main stages of a message processing method according to the invention.
  • the PROG3 computer program defines the functional modules of a DNS server 3 according to the invention, which rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 8.
  • these functional modules comprise in particular as illustrated in Figure 3: a reception module 3A, configured to receive REQ-DNS name resolution requests (DNS requests in the example considered here) sent by client devices, and in particular by the client device 2; a processing module 3B, configured to process (in other words resolve) the REQ-DNS requests received by the reception module 3A and develop REP-DNS responses to these requests; a 3C supply module, configured to provide each client device having requested the DNS server 3, supporting (and incidentally requesting) the implementation of the AD ASTRA mechanism, a plurality of AD ASTRA-ELTS elements in addition to the information conventionally provided in response to a REQ-DNS query, as detailed further later.
  • a reception module 3A configured to receive REQ-DNS name resolution requests (DNS requests in the example considered here) sent by client devices, and
  • the plurality of AD ASTRA-ELTS elements is provided to a client device having sent a REQ-DNS request to the DNS server 3 in the REP-DNS response to this request, for example in an EDNS option (for “Extension Mechanisms for DNS” in English) as explained in more detail later.
  • EDNS option for “Extension Mechanisms for DNS” in English
  • the plurality of ASTRA-ELTS AD elements is provided to the client device using one or more messages distinct from the REP-DNS response; and a 3D sending module, configured to send to the client devices having requested the DNS server 3, the REP-DNS responses developed by the processing module 3B as well as the plurality of AD ASTRA-ELTS elements provided by the 3C module of supply.
  • the processing module 3B proceeds, to resolve a REQ-DNS request received from a client device, in a conventional manner by establishing, from RR records available to the DNS server 3 or to which it can access (via a or several other DNS servers organized hierarchically), a correspondence between the name on which the REQ-DNS request relates (for example, the domain name “service-s.com” allowing access to the service S) and a resource IP (for example an IP address) of a server associated with this name (server 5 in the example of the domain name “service-s.com”).
  • a correspondence between the name on which the REQ-DNS request relates for example, the domain name “service-s.com” allowing access to the service S
  • a resource IP for example an IP address
  • the REP-DNS response to the REQ-DNS request developed by the processing module 3B thus includes at least one piece of information contained in an RR record relating to a server (designated here by “recipient server”) associated with the name on which carries the REQ-DNS request, and resulting from the resolution of the REQ-DNS request by the processing module 3B.
  • this information includes at least one IP address (IPv4 and/or IPv6) of the recipient server.
  • this REP-DNS response further comprises, in the embodiment described here, the plurality of AD ASTRA-ELTS elements provided by the module 3C for providing the DNS server 3.
  • This plurality of elements AD ASTRA-ELTS comprises, in accordance with the invention, at least the following elements: at least one IP address of at least one relay node 4 selected by the DNS server 3 (for example by its supply module 3C) for the device client 2 and for the destination server associated with the name on which the REQ-DNS request relates (remote server 5 in the example envisaged), to which the client device must send all or part of its messages containing data intended for the destination server.
  • This IP address can optionally be supplemented by a port number to be used by the client device to send its messages to relay node 4, if a default port number is not defined.
  • the client device instead of sending messages relating to the service to which it wishes to access the destination server identified in the REP-DNS response, the client device must send these messages to the relay node 4 (i.e. indicate as the destination address of these messages the address of relay node 4 instead of the address of the destination server).
  • the recipient server for which the useful data contained in these messages are truly intended remains identified in the content of the messages addressed to the relay node 4-1 so that it can relay this useful data to the recipient server.
  • each message addressed to relay node 4-1 has the destination address of relay node 4-1 (including its IP address noted @IP4-1 and a P4-1 port number, which can be defined by default or having been provided by the DNS server 3 with the IP address of the relay node 4-1 as mentioned previously), and contains a data packet, called inner data packet (or “inner-packet” in English), encrypted by means of an encryption scheme (for example, TLS, DTLS).
  • an encryption scheme for example, TLS, DTLS
  • the internal data packet contains useful data intended for the remote server 5, and as destination address, the IP address of the remote server 5 and its port number (also more commonly referred to as “transport address”).
  • the address of the remote server 5 is therefore masked by means of encryption in the content of the message addressed to the relay node 4-1; and at least one scrambling INST instruction, intended to be applied (in other words to be applied) by the client device 2 to said messages containing data intended for the recipient server before sending them to said at least one relay node 4.
  • Such a scrambling instruction scrambling may include for example a padding instruction for all or part of the messages, and/or an instruction for emulating connections between the client device and the relay node or via the relay node to a dedicated server in addition to the connection used to send the messages containing the data intended for the recipient server (in other words an instruction to establish “fictitious” connections by the client device), as explained further later.
  • modules 3A to 3D of a DNS server 3 are described in more detail with reference to the steps of the method for processing a (first) name resolution request illustrated by Figure 6.
  • the PROG2 program stored in the NVM memory (or alternatively ROM) of the computer 8 defines the functional modules of the client device 2, which rely on or control the PROC elements , MEM, ROM, NVM, and COM of the computer 8.
  • These functional modules include in particular, in the embodiment described here, as illustrated in Figure 4: a sending module 2A, embedded in the DNS CL client, and configured to send to one of the DNS servers 3 of the L-DNS list chosen by the DNS client CL of the client device 2, a REQ-DNS name resolution request.
  • this REQ-DNS request concerns a domain name and an RR record of type A or AAAA attached to this domain name.
  • the sending module 2A is activated by the DNS client CL each time the client device 2 wishes to access a service, for example the service S hosted by the remote server 5 and associated with the domain name “service-s.com ".
  • the REQ-DNS request further includes an EDNS EAO option, indicating to the requested DNS server 3 that the client device 2 supports (and incidentally requests) the AD ASTRA mechanism.
  • support for the AD ASTRA mechanism by the client device 2 can be signaled to the DNS server 3 by other means (for example in a message other than in the REQ-DNS request, in another option, etc.); a reception module 2B, embedded in the DNS client CL, and configured to receive from the requested DNS server 3, the REP-DNS response to the REQ-DNS request developed by this last.
  • This REP-DNS response includes, as indicated previously, at least one piece of information relating to the RR record requested by the client device 2 of the destination server associated with the name to which the REQ-DNS request relates, for example an IP address of the destination server .
  • the REP-DNS response contains the plurality of AD ASTRA-ELTS elements provided by the DNS server 3 in accordance with the AD ASTRA mechanism; a 2C execution module, configured to apply said at least one scrambling instruction contained in the plurality of AD ASTRA-ELTS elements to messages containing data intended for the destination server associated with the name on which the REQ-DNS request relates before send them to one of the relay nodes 4 identified in the plurality of ASTRA-ELTS AD elements; and a 2D sending module configured to send to the relay node 4 in question the scrambled messages obtained by the 2C execution module.
  • the PROG4 program stored in the NVM memory (or alternatively ROM) of the computer 8 defines the functional modules of a relay node 4 according to the invention, these functional modules relying on or controlling the PROC, MEM, ROM, NVM, and COM elements of the computer 8. They include in particular, in the embodiment described here, as illustrated in Figure 5: an acquisition module 4A, configured to acquire relative information to at least one scrambling INST instruction applied by a client device according to the invention such as the client device 2, for which the relay node 4 has been selected, said INST scrambling instruction being applied to messages containing data intended to a destination server before the client device addresses them to the relay node 4.
  • an acquisition module 4A configured to acquire relative information to at least one scrambling INST instruction applied by a client device according to the invention such as the client device 2, for which the relay node 4 has been selected, said INST scrambling instruction being applied to messages containing data intended to a destination server before the client device addresses them to the relay node 4.
  • the acquisition of information relating to the scrambling INST instruction can be done via the trusted DNS server 3 at the origin of this instruction or by the client device configured to apply it; and a processing module 4B, configured to: o upon receipt of such a message, remove, using the acquired information, the scrambling applied by the client device to the message in accordance with the scrambling instruction INST; and o transfer the message obtained after removing the interference to the destination server.
  • the relay node 4 can transfer the obtained message directly to the recipient server or through another relay node, in the case where several relay nodes are deployed in cascade.
  • the way in which the processing module 4B proceeds presents no difficulty for those skilled in the art and is not described in more detail here.
  • the module 4B is further configured to, upon receipt of a message from the recipient server and intended for the client device for which it was selected (for example the client device 2), scramble this message and transfer the obtained scrambled message to the client device. It should be noted that module 4B does not necessarily apply in the relay node to client device direction, the interference that was applied in the client device to relay node direction (i.e. interference applied in one direction and in the other are not necessarily the same). The scrambling applied in the relay node towards client device direction is for example chosen by the trusted DNS server 3.
  • the relay node 4 is informed of this for example by the trusted DNS server 3 and receives from the latter, via its acquisition module 4A, an INST' instruction fog lage describing the interference to be applied.
  • the instruction for jamming identification is explicitly encoded in the encrypted message and therefore communicated by the client device (resp. the relay node).
  • modules 4A and 4B of a relay node 4 are described in more detail with reference to the steps of the message processing method illustrated in Figure 8.
  • the client device 2 is configured (for example, by its Internet access provider or by its user) with a list L -DNS from trusted DNS 3 servers, conforming to the invention supporting the AD ASTRA mechanism.
  • a client device such as the client device 2 wishes to access, via an application installed on the client device for example, a service hosted within a computer environment
  • the The application in question sends to a DNS server a DNS request relating to the name (in the DNS sense) of the computer environment in order to obtain the address (for example an IP address) of a server with which to exchange to benefit from the service.
  • the client device 2 then sends, via its sending module 2A, a REQ-DNS request for resolution of the domain name “service-s.com” (first request within the meaning of the invention) to one of the trusted DNS servers 3, identified in the L-DNS list, namely here to the DNS server 3-1 (step E10).
  • the choice of DNS server 3-1 from the L-DNS list results from a local strategy applied by the client device 2 and which has been previously configured in the client device 2, as mentioned previously.
  • the exchanges between the client device 2 and the DNS server 3-1 are encrypted, for example using one of the encryption schemes DoT, DoD, DoH, DoQ , or even DoC previously cited.
  • the REQ-DNS request in a manner known per se, specifies in particular the domain name “service-s.com” to which the client device 2 wishes to access, as well as the type of RR record targeted by the request (for example example here an RR record of type A if the client device 2 supports the IPv4 protocol or an RR record of type AAAA if the client device 2 supports the IPv6 protocol).
  • the REQ-DNS request further includes an EDNS option called EAO (newly introduced for the purposes of the invention), indicating to the requested DNS server 3, that is to say the DNS server 3-1, that the client device 2 supports and requests the implementation of the AD ASTRA mechanism.
  • EAO newly introduced for the purposes of the invention
  • FIG. 9A illustrates an example format of the EAO option inserted by the client device 2 in its REQ-DNS request indicating to the DNS server 3-1 that the client device 2 supports and requests the implementation of the AD mechanism ASTRA.
  • the EAO option includes three fields OPTION-CODE, OPTION-LENGTH and OPTION-DATA, the OPTION field -LENGTH indicating the size in bytes of the OPTION-DATA field.
  • the OPTION-DATA field includes a “partial- offload” and an "AID” parameter (for "AD ASTRA relay IDentifier” in English), as well as a reserved location or “reserved” in English, allowing the client device 2 to communicate the capabilities it has in connection with the mechanism AD ASTRA as well as other information that may be useful to the requested DNS 3 server.
  • AID for "AD ASTRA relay IDentifier” in English
  • the parameter “partia l-off load” is used by the client device 2 in a request to indicate to the DNS server 3-1 whether it supports (parameter valued at 1 for example) or not (parameter valued at 0 for example) sending a first name resolution request to the DNS server 3-1 (REQ-DNS request) then sending subsequent name resolution requests (second requests within the meaning of the invention, denoted REQ'-DNS, REQ"-DNS, etc.), correlated to the first REQ-DNS name resolution request, to a name resolution server other than the DNS 3.1 server whose reachability information (for example its IP address) is communicated to it by the DNS server 3-1.
  • This other name resolution server can typically be a relay node selected by the DNS server 3-1 in accordance with the invention.
  • correlated queries we mean here that there is a link between the two questions asked in the two requests, for example the first request concerns the resolution of a "parent" domain name (for example "service-s.com”) while the second request concerns the resolution of a name of a subdomain of the parent domain (i.e. “*. services. corn” in the example considered above where * designates a character string).
  • correlation is the discovery by the client device 2 of names (or “references” or “referrals” in English) requiring resolution during the processing of data sent by the recipient server resulting from the resolution of the first request ; the second query(s) sent to resolve these names are correlated in the sense of the invention to the first query.
  • the correlation is established by the client device 2 as soon as it associates the destination server as the source of the names.
  • the “partial-offload” parameter can be set to 0 by default.
  • the "partial-offload” parameter is set to 1 by the client device 2, it is said that it supports the "partial-offload” function (function of "offloading" DNS requests on a other server than the DNS server 3-1 responsible for processing the first REQ-DNS request); and the “AID” parameter is used by the client device 2 to indicate whether it already uses, for active connections, a relay node in accordance with the invention, as part of an implementation of the AD ASTRA mechanism for the service S associated with the domain name “service-S.com” hosted by server 5 (in other words to send messages containing data intended for server 5), and where appropriate an identifier of this relay node.
  • the client device 2 can optionally associate this identifier with a preference intended for the DNS server 3-1, for example "match” if it wishes the DNS server 3-1 to select the same relay node when processing the REQ- request. DNS, or “not match” to request the use of another relay node.
  • this preference is not necessarily binding on the DNS server 3-1 and may not be taken into account by it.
  • this preference of the client device 2 is binding for the DNS server 3-1.
  • the DNS server 3-1 determines whether the latter contains the EAO option (test step F20).
  • the DNS server 3-1 processes (that is to say resolves) via from its processing module 3B the REQ-DNS request in a conventional manner and known to those skilled in the art, from the RR records available to it or by querying one or more other DNS servers as mentioned previously (step F30), then sends its REP-DNS-0 response to client device 2 (step F40).
  • This response REP-DNS-0 here includes the IP address noted @IP5 of server 5 associated with the domain name “service-s.com”.
  • the DNS server 3-1 processes (resolves) via its processing module 3B the REQ-DNS query in a conventional manner known to those skilled in the art, from the RR records available to it or by querying one or more other DNS servers (step F50). This treatment is identical to that carried out during step F30.
  • the processing module 3B of the DNS server 3-1 obtains, by resolving the REQ-DNS query, the RR record of the server 5 (recipient server within the meaning of the invention) associated with the domain name “service-s. com” and more particularly its IP address @IP5 which is contained in this RR record (information relating to the recipient server resulting from the resolution of the REQ-DNS request within the meaning of the invention). It includes the @IP5 address in the REP-DNS response to the REQ-DNS request.
  • the DNS server 3-1 supporting the AD ASTRA mechanism, selects via its supply module 3C at least one relay node 4 for the recipient server 5 (step F60). In the example considered here, it selects relay node 4-1.
  • the relay node 4-1 thus selected is intended to be used by the client device 2 to send it the messages that it wishes to send to the recipient server 5, as part of its access to the service S (instead of sending them directly to the recipient server 5).
  • the relay node 4-1 is then responsible for relaying these messages to the recipient server 5, directly or via another relay node 4 when relay nodes are deployed in cascade.
  • the REQ-DNS request is addressed by the client device 2 to a trusted DNS server not supporting the AD ASTRA mechanism and in particular the EAO option (for example when the L-DNS list includes both trusted DNS servers supporting the AD ASTRA mechanism and trusted DNS servers not supporting it), then the latter responds to the client device 2 by sending it an error message.
  • the client device 2 can request another DNS server, send the request back to the same server but without the EAO option, end the communication and generate a local notification (application, user, etc.) indicating the failure of the resolution attempt, etc.
  • the module 3C for providing the DNS server 3-1 can take into account one or more selection criteria.
  • the supply module 3C can select a relay node 4 verifying one or more conditions among the following conditions: prevent the establishment of a correlation between the selected relay node 4 and the destination server.
  • the supply module 3C must avoid a relay node 4 being selected only for a single recipient server, or for distinct communications between the client device 2 and the recipient server, it can select different relay nodes 4; maximize the number of client devices using a selected relay node 4; optimize the client devices using a relay node 4 selected according to at least one given criterion, such as for example load considerations, geographical considerations, etc. ; have (already) a route from the selected relay node 4 to the destination server.
  • This information can be obtained by the supply module 3C by querying the relay nodes 4 of the system 1 to obtain the routing tables maintained by the latter; etc.
  • the module 3C for providing the DNS server 3-1 can randomly select a relay node 4 from a list of relay nodes with which it has been previously configured.
  • the DNS server 3-1 can also select a plurality of relay nodes by applying the criteria mentioned previously, each relay node being intended to be used by the client device 2 for a determined duration (for example example, the duration of a connection).
  • the DNS server 3-1 can take this AID identifier into account when selecting the relay node (and where applicable the preference associated with this AID identifier indicated by the client device 2).
  • the DNS server 3-1 can select a relay node 4 so as to avoid associating the same relay node with a same recipient server for this client device 2, so as to minimize the risk of tracking DNS communications of the client device 2 by a malicious entity (such an entity would in fact experience great difficulty in establishing a correlation between the recipient server and the identifier of the relay node).
  • it may decide to select a relay node coinciding with that identified in the AID identifier of the REQ-DNS request.
  • the DNS server 3-1 may ignore the indications provided by the client device 2 in the “AID” parameter of the EAO option of the REQ-DNS request.
  • the supply module 3C inserts, in an EDNS EAO option of the REP-DNS response to the REQ-DNS request, an address of the selected relay node(s) born (step F70).
  • this address is an IP address (IPv4 address or IPv6 address). It is part of the plurality of AD ASTRA-ELTS elements provided by the supply module 3C to the client device 2.
  • the address inserted by the supply module 3C is a transport address of the relay node 4 and includes an IP address of the relay node 4 as well as a port number to use.
  • FIG. 9B illustrates an example of the format of the EAO option inserted by the DNS server 3-1 in its REP-DNS response (which echoes the EAO option inserted by the client device 2 in its REQ- request).
  • DNS the OPTION-DATA field of the EAO option includes several parameters, including in particular a “relay-locators” parameter, in which the IP address of the selected relay node 4-1 (or the IP addresses of the nodes selected relays) is(are) inserted.
  • the supply module 3C also inserts in the EAO option of the REP-DNS response, in the plurality of ASTRA-ELTS AD elements that it provides to the client device 2, at least one scrambling instruction INST to be applied by it to the messages that it will send to the relay node 4-1 and which are intended for the recipient server.
  • the scrambling instruction INST consists of an instruction for stuffing (or even filling or “padding”) messages sent by the client device 2 before their sending to the relay node 4- 1. It is inserted in a “padding” parameter of the OPTION-DATA field of the EAO option, as illustrated in Figure 9.
  • This padding instruction is an instruction to complete the messages intended for the recipient server that the client device 2 sends to the node relay 4-1 so as to homogenize their sizes.
  • the padding pattern(s) applied by the client device 2, denoted PATT are chosen for example so as to make the template of the messages sent by several client devices uniform. This advantageously makes it possible to reinforce further anonymity of communications from the client devices in question.
  • the padding instruction inserted in the “padding” parameter by the 3C supply module can take several forms. It may include a generation technique to be used by the client device 2 to generate one or more padding PATT patterns. Such a technique can rely for example on a reinforcement learning technique (or “Reinforcement Learning” in English) allowing the client device 2 to determine the stuffing patterns to be applied and to adjust them over time if necessary.
  • a reinforcement learning technique or “Reinforcement Learning” in English
  • such a generation technique can be applied directly by the 3C module providing the DNS server 3-1, and the padding instruction inserted in the “padding” parameter records the PATT padding pattern(s), generated by the 3C supply module using this generation technique.
  • the supply module 3C further notifies the relay node 4-1 selected for the client device 2 and the destination server 5, of the content of the stuffing instruction (and more particularly of the or PATT padding patterns or the technique for generating such patterns) which it asks the client device 2 to apply to the messages intended for the recipient server 5 which it will send to the relay node 4-1 (step F80).
  • This notification of the relay node 4-1 by the DNS server 3-1 allows it to acquire information relating to the scrambling instructions ordered by the DNS server 3-1 to the client device 2 and to thus be able to process messages coming from the client device 2 containing data intended for the destination server 5 before relaying them to the destination server 5.
  • the relay node 4-1 can acquire such information from the client device 2 itself.
  • the client device 2 can notify the relay node 4-1 by inserting into its messages containing data intended for the recipient server 5 and addressed to the relay node 4-1, indicators delimiting or identifying the applied padding patterns.
  • the scrambling instruction INST may include an instruction for the client device 2 to establish one or more fictitious connections with the relay node 4-1 and/or via the relay node 4-1 (with one or more dedicated servers), in addition to its “main” connection established with the relay node 4-1 to transmit data to the destination server 5 as part of access to the service S by the client device 2.
  • the client device 2 uses these fictitious connections to transmit “fictitious” data to the relay node 4-1 and/or to the dedicated server(s), in other words, data which are not strictly speaking intended to be exploited (“consumed”) by the relay node 4-1 and/or by the dedicated server(s), but which are only intended to scramble the data intended for the destination server 5.
  • This instruction establishment of fictitious connections can be inserted in an appropriate parameter of the OPTION-DATA field of the EAO option, and be notified to the relay node 4-1 as described previously for the stuffing instruction.
  • scrambling instructions can be transmitted by the DNS server 3-1 to the client device 2 in order to introduce noise around the connection of the client device 2 with the destination server (remote server 5 in the example considered here) and to make the information intercepted by a malicious entity placed on the path of this connection difficult to exploit. They are also notified to the relay node 4-1 so that it can take them into account when receiving scrambled messages from the client device 2.
  • the module 3C for providing the DNS server 3-1 provides two other elements in the plurality of AD ASTRA-ELTS elements inserted in the EAO option of the REP-DNS response, to namely: an “AID” parameter, in which the 3C module providing the DNS server 3-1 provides an identifier of the relay node 4-1 whose address appears in the “relay-locators” parameter, and that it has selected for the domain name “service-s.com” and the destination server 5. If several relay nodes are selected, the “AID” parameter includes the identifiers of each of the selected relay nodes.
  • a “partial-offload” parameter if the client device 2 has indicated in the “partial-offload” parameter of the EAO option of the REQ-DNS request, support for the partial-offload function, the DNS server 3-1 indicates in the “partial-offload” parameter of the EAO option of its REQ-DNS response whether the relay node it selected (relay node 4-1) can support subsequent DNS exchanges from client device 2 correlated to the REQ-DNS query (that is to say the “second” queries within the meaning of the invention), in other words if it supports the partial-offload function.
  • the 3C supply module can optionally add in the “partial-offload” parameter an additional indication identifying the DNS requests concerned by the partial-offload function (for example, requests relating to a particular subdomain or any other filter such as that the origin of the DNS resources (domain names (e.g. “service.example.com”, service (SRV, e.g. “service._tcp.example.com”), etc.) to be submitted to the system DNS).
  • domain names e.g. “service.example.com”, service (SRV, e.g. “service._tcp.example.com”
  • the support of the “partial-offload” function by the relay node 4- 1 indicates to client device 2 that it can send all its subsequent requests relating to a subdomain "*.service-s.com” to relay node 4-1. It should be noted that support for the partial- offload by relay node 4-1 does not necessarily imply that subsequent DNS requests sent by client device 2 are processed (i.e. resolved) directly by relay node 4-1. This can in fact be configured to send these requests to another trusted DNS server capable of resolving them.
  • the different elements indicated by the DNS server 3-1 in the “relay-locators”, “AID” and “partial-offload” parameters constitute, as mentioned previously, a plurality of AD ASTRA-ELTS elements provided by the 3C module providing the DNS server 3-1 to the client device 2.
  • this plurality of elements is provided in the REP-DNS response to the REQ-DNS request, in an EAO option.
  • all or part of this plurality of elements may be provided in one or more distinct options or messages of the REP-DNS response.
  • the REP-DNS response including the EAO option is then sent by the 3D sending module from the DNS server 3-1 to the client device 2 (step F90).
  • the client device 2 receives the REP-DNS response developed by the DNS server 3-1 to its REQ-DNS request (step E20) .
  • the client device 2 extracts from the EAO option the plurality of ASTRA-ELTS AD elements present in the REP-DNS response, and more particularly the elements included in the “relay-locators”, “padding”, “padding” parameters. AID” and “partial-offload” of the option (step E30).
  • the use of an encrypted DNS transport to transmit these parameters advantageously guarantees the authenticity and integrity of the messages conveying these parameters, and therefore incidentally, of the parameters received by the client device 2.
  • the identifier AID is recorded by the reception module 2B in a local cache of the DNS client CL of the client device 2, in association with the corresponding IP resource, namely here the domain name “service-s.com” . If an entry is already present in the cache for this same resource, the DNS CL client replaces its content with the new AID provided in the REP-DNS response. When sending subsequent DNS queries correlated to the REQ-DNS query, the CL DNS client populates the “AID” parameter of the EAO option of these subsequent DNS queries with the current contents of the local cache.
  • the reception module 2B also records in the local cache of the DNS client CL the information transmitted in the parameter “partial-offload”, i.e. all or part of the relay nodes indicated in the “relay-locators” parameter can be used for subsequent DNS queries correlated to the first REQ-DNS query as well as, where applicable, additional indications provided by the DNS server 3-1 and identifying the subsequent DNS requests concerned (step E50).
  • the “partial-offload” parameter is populated by the DNS server 3-1 in the EAO option of the REQ-DNS response only if the client device 2 supports the partial function -offload and notified the DNS server 3-1 by setting the “partial-offload” parameter of the REQ-DNS request to 1.
  • the INST scrambling instruction included in the “padding” parameter (message padding instruction here) is transmitted by the reception module 2B to the application APP of the client device 2 at the origin of the REQ- request. DNS resolution of the domain name “service-s.com”, so that it can execute (i.e. apply) this instruction before sending messages intended for the recipient server 5 to the relay node 4-1 indicated in the “relay-locators” parameter (step E60).
  • the APP application comprises a 2C execution module according to the invention. It should be noted that all of the modules 2A to 2D of the client device 2 can be hosted in the APP application.
  • the messages intended for the destination server 5 contain useful data DATA exchanged by the APP application with the destination server 5 during access to the service S.
  • these data are encrypted by means of a first encryption mechanism ENC1 according to the needs of the service S offered by the recipient server 5, and recorded in internal data packets denoted I-PKT (“inner packets” in English).
  • I-PKT inner packets
  • Each internal I-PKT data packet is intended for the destination server 5, that is to say it has as destination address (contained in a header of the I-PKT IP packet referenced by DEST in Figure 10), the IP address @IP5 of the destination server 5 and the port number P5 of the destination server 5.
  • This port number is for example here a port number defined by default (alternatively it may have been obtained during the resolution of the name domain associated with the recipient server 5, in a manner known per se).
  • the internal data packet I-PKT constitutes a data packet intended for the destination server within the meaning of the invention.
  • the APP application then applies, through its execution module 2C, the scrambling instruction INST recorded in the AD ASTRA-ELTS elements, to each internal data packet I-PKT containing data intended for the recipient server 5 (step E60).
  • the scrambling instruction INST is a padding instruction comprising at least one padding PATT pattern or a technique for generating such a PATT pattern.
  • the APP application adds padding bits or symbols in accordance with the PATT padding pattern(s) indicated in the INST padding instruction or generated by the execution module 2C. by applying the generation technique given in the INST padding instruction.
  • the APP application thus obtains a so-called scrambled B-PKT data packet, consisting of the internal I-PKT data packet supplemented by the stuffing bits or symbols of the applied stuffing PATT pattern(s).
  • the PATT padding pattern is inserted following the DATA data. This hypothesis is however not limiting in itself; the PATT padding pattern can be inserted in other places, or it can be fragmented and interspersed in the middle of the DATA data.
  • the scrambled data packet B-PKT is then encrypted (in accordance with the encryption scheme applied where applicable between the client device 2 and the relay node 4-1, referenced by ENC2 in the Figure 10), then inserted by the execution module 2C into a BM message whose destination address includes the IP address of the relay node 4-1 noted @IP4-1 (or of one of the relay nodes 4 specified in the “relay-locators” parameter) provided by the plurality of AD ASTRA-ELTS elements, as well as its port number P4-1.
  • This port number may be a port number defined by default, or alternatively have been recorded with the address @IP4-1 in the plurality of ASTRA-ELTS AD elements.
  • the BM message obtained which here contains the useful data DATA intended for the destination server 5, the IP address @IP5 of the destination server 5 and its port number P5 (commonly referred to as the transport address of the destination server 5), and the reason PATT stuffing, information which is all in encrypted form, is a scrambled message within the meaning of the invention containing data intended for the recipient server 5 but addressed to the relay node 4-1.
  • Each scrambled message BM obtained by the execution module 2C is then sent by the sending module 2D of the client device 2 to the relay node 4-1 (step E70).
  • Figure 10 only partially represents the scrambled message B-M, and is only provided for illustrative purposes for a better understanding of the invention.
  • Such a message of course includes other elements, such as a source IP address and port number (which may also be encrypted), etc.
  • the INST scrambling instruction may include an instruction for establishing fictitious connection(s) by the client device 2 with or via the relay node 4-1 to scramble the messages. containing data intended for the destination server 5 addressed to the relay node 4-1.
  • the execution module 2C proceeds as described previously: it inserts into a message M, in encrypted form (by means of the ENC2 encryption mechanism), an internal data packet I-PKT having as destination address the @IP5 address of the destination server 5, and comprising in encrypted form by means of the ENC1 encryption mechanism the DATA useful data intended for the destination server 5 (no addition of padding reason(s) unless the scrambling INST instruction contains also a padding instruction in addition to the instruction).
  • the destination address of the message M is the transport address of the relay node including its IP address @IP4-1 and its port number P4-1.
  • the message M thus formed is sent to the relay node 4-1 by the sending module 2D of the client device 2 on the main connection established by the client device 2 with the relay node 4-1 in a manner known per se.
  • the execution module 2C of the client device 2 further establishes, in addition to the main connection used to send the message M to the relay node 4-1, one or more other fictitious connections with the relay node 4 -1 and/or via this relay node 4-1 with one or more dedicated servers, in accordance with the INST instruction.
  • the fictitious connections thus emulated by the execution module 2C are advantageously added to the main connection established between the client device 2 and the relay node 4-1.
  • a malicious third party entity is therefore not able to distinguish the message comprising useful data M intended for the recipient server 5 from the fictitious messages F-M sent simultaneously on the fictitious connections.
  • the fictitious connections established by the client device 2 therefore come via the fictitious messages F-M sent to the relay node 4-1 or via the relay node 4-1 at the same time as the message M to “scramble” the message M (which we designate in the following by scrambled message B-M as in the previous variant).
  • the relay node 4-1 receives via its reception module 4A each scrambled message B-M sent by the client device 2 (step G 10).
  • the node 4-1 decrypts each scrambled message BM received, then deletes, via its processing module 4B, the interference introduced by the execution module 2C of the client device 2 (step G20).
  • the interference introduced by the client device 2 is a padding of the interior data packets transmitted by the APP application by means of at least one PATT padding pattern provided in the INST instruction or generated at from a generation technique recorded in this instruction.
  • This PATT pattern(s) of stuffing or the generation technique allowing them to be generated have also been transmitted by the DNS server 3-1 to the relay node 4-1 during the notification step F80/step G00. Obtaining this or these PATT stuffing patterns or the technique making it possible to generate them constitutes in itself a step of acquiring information relating to the scrambling instruction INST applied by the client device 2 within the meaning of the invention .
  • the relay node 4-1 can acquire information representative of the scrambling instruction INST applied by the client device 2.
  • the scrambling pattern can be indicated explicitly by the client device in the scrambled packet itself, as discussed previously.
  • the removal of the interference introduced by the execution module 2C of the client device 2 consists for the processing module 4B in removing the stuffing bits/symbols corresponding to the pattern(s).
  • (s) PATT padding it received from DNS server 3-1 or generated from the generation technique received from DNS server 3-1. It thus obtains the internal I-PKT data packets intended for the destination server 5.
  • the processing module 4B can locally terminate the fictitious connections established with it (or relay the F-M messages to the server(s) s) dedicated(s) if applicable) and extract the interior I-PKT data packet from the M message received on the main connection after decryption of the packet.
  • the processing module 4B replaces in each internal I-PKT data packet obtained the IP address and the source port number of the client device 2 (noted respectively in Figure @IP2 and P2) at the origin of the internal I-PKT data packet by its external IP address and source port number (or any other identifier used by the transport protocol such as for example the int-VTag or rem-VTag identifiers for the SCTP protocol), noted respectively @IP4-l_e and P4-l_e. It stores the P2 port number and the @IP2 source IP address of client device 2 in a local table, in its non-volatile NVM memory. Then it transfers the data packet obtained to the destination server 5, in a manner known per se (step G30).
  • the data packet obtained is transferred directly to the destination server 5 (without an intermediary between the relay node 4-1 and the destination server 5).
  • this hypothesis is not limiting in itself, and the invention also applies to the transfer of the data packet to the destination server 5 via one or more other relay nodes.
  • the relay node 4-1 adds scrambling before transferring the I-PKT data packet to the destination server 5. It can in particular for this purpose, as described previously for the client device 2, establish fictitious connections with dedicated servers, or with other (“real”) servers. This interference introduced between the relay node 4-1 and the destination server 5 presents a particular advantage in particular when the number of client devices using the same relay node 4 is less than a given threshold.
  • the destination server 5 responds to at least one of the I-PKT data packets received from the client device 2 via the relay node 4-1, by means of a so-called “return” data packet. and denoted R-PKT, the useful data contained in this return packet being encrypted as required of the service S using the ENC1 encryption mechanism.
  • the return R-PKT data packet is sent by the destination server 5 to the node relay 4-1.
  • the processing module 4C replaces its external P4-l_e port number and @IP4-1 e IP address in the destination address of the R-PKT return data packet by the port number P2 and the IP address @IP2 of the client device 2. Furthermore, it scrambles the R-PKT return data packet thus modified by applying here the same type of scrambling than that applied by the client device 2 in accordance with the scrambling instruction INST.
  • the processing module 4C thus applies the PATT scrambling pattern(s), notified by the DNS server 3-1 during steps F80/G00 (or generated from the generation technique provided by the server DNS 3-1) (step G50), then encrypts the scrambled return data packet obtained in its entirety (i.e. including its headers) in accordance with the ENC2 encryption scheme used between the relay node 4-1 and the client device 2.
  • the processing module 4C inserts the encrypted scrambled return data packet thus obtained into a return message whose destination address is the IP address of the client device 2 (extracted from the local table of the relay node 4-1 ).
  • the obtained B-MR scrambled return message is then transferred by the relay node 4-1 to the client device 2 (step G60).
  • the processing module 4C also replaces in the return data packet R-PKT the port number P5 and the source IP address @IP5 of the destination server 5 by its port number P4-1 and its IP address @IP4-1 (which can be described as “internal” compared to the external P4-l_e port number and IP address @4-l_e visible to the server recipient 5), before scrambling and encrypting it.
  • step E80 On receipt of the scrambled return message B-MR by the client device 2 (step E80), the latter decrypts it, then removes the interference introduced by the relay node 4-1 (by removing the bits/symbols added in accordance with the (x) PATT stuffing reason(s)) and accesses the return data packet R-PKT sent by the destination server 5 (step E90).
  • the client device 2 If the client device 2 supports the partial-offload function (“partial-offload” parameter valued at 1 in the REQ-DNS request), and the DNS server 3-1 has indicated in the “partial-offload” parameter of its REQ-DNS response the relay node 4-1, then the client device 2 addresses the new REQ'-DNS request to the relay node 4-1 directly, as illustrated in Figure 12A. It is the same for all subsequent name resolution requests (REQ"-DNS, etc.) connected to the REQ-DNS request. Note that the resolution of subsequent requests may result in a recipient server 5' different from the server recipient 5, as illustrated in Figure 12A.
  • the client device 2 If the client device 2 does not support the partial-offload function (“partial-offload” parameter set to 0 in the REQ-DNS request), the client device 2 continues to use the DNS server 3-1, as illustrated by Figure 12B. The same applies if the new DNS query REQ'-DNS is not correlated with the query REQ-DNS, including when the client device 2 supports the partial-offload function.
  • DNS exchanges between the client device 2 were considered, the DNS server(s) 3 and the relay nodes 4.
  • the invention applies to any type of name to be resolved, whatever the format, and not only to a domain name as defined by document RFC 1034.
  • everything that has been described previously with reference to a domain name applies to the resolution of any name of an IP resource.

Landscapes

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

Abstract

Le procédé de traitement selon l'invention d'une première requête (REQ-DNS) de résolution de nom provenant d'un dispositif client (2) est mis en œuvre par un serveur (3-1) de résolution de noms. Il comprend un envoi au dispositif client (2) d'une réponse à la première requête comprenant au moins une information relative à un serveur dit destinataire (5) résultant d'une résolution de la première requête. Le procédé comprend en outre un envoi au dispositif client (2) d'une pluralité d'éléments comprenant : - au moins une adresse d'au moins un nœud relais (4-1) sélectionné par le serveur de résolution de noms (3-1) auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire; et - au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.

Description

Description
PROCEDES DE RESOLUTION DE NOM, DE COMMUNICATION, DE TRAITEMENT DE MESSAGES ET SERVEUR, DISPOSITIF CLIENT ET NOEUD RELAIS CORRESPONDANTS
Technique antérieure
[0001] L'invention appartient au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement les communications avec un serveur de résolution de noms de domaine (ou DNS pour « Domain Name System » en anglais) dans un réseau de télécommunications, comme par exemple un réseau IP (pour « Internet Protocol » en anglais).
[0003] Le système DNS est une composante fondamentale dans la fourniture de services IP. En effet, il permet d'associer une ressource (telle qu'un nom de domaine, une URI (pour « Uniform Resource Identifier » en anglais), etc.) à une ou plusieurs adresses IP qui permettent à un dispositif (tel que par exemple un terminal) d'accéder à cette ressource.
[0004] A titre d'exemple, un serveur joignable en IPv4 publie auprès du système DNS un enregistrement (ou RR pour « Resource Record » en anglais) DNS de type « A », tandis qu'un serveur joignable en IPv6 publie un enregistrement DNS de type « AAAA » (ou « Quad A Resource Record » en anglais) ; un serveur joignable en IPv4 et IPv6 publie les deux types d'enregistrement.
[0005] Lorsqu'un dispositif souhaite établir une communication avec un serveur dit « destinataire » identifié par un nom de domaine (ou FQDN pour « Fully Qualified Domain Name » en anglais), le client DNS embarqué dans le dispositif envoie une requête de résolution de noms de domaine (dite requête DNS) à un serveur du système DNS (ou serveur DNS par souci de simplification) en précisant dans la requête le type d'enregistrement souhaité (A ou AAAA). Un dispositif supportant les deux protocoles IPv4 et IPv6 envoie deux requêtes DNS à un serveur DNS (une indiquant un enregistrement de type A, l'autre un enregistrement de type AAAA).
[0006] Sur réception de cette requête, le serveur DNS répond au dispositif en lui envoyant au moins une adresse IP associée au nom de domaine sur lequel porte la requête si une entrée correspondant à ce nom de domaine est disponible. S'il ne dispose pas d'une telle entrée, le serveur DNS relaie la requête vers un autre serveur selon la hiérarchie DNS connue de l'homme du métier. La réponse reçue de cet autre serveur est ensuite relayée par le serveur DNS initialement sollicité vers le dispositif à l'origine de la requête DNS. Le dispositif extrait l'adresse ou les adresses IP contenues dans la réponse et établit une communication avec le serveur destinataire en utilisant typiquement l'une de ces adresses IP.
[0007] Ces échanges entre le dispositif et le serveur DNS (désignés dans la suite par « communications DNS » par souci de simplification) sont conventionnellement mis en œuvre en clair, selon un mode appelé Do53 (ou « unencrypted DNS » en anglais). Ce mode non chiffré rend possible, aux entités localisées sur le chemin des communications DNS, l'accès à des informations sensibles, par exemple à des fins de profilage. Do53 présente donc un risque d'atteinte à la vie privée des utilisateurs.
[0008] Afin d'améliorer le niveau de confidentialité des communications DNS et restreindre l'accès aux informations sensibles véhiculées par ces communications DNS uniquement à des entités habilitées ou consenties, de nombreux mécanismes ont été spécifiés pour chiffrer les communications DNS. Des exemples de tels mécanismes sont « DNS over DTLS (DoD) », « DNS over TLS (DoT) », « DNS over HTTPS (DoH) », « DNS over QUIC (DoQ) », DNS over CoAP (ou DoC), etc. Toutefois, en dépit de la mise en œuvre de tels mécanismes, une entité localisée dans le chemin de communications DNS peut associer l'adresse de destination de paquets de données émis après un échange DNS avec un serveur ou un service donné en utilisant des techniques dites d'analyse statistique (ou « statistical analysis » en anglais), et obtenir ainsi des informations potentiellement sensibles sur les utilisateurs. Une étude de l'APNIC (pour « Asia Pacific Network Information Centre » en anglais) datant de 2019 s'est en effet intéressée aux informations qu'il est possible de tirer d'un ensemble d'adresses IP contactées par un équipement utilisateur. Cette étude montre notamment que la majorité des sites web ont une empreinte de chargement de page ou PLF (pour « Page Load Fingerprint » en anglais) unique ; il existe donc un risque qu'un site web visité par un utilisateur puisse être identifié à partir des adresses IP ciblées par son équipement utilisateur. Il en résulte une protection limitée de la vie privée des utilisateurs par les mécanismes DNS chiffrés précités.
Exposé de l'invention
[0009] L'invention vient notamment améliorer la situation précitée en proposant un procédé de traitement d'une première requête de résolution de nom provenant d'un dispositif client, ce procédé étant mis en œuvre par un serveur de résolution de noms et comprenant un envoi au dispositif client d'une réponse à la première requête comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le procédé de traitement est remarquable en ce qu'il comprend en outre un envoi au dispositif client d'une pluralité d'éléments comprenant : au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
[0010] Corrélativement, l'invention concerne également un serveur de résolution de noms configuré pour envoyer une réponse à une première requête de résolution de nom provenant d'un dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le serveur de résolution de noms est remarquable en ce qu'il est en outre configuré pour envoyer au dispositif client une pluralité d'éléments comprenant : au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
[0011] L'invention vise aussi un procédé de communication mis en œuvre par un dispositif client, comprenant une réception, en provenance d'un serveur de résolution de noms, d'une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le procédé de communication est remarquable en ce qu'il comprend en outre : une réception d'une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et o au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais ; et une application de ladite instruction de brouillage auxdits messages.
[0012] Corrélativement, l'invention concerne également un dispositif client configuré pour recevoir, en provenance d'un serveur de résolution de noms, une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête. Le dispositif client est remarquable en ce qu'il est en outre configuré pour : recevoir une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et o au moins une instruction de brouillage devant être appliquée par le dispositif client aux- dits messages avant de les adresser audit au moins un nœud relais ; et appliquer ladite instruction de brouillage auxdits messages.
[0013] Selon un autre aspect encore, l'invention vise aussi un procédé de traitement de messages mis en œuvre par un nœud relais sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce procédé comprenant : une acquisition d'au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d'au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, une suppression en utilisant ladite au moins une information acquise, du brouillage appliqué par le dispositif client ; et un transfert dudit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.
[0014] Corrélativement, l'invention concerne également un nœud relais dans un réseau de communications sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ce nœud relais étant configuré pour : acquérir au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages contenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d'au moins un message brouillé contenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, supprimer en utilisant ladite au moins une information acquise, le brouillage appliqué par le dispositif client ; et transférer ledit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.
[0015] L'invention propose donc une solution qui permet de prévenir l'accès à des informations sensibles par des équipements qui sont proches du dispositif client (du point de vue de la topologie du réseau). Ainsi, la solution s'applique particulièrement au niveau du réseau d'accès utilisé par un dispositif client (ex. réseau WLAN (« Wireless Local Area Network » en anglais) public ou privé, réseau mobile, etc.) en s'appuyant sur une pluralité d'entités de réseau (serveur(s) de résolution de noms, nœud(s) relais), pour prévenir des actions malveillantes susceptibles d'être mises en œuvre lors de communications DNS, ou plus généralement lors de communications en lien avec la résolution de ressources telles que des URI, des noms de domaine, etc. Ces ressources sont plus généralement désignées par « noms » dans la suite de ce document. L'invention a une application privilégiée mais non limitative lorsque les communications en question sont chiffrées ; aucune limitation n'est attachée au schéma de chiffrement envisagé alors pour transporter les messages échangés lors de ces communications (par exemple, pour des communications DNS, DoT, DoD, DoQ, DoH, DoC).
[0016] De même, aucune limitation n'est imposée quant à la nature du dispositif client (qui peut être par exemple un terminal, un CPE (pour « Customer Premises Equipment » en anglais), un décodeur de type STB (pour « Set Top Box » en anglais), etc.), ni à celle du nœud relais sélectionné par le serveur de résolution de noms (qui peut être notamment un serveur, un routeur, etc.).
[0017] La solution proposée par l'invention s'appuie plus particulièrement sur la sélection, par un serveur de résolution de noms de confiance sollicité par le dispositif client lorsqu'il souhaite accéder à un service donné, typiquement fourni par un serveur dit destinataire, d'au moins un nœud relais via lequel le dispositif client va interagir avec le serveur destinataire. Plusieurs nœuds relais peuvent être avantageusement utilisés lors d'une communication avec un serveur destinataire, par exemple chaque nœud relais est utilisé durant une période de temps limitée. Il convient par ailleurs de noter qu'une requête de résolution de nom peut donner lieu à une ou plusieurs communications avec un ou plusieurs serveurs destinataires. Les communications avec ces différents serveurs destinataires peuvent être gérées avec un ou plusieurs nœuds relais.
[0018] Plus spécifiquement, conformément à l'invention, le dispositif client adresse les messages contenant les données qu'il destine au serveur destinataire (autrement dit contenant les données qu'il souhaite lui envoyer dans le cadre de l'accès au service) à un nœud relais, qui se charge ensuite de les relayer vers le serveur destinataire. L'introduction d'un nœud relais entre le dispositif client et le serveur destinataire a pour effet de masquer le véritable destinataire (à savoir le serveur destinataire) des données envoyées par le dispositif client lorsqu'il accède au service, puisque l'adresse à laquelle sont envoyés les messages est celle du nœud relais et non celle du serveur destinataire, conformément à l'invention. L'adresse du serveur destinataire est quant à elle dissimulée dans le contenu des messages adressés au nœud relais, par exemple sous forme chiffrée au moyen d'un mécanisme de chiffrement partagé avec le nœud relais. Ceci permet de rendre l'identité du serveur destinataire inaccessible en cas d'interception des messages entre le dispositif client et le nœud relais et ce, tout en permettant au nœud relais de relayer ces messages vers le serveur destinataire.
[0019] Par exemple, dans un mode particulier de réalisation, les messages adressés audit au moins un nœud relais comprennent, sous forme chiffrée, des données destinées au serveur destinataire et une adresse du serveur destinataire.
[0020] Ces dispositions rendent ainsi difficile voire impossible à une entité malveillante localisée entre le dispositif client et le nœud relais d'obtenir par analyse statistique du trafic issu du dispositif client et/ou en établissant et analysant une empreinte de chargement de page, des informations révélant les pratiques de l'utilisateur du dispositif client et susceptibles de porter atteinte à sa vie privée.
[0021] De façon similaire, l'introduction d'un nœud relais entre le dispositif client et le serveur destinataire permet de masquer la véritable source des messages (c'est-à-dire l'identité du dispositif client), en cas d'interception et d'inspection de ces messages par une entité malveillante localisée au-delà du nœud relais (dans le sens dispositif client vers serveur destinataire).
[0022] Cette difficulté à obtenir par analyse statistique du trafic des données sensibles est accrue lorsque l'utilisation d'un (ou de plusieurs) nœud(s) relais est combinée avec une ou plusieurs actions de brouillage (supplémentaires) mises en œuvre par le dispositif client (éventuellement complétée(s) par des actions de brouillage mises en œuvre par le(s) nœud(s) relais). Ces actions de brouillage sont transmises sous formes d'instructions de brouillage au dispositif client par le serveur de résolution et peuvent être de différentes natures.
[0023] Par exemple, dans un mode particulier de réalisation du procédé de traitement de la première requête, ladite au moins une instruction de brouillage transmise par le serveur de résolution de noms au dispositif client comprend une instruction de bourrage (ou de remplissage ou encore de « padding » en anglais) des messages contenant des données destinées au serveur destinataire avant de les adresser audit au moins un nœud relais, cette instruction comprenant au moins un motif de bourrage à utiliser par le dispositif client pour brouiller lesdits messages ou une technique de génération d'au moins un tel motif de bourrage.
[0024] Corrélativement, dans un mode particulier de réalisation du procédé de communication, ladite au moins une instruction de brouillage comprend une instruction de bourrage desdits messages et l'application de ladite au moins une instruction de brouillage auxdits messages comprend un bourrage d'au moins un dit message contenant des données destinées au serveur destinataire et adressé au nœud relais en utilisant un motif de bourrage fourni dans ladite instruction de bourrage ou généré au moyen d'une technique de génération fournie dans ladite instruction de bourrage.
[0025] A titre illustratif, une instruction de bourrage des messages peut consister, dans le cadre d'un service de communication de type voix s'appuyant sur l'échange de paquets de données de petite taille entre le dispositif client et le serveur destinataire, à augmenter la longueur des paquets de données envoyés au nœud relais par le dispositif client et destinés au serveur destinataire en utilisant un motif de bourrage déterminé, fourni par le serveur de résolution de noms, ou généré par le dispositif client selon une technique de génération de motifs de bourrage fournie par le serveur de résolution de noms.
[0026] Le bourrage des messages par le dispositif client permet de banaliser le profil des messages émis par le dispositif client et ainsi d'homogénéiser le trafic en sortie du dispositif client. Pour renforcer la protection des données véhiculées par les messages envoyés au nœud relais, comme évoqué précédemment, les données, le motif de bourrage complétant ces données, et l'adresse du serveur destinataire peuvent être chiffrés avant d'être adressés au nœud relais. Ceci permet en outre de garantir l'authenticité et l'intégrité des messages échangés entre le dispositif client et le nœud relais, et les informations contenues dans ces messages. On peut, dans un mode particulier de réalisation, envisager une activation du chiffrement par défaut pour l'envoi de ces informations critiques (par ex. pour le motif de brouillage).
[0027] D'autres actions de brouillage des messages avant leur envoi au nœud relais peuvent être envisagées en sus ou en remplacement des actions précitées.
[0028] Ainsi, dans un autre mode de réalisation, ladite au moins une instruction de brouillage comprend une instruction d'établissement par le dispositif client d'au moins une connexion fictive avec et/ou via ledit au moins un nœud relais.
[0029] Une telle connexion fictive est établie en parallèle de la connexion utilisée par le dispositif client pour transmettre au nœud relais les messages destinés au serveur destinataire (désignée dans la suite par « connexion principale »). Elle peut se terminer au niveau du nœud relais ou être relayée par ce dernier jusqu'à un serveur dédié (c'est-à-dire capable d'établir et de gérer une connexion fictive convenablement et en toute connaissance de cause). Le dispositif client peut être configuré pour transmettre sur cette connexion fictive des données fictives, c'est-à-dire qui ne sont pas destinées à être « consommées » (c'est-à-dire exploitées, utilisées) par le nœud relais et/ou par le serveur dédié qui les reçoit. De même, les données applicatives fictives éventuellement transmises par le serveur dédié ne sont pas consommées par le relais et/ou par le dispositif client.
[0030] Dans un mode particulier de réalisation, le procédé de traitement d'une première requête de résolution de noms ou le procédé de communication peut comprendre en outre une étape de notification audit au moins un nœud relais d'au moins une information relative à ladite au moins une instruction de brouillage.
[0031] Cette notification du nœud relais par le serveur de résolution de noms ou par le dispositif client permet au nœud relais d'identifier aisément et de supprimer le brouillage appliqué des messages brouillés provenant du dispositif client avant leur transmission vers le serveur destinataire.
[0032] L'information notifiée au nœud relais peut comprendre l'instruction de brouillage en elle-même, telle qu'ordonnée par le serveur de résolution de noms au dispositif client, ou seulement certains éléments représentatifs de cette instruction de brouillage, suffisants pour permettre au nœud relais d'être en mesure de supprimer le brouillage introduit par le dispositif client. Par exemple, dans le cas d'une instruction de bourrage des messages, l'information en question, lorsqu'elle est notifiée au nœud relais par le dispositif client, peut être un indicateur délimitant ou identifiant le motif de bourrage contenu dans un message (par exemple, un tel indicateur peut comprendre un décalage de bits ou de symboles aussi appelé « bit/symbol offset » en anglais).
[0033] Les actions de brouillage ordonnées par le serveur de résolution de noms sont avantageusement prises en compte par le nœud relais lorsqu'il reçoit des messages brouillés du dispositif client contenant des données destinées au serveur destinataire, afin d'identifier puis de supprimer le brouillage introduit par le dispositif client avant de relayer les messages vers le serveur destinataire.
[0034] Le nœud relais peut également, sur réception d'au moins un message provenant du serveur destinataire et contenant des données destinées au dispositif client, appliquer un brouillage dudit au moins un message avant de le transférer vers le dispositif client, de façon transparente pour le serveur destinataire.
[0035] Le brouillage introduit par le nœud relais peut être équivalent à celui appliqué par le dispositif client (autrement dit de même nature, par exemple reposer sur les mêmes motifs de bourrage). Ce mode est appelé « mode de brouillage symétrique ».
[0036] En variante, le brouillage introduit par le nœud relais peut être différent de celui appliqué par le dispositif client ; par exemple, un bourrage des messages peut n'être appliqué que dans un sens, ou des motifs de bourrage différents peuvent être appliqués dans les deux sens, ou encore une émulation de connexions fictives peut être réalisée dans un sens (par exemple du dispositif client vers le nœud relais) tandis qu'un bourrage des messages est appliqué dans l'autre sens (par exemple du nœud relais vers le dispositif client), etc. Ce mode est appelé « mode de brouillage asymétrique ». Cette différence dans les actions de brouillage appliquées permet de tenir compte du caractère asymétrique de la volumétrie du trafic selon sa direction. En effet, une quantité plus importante de données utiles est généralement transmise dans le sens nœud relais vers dispositif client. Ces données peuvent présenter, pour une application donnée, des profils constants dans le temps et ainsi être utilisées pour des besoins de profilage (et donc de traçabilité/* tracking ») de l'utilisateur. Par conséquent, l'application d'un brouillage adéquat dans chacun des deux sens de la communication permet une protection plus efficace des informations sensibles relatives au dispositif client ou à son utilisateur.
[0037] Par ailleurs, il convient de noter qu'il n'est pas toujours possible d'appliquer le même brouillage dans le sens dispositif client vers nœud relais et dans le sens nœud relais vers dispositif client (par exemple, il se peut que les messages envoyés dans le sens dispositif client vers nœud relais ne contiennent pas autant de données que dans le sens inverse).
[0038] Grâce au brouillage introduit par le dispositif client, et éventuellement par le nœud relais, il est difficile voire impossible pour une entité tierce malveillante de déduire/extraire/extrapoler des informations sur le trafic en provenance et/ou à destination du dispositif client. Combinées à l'intervention du nœud relais jouant l'intermédiaire entre le dispositif client et le serveur destinataire, il est possible d'éliminer la mise en œuvre d'analyses statistiques par des entités tierces malveillantes présentes dans les réseaux impliqués dans l'acheminement du trafic DNS ou tout du moins de réduire la portée de telles analyses statistiques et de limiter la pertinence des informations qui sont obtenues à partir de telles analyses statistiques.
[0039] L'invention permet donc de garantir le respect de la confidentialité des communications établies par des dispositifs clients, et contribue à mieux préserver la vie privée des utilisateurs de ces dispositifs clients et à limiter les risques de profilage des utilisateurs. Les opérateurs de réseaux peuvent incidemment, par le biais de l'invention, offrir des services de résolution de noms (ex. services DNS) à valeur ajoutée et ainsi bénéficier de la confiance de leurs utilisateurs. On note que les utilisateurs en question ne sont pas nécessairement ceux auxquels les opérateurs fournissent une connectivité réseau.
[0040] Comme mentionné précédemment, l'introduction d'un nœud relais entre le dispositif client et le serveur destinataire a pour but de masquer le véritable destinataire des messages émis par le dispositif client, ainsi que la véritable source de ces messages (lorsqu'une inspection indue des messages a lieu au-delà du nœud relais), rendant difficile la mise en œuvre d'analyse statistique du trafic issu du dispositif client. Cette difficulté peut être accrue via un choix judicieux du ou des nœuds relais à utiliser par un dispositif client. Par exemple, au moins un dit nœud relais peut être sélectionné par le serveur de résolution de noms de sorte que le nœud relais satisfait au moins une condition parmi : empêcher une corrélation entre ce nœud relais et le serveur destinataire (par exemple, un même nœud relais peut être utilisé pour plusieurs serveurs destinataires distincts, ou des nœuds relais différents peuvent être sélectionnés pour un même dispositif client et un même serveur destinataire mais pour des communications différentes entre le dispositif client et le serveur destinataire) ; et/ou maximiser le nombre de dispositifs clients utilisant ledit nœud relais.
Ces critères permettent de limiter le risque de traçage des communications visant une résolution de nom (par ex. communications DNS) par une entité malveillante.
[0041] D'autres conditions à vérifier peuvent être prises en compte lors de la sélection d'un nœud relais pour un dispositif client et un serveur destinataire, comme optimiser les dispositifs clients utilisant le nœud relais sélectionné en fonction d'au moins un critère donné, tel que des considérations de charge ou des considérations géographiques (qui peuvent relever notamment d'un savoir-faire de l'opérateur et/ou de l'ingénierie/configuration des nœuds relais). Selon un autre exemple encore, un nœud relais peut être sélectionné parce qu'il vérifie une condition consistant à disposer (déjà) d'une route vers le serveur destinataire.
[0042] Il convient de noter que les critères évoqués ci-dessus ne sont pas exclusifs ; autrement dit, le serveur de résolution de noms peut prendre en compte plusieurs critères de façon simultanée pour sélectionner un nœud relais pour le dispositif client et le serveur destinataire.
[0043] Dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) comprend en outre une première indication qu'au moins un dit nœud relais peut être utilisé par le dispositif client pour envoyer au moins une deuxième requête de résolution de nom corrélée à la première requête.
[0044] En d'autres termes, non seulement le nœud relais en question est utilisé par le dispositif client pour transmettre des messages au serveur destinataire, mais il est également chargé de résoudre tout ou partie des futures requêtes de résolution de noms du dispositif client corrélées avec la première requête, par exemple portant sur un nom d'un sous-domaine d'un nom de domaine sur lequel portait la première requête. Ceci permet d'introduire un degré supplémentaire de brouillage, en rendant difficile l'établissement d'un lien par une entité malveillante entre un serveur de résolution de noms particulier et un dispositif client. En outre, chaque serveur de résolution de noms impliqué dans la communication du dispositif client avec le serveur destinataire n'a qu'une connaissance partielle des requêtes émises par le dispositif client.
[0045] On peut envisager d'introduire un degré de granularité dans les requêtes de résolution de noms orientées vers un nœud relais. Ainsi, dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) peut comprendre en outre une deuxième indication identifiant les requêtes de résolution de nom concernées par la première indication.
[0046] Dans un mode particulier de réalisation, la pluralité d'éléments transmise par le serveur de résolution au dispositif client (et incidemment reçue par le dispositif client en provenance du serveur de résolution) comprend en outre au moins un identifiant dudit au moins un nœud relais sélectionné par le serveur de résolution de noms.
[0047] Ce mode de réalisation présente plusieurs avantages.
[0048] Tout d'abord, il permet de gérer les situations où plusieurs nœuds relais peuvent être joignables en utilisant une même adresse IP. L'identifiant transmis dans la pluralité d'éléments permet au dispositif client de distinguer un nœud relais particulier parmi la pluralité de nœuds relais partageant la même adresse IP. [0049] En outre, la transmission de l'identifiant du nœud relais sélectionné par le serveur de résolution de noms permet de s'affranchir du maintien au niveau du serveur de résolution de noms d'états associant à chaque dispositif client le contactant un ou plusieurs nœuds relais (on parle dans ce cas de serveur de résolution de noms sans état ou « stateless » en anglais).
[0050] Dans un mode particulier de réalisation, la première requête comprend au moins un identifiant d'au moins un nœud relais précédemment sélectionné pour le dispositif client auquel le dispositif client envoie tout ou partie de ses messages contenant des données destinées au serveur destinataire.
[0051] Il convient de noter que le nœud relais en question peut avoir été sélectionné pour le dispositif client et pour le même serveur destinataire (typiquement pour une même communication avec ce serveur destinataire), par le serveur de résolution de noms auquel le dispositif client adresse la première requête ou par un autre serveur de résolution de noms. L'insertion de l'identifiant du nœud relais en cours d'utilisation par le dispositif client permet au serveur de résolution de noms auquel est adressée la première requête, selon la stratégie adoptée, soit de resélectionner le même nœud relais (c'est- à-dire au moins un dit nœud relais sélectionné par le serveur de résolution de noms coïncide avec un nœud relais identifié dans la première requête), par exemple pour exploiter une connexion existante, soit au contraire, de sélectionner sciemment un nœud relais différent, de façon à rendre plus difficile encore le traçage des communications du dispositif client. Il est en effet plus difficile dans ce dernier cas de corréler le serveur destinataire avec l'identité du relais inclus dans la première requête.
[0052] Par ailleurs, ce mode de réalisation permet de limiter les informations stockées par le serveur de résolution de noms (pas de maintien d'états nécessaire, comme expliqué précédemment), ce qui renforce la sécurité du mécanisme mis en œuvre par l'invention et limite les risques de traçage du dispositif client sur la base de ses communications DNS.
[0053] Dans un mode particulier de réalisation, la pluralité d'éléments est envoyée au dispositif client ou reçue par le dispositif client dans une réponse à la première requête de résolution.
[0054] Ce mode de réalisation permet d'appliquer sans délai l'invention à partir de la première requête de résolution. En outre, il permet avantageusement de limiter la signalisation requise entre le serveur de résolution de noms et le dispositif client pour mettre en œuvre l'invention.
[0055] Il convient de noter que l'utilisation des adjectifs « première » et « deuxième » a uniquement pour dessein de distinguer deux requêtes de résolution de noms successives, corrélées entre elles, par exemple une requête portant sur un nom de domaine et une requête ultérieure portant sur un sous- domaine de ce nom de domaine. Cette utilisation ne présuppose pas l'absence d'échanges DNS ou plus généralement de résolution de noms antérieur entre le dispositif client et le serveur de résolution de noms, par exemple l'envoi par le dispositif client et la résolution par le serveur de résolution de noms d'une requête portant sur un autre nom de domaine.
[0056] Dans un mode de réalisation l'envoi de ladite pluralité d'éléments par le serveur de résolution de noms au dispositif client est conditionné par une détection par le serveur de résolution de noms d'une option déterminée dans la première requête.
[0057] Ce mode de réalisation offre la possibilité à l'utilisateur du dispositif client de choisir s'il souhaite ou non bénéficier du mécanisme de protection proposé par l'invention. Par exemple, si le réseau utilisé par le dispositif client de l'utilisateur pour accéder au service fourni par le serveur destinataire est un réseau de confiance, l'utilisateur peut décider de désactiver la mise en œuvre de l'invention . A l'inverse, si le réseau n'est pas un réseau de confiance, l'utilisateur peut décider d'avoir recours à l'invention. Il convient de noter que cette désactivation peut également être réalisée par le dispositif client lui-même, de façon automatique c'est-à-dire sans intervention de l'utilisateur, de façon transparente pour lui.
[0058] Dans un mode particulier de réalisation, les procédés de traitement d'une (première) requête et de messages, et/ou de communication sont mis en œuvre par un ordinateur. [0059] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un serveur de résolution de nom conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de traitement d'une première requête de résolution de nom tel que décrit ci-dessus.
[0060] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif client conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de communication tel que décrit ci-dessus.
[0061] L'invention vise aussi un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un nœud relais conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de traitement de messages tel que décrit ci-dessus.
[0062] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0063] L'invention vise aussi un support d’informations ou un support d'enregistrements lisible par un ordinateur, et comportant des instructions d'un programme d’ordinateur tel que mentionné ci-dessus.
[0064] Le support d’informations ou d'enregistrements peut être n’importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0065] D’autre part, le support d’informations ou d'enregistrements peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d’autres moyens.
[0066] Le programme selon l’invention peut être en particulier téléchargé sur un réseau de type Internet.
[0067] Alternativement, le support d’informations ou d'enregistrements peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés de traitement et de communication selon l'invention.
[0068] Selon un autre aspect, l'invention concerne également un système dans un réseau de communications comprenant : un dispositif client selon l'invention ; un serveur de résolution de noms selon l'invention ; et au moins un nœud relais selon l'invention sélectionné par le serveur de résolution de noms pour ledit dispositif client.
[0069] Le système selon l'invention bénéficie des mêmes avantages cités précédemment que le dispositif client, le serveur de résolution de noms et le nœud relais selon l'invention.
[0070] On peut également envisager, dans d’autres modes de réalisation, que les procédés de traitement et de communications, le serveur de résolution de noms, le dispositif client, le nœud relais et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
[0071] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1 représente, dans son environnement, un système dans un réseau conforme à l'invention, dans un mode particulier de réalisation ;
[Fig. 2] la figure 2 représente schématiquement l'architecture matérielle d'un ordinateur pouvant héberger l'une quelconque des entités selon l'invention appartenant au système de la figure 1 ;
[Fig. 3] la figure 3 représente les modules fonctionnels d'un serveur de résolution de noms du système de la figure 1, conforme à l'invention ;
[Fig. 4] la figure 4 représente les modules fonctionnels d'un dispositif client du système de la figure 1, conforme à l'invention ;
[Fig. 5] représente les modules fonctionnels d'un nœud relais du système de la figure 1, conforme à l'invention ;
[Fig. 6] la figure 6 représente sous forme d'ordinogramme les principales étapes d'un procédé de traitement d'une requête de résolution de nom telles qu'elles sont mises en œuvre par le serveur de résolution de noms de la figure 3 ;
[Fig. 7] la figure 7 représente sous forme d'ordinogramme les principales étapes d'un procédé de communication telles qu'elles sont mises par le dispositif client de la figure 4 ;
[Fig. 8] la figure 8 représente sous forme d'ordinogramme les principales étapes d'un procédé de traitement de messages telles qu'elles sont mises en œuvre par le nœud relais de la figure 5 ;
[Fig. 9] la figure 9 comprend les figures 9A et 9B représentant respectivement une option EAO (pour « EDNS (Extension Mechanisms for DNS) ASTRA (A DNS-driven Guard Against STatistical Trafic Analysis) Option ») pouvant être utilisée dans une requête de résolution de noms et dans la réponse à cette requête pour mettre en œuvre l'invention, dans un mode particulier de réalisation ;
[Fig. 10] la figure 10 illustre de façon partielle et schématique un message brouillé adressé au nœud relais de la figure 5 et contenant des données destinées au serveur destinataire de la figure 1 ;
[Fig. 11] la figure 11 illustre schématiquement les changements de numéros de port et d'adresses source et de destination opérés par le nœud relais de la figure 5, dans une variante particulière de réalisation ; et
[Fig. 12] la figure 12 comprend les figures 12A et 12B représentant les échanges entre les entités du système 1 de la figure selon que le dispositif client du système supporte ou non la fonction « partial-offload ».
Description de l'invention
[0072] La figure 1 représente un système 1 dans un réseau de communications NW, conforme à l'invention, dans un mode particulier de réalisation. Aucune limitation n'est imposée quant à la nature du réseau de communications NW, celui-ci pouvant comprendre un ou plusieurs sous-réseaux, comme par exemple un ou plusieurs (sous-)réseaux d'accès (par exemple un réseau public ou privé de type WLAN, un réseau mobile, etc.), le réseau Internet, etc.
[0073] Conformément à l'invention, le système 1 comprend : un dispositif client 2, conforme à l'invention. Dans l'exemple de la figure 1, le dispositif client 2 est un terminal d'un utilisateur U tel qu'un téléphone mobile (par exemple de type « smartphone »), connecté à un réseau WLAN public AN 1 et à un réseau d'accès mobile AN2 via lesquels il peut accéder au réseau Internet. L'invention s'applique bien entendu à d'autres dispositifs clients fixes ou mobiles (par exemple à un décodeur tel qu'une STB, un CPE, etc.), ainsi qu'à d'autres réseaux (filaires, sans fil, etc.), le dispositif client 2 pouvant être connecté simultanément à un ou plusieurs réseaux d'accès, directement ou via un équipement intermédiaire tel qu'un CPE ; au moins un serveur de résolution de noms de confiance pour le dispositif client 2 (typiquement, considéré comme tel par l'utilisateur U du dispositif client 2), conforme à l'invention, et référencé de manière générale par 3. Dans l'exemple de la figure 1, on considère à titre illustratif deux serveurs 3 de confiance conformes à l'invention. Ces serveurs 3-1 et 3-2 sont à titre illustratif des serveurs de résolution de noms de domaine tels que définis par le document IETF RFC 1034, novembre 1987, aussi couramment désignés par serveurs DNS. L'invention peut toutefois s'appliquer dans le contexte de la résolution d'autres ressources IP désignées dans ce document de façon générale par « noms », comme par exemple des URI, etc. ; et au moins un nœud relais 4-1, 4-2, etc. conforme à l'invention, désigné plus généralement sous la référence 4 et s'interfaçant avec les serveurs 3 de résolution de noms, par exemple en utilisant le protocole RESTCONF décrit dans le document IETF RFC 8040, janvier 2017. Bien entendu, d'autres protocoles peuvent être envisagés en variante pour cette interface.
[0074] Dans le mode de réalisation décrit ici, le mécanisme proposé par l'invention, désigné dans la suite par procédure ou mécanisme AD ASTRA (pour « Advanced DNS-driven protection Against Statistical TRaffic Analysis » en anglais), est activé lorsque le dispositif client 2 utilise, pour accéder au réseau Internet et plus particulièrement à un service S quelconque (ex. service de communication vocale, service web, etc.) hébergé ou fourni par un serveur 5 distant associé à (c'est-à-dire identifié par) un nom de domaine donné (par exemple à titre illustratif, « service-s.com »), un réseau d'accès qui n'est pas un réseau de confiance pour le dispositif client 2. Un tel réseau, appelé « Untrusted » en anglais, est par exemple un réseau public tel que le réseau WLAN public AN1, ou un réseau « visiteur » tel qu'un réseau d'hôtel, de bar, d'une ville, etc. Il présente en effet un risque pour le dispositif client 2 selon lequel ses communications, notamment avec un serveur DNS 6 local du réseau en question, peuvent être interceptées par une entité tierce malveillante et le cas échéant exploitées par cette entité, par exemple en procédant à une analyse statistique, pour obtenir des informations susceptibles de compromettre la vie privée de l'utilisateur U.
[0075] Le mécanisme AD ASTRA est en revanche désactivé ici (bien que cela ne soit pas obligatoire), lorsque le réseau d'accès utilisé par le dispositif client 2 est un réseau de confiance pour le dispositif client 2 (aussi désigné par « Trusted Network » en anglais), comme par exemple le réseau mobile AN2. Un tel réseau de confiance est typiquement un réseau qui a été configuré comme tel par l'utilisateur U du dispositif client 2, ou selon une configuration par défaut, ou encore qui a été identifié comme tel par exemple en utilisant un mécanisme de vérification d'identité du réseau, etc. Alternativement, un réseau de confiance peut aussi être déterminé dynamiquement en procédant à la validation des assertions du réseau, de façon connue en soi. Le dispositif client 2 est alors configuré pour utiliser, lorsqu'il souhaite accéder au service S via un tel réseau de confiance, un serveur DNS 7 de confiance local (au réseau de confiance), annoncé par le réseau de confiance, par exemple au moyen d'un mécanisme d'annonce tel que décrit dans le document draft-ietf-add-dnr-13 édité par l'IETF et intitulé « DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) », août 2022. Le serveur DNS 7 peut être indifféremment un serveur DNS conforme à l'invention ou un serveur DNS connu de l'état de la technique ne mettant pas en œuvre l'invention.
[0076] L'activation/désactivation du mécanisme AD ASTRA en fonction du niveau de confiance accordé au réseau d'accès utilisé par le dispositif client 2 peut être configurée par défaut au niveau du dispositif client 2 (ce qui permet une activation ou une désactivation automatique du mécanisme en fonction des conditions d'attachement au réseau du dispositif client 2) ou être décidée dynamiquement, par exemple en interrogeant l'utilisateur U du dispositif client 2, via une interface utilisateur prévue à cet effet.
[0077] Les serveurs DNS 3 de confiance appartiennent à une liste L-DNS de serveurs DNS de confiance, configurée par exemple par défaut sur le dispositif client 2 ou définie par l'utilisateur U du dispositif client 2 (par exemple via une interface utilisateur prévue à cet effet). Cette configuration peut avoir été notamment réalisée par l'opérateur du réseau fournissant une connectivité IP au dispositif client 2 (par exemple, son fournisseur d'accès Internet) ou par l'utilisateur U du dispositif client 2. Par souci de simplification, on suppose que la liste L-DNS ne comprend que des serveurs DNS de confiance supportant le mécanisme AD ASTRA. Toutefois, en variante, la liste L-DNS peut également comprendre des serveurs DNS de confiance ne supportant pas ce mécanisme. [0078] Dans l'exemple de la figure 1, les serveurs DNS 3 compris dans la liste L-DNS se trouvent dans le réseau Internet ; bien qu'aucune limitation ne soit attachée à leur localisation à proprement parler, préférentiellement, les serveurs DNS 3 ne sont pas situés dans ou annoncés par un réseau « Un- trusted » (c'est-à-dire par un réseau qui n'est pas un réseau de confiance pour le dispositif client 2). [0079] Il convient de noter qu'il n'existe aucune limitation quant au nombre de serveurs DNS (ou plus généralement de résolution de noms) de confiance tels que spécifiés dans la liste L-DNS, qui peut être supérieur ou égal à 1. Dans le mode de réalisation décrit ici, on suppose que le dispositif client 2 embarque un client DNS référencé par CL (par exemple dans une application telle que son système d'exploitation ou OS pour « Operating System » en anglais, le client DNS CL pouvant être partagé par plusieurs applications), qui choisit selon une stratégie locale prédéfinie (par exemple via une configuration par défaut) le ou les serveurs DNS de confiance à solliciter parmi la liste L-DNS pour chaque résolution de noms de domaine requise lors de l'invocation d'un service tel que par exemple le service S fourni par le serveur distant 5. Cette stratégie locale peut notamment spécifier : un mode de choix persistant selon lequel un même serveur DNS est choisi selon une préférence locale ou sur la base d'informations caractéristiques des capacités des serveurs DNS de la liste L-DNS, et sollicité pendant une durée déterminée ; un mode de choix séquentiel, selon lequel le client DNS CL établit une liste de serveurs candidats L-CAND à partir de la liste L-DNS, qu'il ordonne selon un ou plusieurs critères. Par exemple, la liste L-CAND est établie et ordonnée en fonction d'un schéma de chiffrement supporté le cas échéant par chaque serveur DNS ; un tel schéma de chiffrement est par exemple un schéma de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC tel que cité précédemment. A titre illustratif, la liste L-CAND peut ainsi comprendre tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoH, suivis de tous les serveurs DNS de la liste L-DNS supportant le schéma de chiffrement DoT. Les serveurs DNS sont alors sollicités par le client DNS CL dans l'ordre de la liste L-CAND ainsi établie. Bien entendu, d'autres critères que les schémas de chiffrement peuvent être envisagés en variante, comme par exemple la localisation des serveurs DNS, leur(s) capacité(s) de traitement, etc. ; un mode de choix aléatoire : un serveur DNS est choisi aléatoirement par le client DNS CL pour toute nouvelle requête de résolution DNS. Ce mode de choix aléatoire peut résulter également en un choix aléatoire du schéma de chiffrement implémenté ; etc.
[0080] Ces exemples de stratégies adoptées par le client DNS CL du dispositif client 2 ne sont donnés qu'à titre illustratif, et d'autres stratégies peuvent être envisagées en variante. En outre, le dispositif client 2 peut embarquer un ou plusieurs clients DNS CL aptes à mettre en œuvre une telle stratégie lorsqu'ils sont activés.
[0081] Dans le mode de réalisation décrit ici, les communications entre le dispositif client 2 (et plus spécifiquement son client DNS CL) et un serveur DNS 3 de confiance, sélectionné par le client DNS CL du dispositif client 2 sont chiffrées. Elles sont par exemple conformes à l'un quelconque des protocoles DoT, DoD, DoH, DoQ, ou DoC. L'utilisation d'un transport DNS chiffré pour transmettre des messages entre le dispositif client 2 et un serveur DNS 3 garantit l'authenticité et l'intégrité de ces messages.
[0082] On suppose par ailleurs, par souci de simplification, que le dispositif client 2 échange directement avec le serveur DNS 3 de confiance, sélectionné par le client DNS CL, sans l'intervention d'un relais (ou « forwarder » en anglais) DNS. Toutefois, l'invention s'applique également en présence d'un forwarder DNS situé entre le dispositif client 2 et le serveur DNS 3 de confiance, sélectionné par le client DNS CL. Plus spécifiquement, si le forwarder DNS est de confiance, le dispositif client 2 lui adresse ses requêtes DNS ; dans ce cas, le forwarder DNS est configuré pour relayer les requêtes DNS du dispositif client 2 vers le serveur DNS 3 sélectionné par le client DNS CL. Si le forwarder DNS n'est pas de confiance, le dispositif client 2 est configuré pour adresser ses requêtes DNS directement au serveur DNS 3 sélectionné par le client DNS CL (et ainsi contourner le forwarder DNS). Ainsi, par souci de simplification dans la suite, la terminologie « requête DNS adressée par un dispositif client » désigne indifféremment une requête DNS provenant directement du dispositif client ou via un forwarder DNS comme cela vient d'être évoqué.
[0083] Conformément à l'invention, lorsque le mécanisme AD ASTRA est activé et un serveur DNS 3 de confiance est sollicité par le dispositif client 2 pour résoudre un nom de domaine associé au service S hébergé par le serveur distant 5, le serveur DNS 3 en question est configuré pour, outre résoudre le nom de domaine en question (directement ou indirectement en sollicitant un autre serveur DNS), sélectionner un ou plusieurs nœuds relais parmi les nœuds relais 4 du système 1 vers le(s)quel(s) orienter le dispositif client 2 pour envoyer ses messages contenant des données destinées au serveur distant 5 (serveur destinataire au sens de l'invention), émises dans le cadre du service S. Les communications entre le dispositif client 2 et le ou les nœuds relais 4 du système 1 sélectionnés, ainsi qu'entre ces nœuds relais 4 et les serveurs DNS 3 les ayant sélectionnés, sont chiffrées dans le mode de réalisation décrit ici, par exemple au moyen du protocole TLS (pour « Transport Layer Security » en anglais), version 1.3, éventuellement combiné à l'utilisation d'une fonction ECH (pour « Encrypted Client Hello »). Bien entendu, cette hypothèse n'est pas limitative en soi et d'autres protocoles et extensions de chiffrement peuvent être envisagés en variante dans le contexte de l'invention.
[0084] Dans le mode de réalisation décrit ici, le dispositif client 2, les serveurs DNS 3 et les nœuds relais 4 ont l'architecture matérielle d'un ordinateur 8 telle que représentée schématiquement dans la figure 2. Cette architecture matérielle s'appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication permettant à chacun des dispositifs précités de communiquer notamment avec les autres dispositifs du système 1. Ces moyens COM de communication peuvent notamment s'appuyer sur une interface de communication filaire ou sans fil, connue en soi et non décrite en détail ici, et/ou sur une ou plusieurs interfaces logicielles telles qu'une interface de programmation applicative (ou API pour « Application Programming Interface » en anglais) ou une interface de communication point-à-point, etc., et mettre en œuvre un ou plusieurs schémas de chiffrement comme évoqué précédemment.
[0085] La mémoire non volatile NVM (ou en variante la mémoire morte ROM) de l'ordinateur 8 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur PROC, et sur lequel est enregistré un programme d'ordinateur conforme à l'invention.
[0086] Dans le cas d'un serveur DNS 3 conforme à l'invention, ce programme d'ordinateur est référencé par PROG3 et comporte des instructions définissant les principales étapes d'un procédé de traitement d'une (première) requête de résolution de nom selon l'invention. Dans le cas du dispositif client 2 conforme à l'invention, ce programme d'ordinateur est référencé par PROG2 et comporte des instructions définissant les principales étapes d'un procédé de communication selon l'invention. Enfin, dans le cas d'un nœud relais 4 conforme à l'invention, ce programme d'ordinateur est référencé par PROG4 et comporte des instructions définissant les principales étapes d'un procédé de traitement de messages selon l'invention.
[0087] Le programme d'ordinateur PROG3 définit les modules fonctionnels d'un serveur DNS 3 conforme à l'invention, qui s'appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Dans le mode de réalisation décrit ici, ces modules fonctionnels comprennent notamment comme illustré par la figure 3 : un module 3A de réception, configuré pour recevoir des requêtes REQ-DNS de résolution de noms (requêtes DNS dans l'exemple envisagé ici) envoyées par des dispositifs clients, et notamment par le dispositif client 2 ; un module 3B traitement, configuré pour traiter (autrement dit résoudre) les requêtes REQ-DNS reçues par le module 3A de réception et élaborer des réponses REP-DNS à ces requêtes ; un module 3C de fourniture, configuré pour fournir à chaque dispositif client ayant sollicité le serveur DNS 3, supportant (et incidemment sollicitant) la mise en œuvre du mécanisme AD ASTRA, une pluralité d'éléments AD ASTRA-ELTS en plus des informations classiquement fournies en réponse à une requête REQ-DNS, comme détaillé davantage ultérieurement. Dans le mode de réalisation décrit ici, la pluralité d'éléments AD ASTRA-ELTS est fournie à un dispositif client ayant adressé une requête REQ-DNS au serveur DNS 3 dans la réponse REP-DNS à cette requête, par exemple dans une option EDNS (pour « Extension Mechanisms for DNS » en anglais) comme expliqué plus en détail ultérieurement. Ces hypothèses ne sont toutefois pas limitatives et on peut envisager que la pluralité d'éléments AD ASTRA-ELTS soit fournie au dispositif client à l'aide d'un ou plusieurs messages distincts de la réponse REP-DNS ; et un module 3D d'envoi, configuré pour envoyer aux dispositifs clients ayant sollicité le serveur DNS 3, les réponses REP-DNS élaborées par le module 3B de traitement ainsi que la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture.
[0088] Le module 3B de traitement procède, pour résoudre une requête REQ-DNS reçue d'un dispositif client, de façon conventionnelle en établissant, à partir d'enregistrements RR dont dispose le serveur DNS 3 ou auxquels il peut accéder (via un ou plusieurs autres serveurs DNS organisés de façon hiérarchique), une correspondance entre le nom sur lequel porte la requête REQ-DNS (par exemple, le nom de domaine « service-s.com » permettant d'accéder au service S) et une ressource IP (par exemple une adresse IP) d'un serveur associé à ce nom (le serveur 5 dans l'exemple du nom de domaine « service-s.com »).
[0089] Dans l'exemple envisagé ici, par souci de simplification, on se limite à des enregistrements RR de type A (établissant une correspondance entre un nom et une adresse IPv4 d'un serveur associé à ce nom) et des enregistrements RR de type AAAA (établissant une correspondance entre un nom et une adresse IPv6 d'un serveur associé à ce nom), un serveur associé à un nom pouvant être identifié par une adresse IPv4 et/ou une adresse IPv6 (et donc correspondre à un enregistrement de type A et/ou à un enregistrement de type AAAA). Il convient de noter que l'invention ne se limite toutefois pas à ces deux types d'enregistrements et s'applique également à d'autres types d'enregistrements RR comme des enregistrements RR de type SVCB (pour « Service Binding » en anglais), SRV (pour « Service resource record » en anglais), CNAME, etc., qui peuvent associer à des noms d'autres ressources qu'une adresse IP, comme par exemple un alias, un autre nom, une URI, etc.
[0090] La réponse REP-DNS à la requête REQ-DNS élaborée par le module 3B de traitement comprend ainsi au moins une information contenue dans un enregistrement RR relatif à un serveur (désigné ici par « serveur destinataire ») associé au nom sur lequel porte la requête REQ-DNS, et résultant de la résolution de la requête REQ-DNS par le module 3B de traitement. Dans l'exemple envisagé ici d'enregistrements RR de types A et AAAA, cette information comprend au moins une adresse IP (IPv4 et/ou IPv6) du serveur destinataire.
[0091] Comme évoqué précédemment, cette réponse REP-DNS comprend en outre, dans le mode de réalisation décrit ici, la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture du serveur DNS 3. Cette pluralité d'éléments AD ASTRA-ELTS comprend, conformément à l'invention, au moins les éléments suivants : au moins une adresse IP d'au moins un nœud relais 4 sélectionné par le serveur DNS 3 (par exemple par son module 3C de fourniture) pour le dispositif client 2 et pour le serveur destinataire associé au nom sur lequel porte la requête REQ-DNS (serveur distant 5 dans l'exemple envisagé), auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire. Cette adresse IP peut être éventuellement complétée par un numéro de port à utiliser par le dispositif client pour adresser ses messages au nœud relais 4, si un numéro de port par défaut n'est pas défini. Autrement dit, au lieu d'adresser les messages relatifs au service auquel il souhaite accéder au serveur destinataire identifié dans la réponse REP-DNS, le dispositif client doit adresser ces messages au nœud relais 4 (c'est-à-dire indiquer comme adresse de destination de ces messages l'adresse du nœud relais 4 au lieu de l'adresse du serveur destinataire). Le serveur destinataire auquel sont véritablement destinées les données utiles contenues dans ces messages reste toutefois identifié dans le contenu des messages adressés au nœud relais 4-1 afin qu'il puisse relayer ces données utiles vers le serveur destinataire. Ainsi, dans l'exemple envisagé du service S, si la pluralité d'éléments AD ASTRA- ELTS désigne le nœud relais 4-1, cela signifie que le dispositif client 2 doit adresser les messages contenant des données destinées au serveur distant 5 au nœud relais 4-1. Chaque message adressé au nœud relais 4-1 a pour adresse de destination, l'adresse du nœud relais 4-1 (incluant son adresse IP notée @IP4-1 et un numéro de port P4-1, qui peut être défini par défaut ou avoir été fourni par le serveur DNS 3 avec l'adresse IP du nœud relais 4-1 comme évoqué précédemment), et contient un paquet de données, appelé paquet de données intérieur (ou « inner- packet » en anglais), chiffré au moyen d'un schéma de chiffrement (par exemple, TLS, DTLS). Le paquet de données intérieur contient des données utiles destinées au serveur distant 5, et comme adresse de destination, l'adresse IP du serveur distant 5 et son numéro de port (aussi plus communément désigné par « adresse de transport »). L'adresse du serveur distant 5 est donc masquée par le biais du chiffrement dans le contenu du message adressé au nœud relais 4-1 ; et au moins une instruction INST de brouillage, destinée à être appliquée (autrement dit devant être appliquée) par le dispositif client 2 auxdits messages contenant des données destinées au serveur destinataire avant de les adresser audit au moins un nœud relais 4. Une telle instruction de brouillage peut comprendre par exemple une instruction de bourrage (« padding ») de tout ou partie des messages, et/ou une instruction d'émulation de connexions entre le dispositif client et le nœud relais ou via le nœud relais jusqu'à un serveur dédié en plus de la connexion utilisée pour envoyer les messages contenant les données destinées au serveur destinataire (autrement dit une instruction d'établissement de connexions « fictives » par le dispositif client), comme expliqué davantage ultérieurement.
[0092] La configuration et le fonctionnement des modules 3A à 3D d'un serveur DNS 3 conforme à l'invention sont décrits plus en détail en référence aux étapes du procédé de traitement d'une (première) requête de résolution de nom illustrées par la figure 6.
[0093] Pour ce qui concerne le dispositif client 2, le programme PROG2 stocké dans la mémoire NVM (ou en variante ROM) de l'ordinateur 8 définit les modules fonctionnels du dispositif client 2, qui s'appuient sur ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré dans la figure 4 : un module 2A d'envoi, embarqué dans le client DNS CL, et configuré pour envoyer à l'un des serveurs DNS 3 de la liste L-DNS choisi par le client DNS CL du dispositif client 2, une requête de résolution de nom REQ-DNS. Dans l'exemple envisagé ici, cette requête REQ-DNS porte sur un nom de domaine et sur un enregistrement RR de type A ou AAAA attaché à ce nom de domaine. Le module 2A d'envoi est activé par le client DNS CL à chaque fois que le dispositif client 2 souhaite accéder à un service, par exemple au service S hébergé par le serveur distant 5 et associé au nom de domaine « service-s.com ». Dans le mode de réalisation décrit ici, la requête REQ-DNS comprend en outre une option EDNS EAO, indiquant au serveur DNS 3 sollicité que le dispositif client 2 supporte (et incidemment sollicite) le mécanisme AD ASTRA. En variante, le support du mécanisme AD ASTRA par le dispositif client 2 peut être signalé au serveur DNS 3 par d'autres moyens (par exemple dans un autre message que dans la requête REQ-DNS, dans une autre option, etc.) ; un module 2B de réception, embarqué dans le client DNS CL, et configuré pour recevoir en provenance du serveur DNS 3 sollicité, la réponse REP-DNS à la requête REQ-DNS élaborée par ce dernier. Cette réponse REP-DNS comprend, comme indiqué précédemment, au moins une information relative à l'enregistrement RR demandé par le dispositif client 2 du serveur destinataire associé au nom sur lequel porte la requête REQ-DNS, par exemple une adresse IP du serveur destinataire. En outre, dans le mode de réalisation décrit ici, la réponse REP-DNS contient la pluralité d'éléments AD ASTRA-ELTS fournie par le serveur DNS 3 conformément au mécanisme AD ASTRA ; un module 2C d'exécution, configuré pour appliquer ladite au moins une instruction de brouillage contenue dans la pluralité d'éléments AD ASTRA-ELTS aux messages contenant des données destinées au serveur destinataire associé au nom sur lequel porte la requête REQ-DNS avant de les adresser à l'un des nœuds relais 4 identifiés dans la pluralité d'éléments AD ASTRA-ELTS ; et un module 2D d'envoi configuré pour envoyer au nœud relais 4 en question les messages brouillés obtenus par le module 2C d'exécution.
[0094] La configuration et le fonctionnement des modules 2A à 2D du dispositif client 2 selon l'invention sont décrits plus en détail en référence aux étapes du procédé de communication illustrées par la figure 7.
[0095] De façon similaire, le programme PROG4 stocké dans la mémoire NVM (ou en variante ROM) de l'ordinateur 8 définit les modules fonctionnels d'un nœud relais 4 conforme à l'invention, ces modules fonctionnels s'appuyant ou commandant les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 8. Ils comprennent notamment, dans le mode de réalisation décrit ici, comme illustré par la figure 5 : un module 4A d'acquisition, configuré pour acquérir des informations relatives à au moins une instruction INST de brouillage appliquée par un dispositif client conforme à l'invention tel que le dispositif client 2, pour lequel le nœud relais 4 a été sélectionné, ladite instruction de brouillage INST étant appliquée à des messages contenant des données destinées à un serveur destinataire avant que le dispositif client les adresse au nœud relais 4. L'acquisition des informations relatives à l'instruction INST de brouillage peut se faire par l'intermédiaire du serveur DNS 3 de confiance à l'origine de cette instruction ou par le dispositif client configuré pour l'appliquer ; et un module 4B de traitement, configuré pour : o sur réception d'un tel message, supprimer en utilisant les informations acquises, le brouillage appliqué par le dispositif client au message conformément à l'instruction de brouillage INST ; et o transférer le message obtenu après suppression du brouillage vers le serveur destinataire. Il convient de noter que le nœud relais 4 peut transférer le message obtenu directement au serveur destinataire ou par l'intermédiaire d'un autre nœud relais, dans le cas où plusieurs nœuds relais sont déployés en cascade. La façon dont le module 4B de traitement procède ne présente aucune difficulté pour l'homme du métier et n'est pas décrite plus en détail ici.
[0096] Dans le mode de réalisation décrit ici, le module 4B est en outre configuré pour, sur réception d'un message provenant du serveur destinataire et destiné au dispositif client pour lequel il a été sélectionné (par exemple au dispositif client 2), brouiller ce message et transférer le message brouillé obtenu au dispositif client. Il convient de noter que le module 4B n'applique pas nécessairement dans le sens nœud relais vers dispositif client, le brouillage qui a été appliqué dans le sens dispositif client vers nœud relais (c'est-à-dire les brouillages appliqués dans un sens et dans l'autre ne sont pas nécessairement les mêmes). Le brouillage appliqué dans le sens nœud relais vers dispositif client est par exemple choisi par le serveur DNS 3 de confiance. S'il diffère de celui appliqué dans le sens dispositif client vers nœud relais, le nœud relais 4 en est informé par exemple par le serveur DNS 3 de confiance et reçoit de ce dernier, via son module 4A d'acquisition, une instruction INST' de brouil- lage décrivant le brouillage à appliquer. Alternativement, l'instruction pour l'identification du brouillage est explicitement codée dans le message chiffré et donc communiquée par le dispositif client (resp. le nœud relais).
[0097] La configuration et le fonctionnement des modules 4A et 4B d'un nœud relais 4 selon l'invention sont décrits plus en détail en référence aux étapes du procédé de traitement de messages illustrées par la figure 8.
[0098] Nous allons maintenant décrire, en référence aux figures 6 à 8, les principales étapes des procédés de traitement d'une requête de résolution de nom (figure 6), de communication (figure 7) et de traitement de messages (figure 8) selon l'invention, tels qu'ils sont mis en œuvre respectivement par un serveur DNS 3 (dans l'exemple envisagé ci-après, le serveur DNS 3-1), le dispositif client 2 et un nœud relais 4 (dans l'exemple envisagé ci-après le nœud relais 4-1) conformes à l'invention, dans un mode particulier de réalisation.
[0099] En référence à la figure 7, comme évoqué précédemment, on suppose dans le mode de réalisation décrit ici que le dispositif client 2 est configuré (par exemple, par son fournisseur d'accès Internet ou par son utilisateur) avec une liste L-DNS de serveurs DNS 3 de confiance, conformes à l'invention supportant le mécanisme AD ASTRA.
[0100] De façon connue en soi, lorsqu'un dispositif client tel que le dispositif client 2 souhaite accéder par le biais d'une application installée sur le dispositif client par exemple, à un service hébergé au sein d'un environnement informatique , l'application en question envoie à un serveur DNS une requête DNS portant sur le nom (au sens DNS) de l'environnement informatique afin d'obtenir l'adresse (par exemple une adresse IP) d'un serveur avec lequel échanger pour bénéficier du service.
[0101] On suppose ici que le dispositif client 2 souhaite accéder par le biais d'une application APP au service S associé au nom de domaine « service-s.com » et hébergé par le serveur distant 5.
[0102] Le dispositif client 2 envoie alors, par l'intermédiaire de son module 2A d'envoi, une requête REQ- DNS de résolution du nom de domaine « service-s.com » (première requête au sens de l'invention) à l'un des serveurs DNS 3 de confiance, identifiés dans la liste L-DNS, à savoir ici au serveur DNS 3- 1 (étape E10). Le choix du serveur DNS 3-1 parmi la liste L-DNS résulte d'une stratégie locale appliquée par le dispositif client 2 et qui a été préalablement configurée dans le dispositif client 2, comme évoqué précédemment. On rappelle par ailleurs que les échanges entre le dispositif client 2 et le serveur DNS 3-1 (requêtes DNS et réponses aux requêtes DNS notamment) sont chiffrés, par exemple en utilisant l'un des schémas de chiffrement DoT, DoD, DoH, DoQ, ou encore DoC précédemment cités.
[0103] La requête REQ-DNS, de façon connue en soi, spécifie notamment le nom de domaine « service- s.com » auquel le dispositif client 2 souhaite accéder, ainsi que le type d'enregistrement RR visé par la requête (par exemple ici un enregistrement RR de type A si le dispositif client 2 supporte le protocole IPv4 ou un enregistrement RR de type AAAA si le dispositif client 2 supporte le protocole IPv6). Dans le mode de réalisation décrit ici, la requête REQ-DNS comporte en outre une option EDNS appelée EAO (nouvellement introduite pour les besoins de l'invention), indiquant au serveur DNS 3 sollicité, c'est-à-dire le serveur DNS 3-1, que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA.
[0104] La figure 9A illustre un exemple de format de l'option EAO insérée par le dispositif client 2 dans sa requête REQ-DNS indiquant au serveur DNS 3-1 que le dispositif client 2 supporte et sollicite la mise en œuvre du mécanisme AD ASTRA. Conformément au document RFC 6891 édité par l'IETF et intitulé « Extension Mechanisms for DNS (EDNS(0)) », avril 2013, l'option EAO comprend trois champs OPTION-CODE, OPTION-LENGTH et OPTION-DATA, le champ OPTION-LENGTH indiquant la taille en octets du champ OPTION-DATA.
[0105] Dans l'exemple illustré par la figure 9, le champ OPTION-DATA comprend un paramètre « partial- offload » et un paramètre « AID » (pour « AD ASTRA relay IDentifier » en anglais), ainsi qu'un emplacement réservé ou « reserved » en anglais, permettant au dispositif client 2 de communiquer des capacités dont il dispose en lien avec le mécanisme AD ASTRA ainsi que d'autres informations pouvant être utiles au serveur DNS 3 sollicité. Plus particulièrement : le paramètre « pa rtia l-off load » est utilisé par le dispositif client 2 dans une requête pour indiquer au serveur DNS 3-1 s'il supporte (paramètre valorisé à 1 par exemple) ou non (paramètre valorisé à 0 par exemple) l'envoi d'une première requête de résolution de nom vers le serveur DNS 3-1 (requête REQ-DNS) puis l'envoi de requêtes de résolution de nom ultérieures (deuxièmes requêtes au sens de l'invention, notées REQ'-DNS, REQ"-DNS, etc.), corrélées à la première requête de résolution de nom REQ-DNS, vers un autre serveur de résolution de nom que le serveur DNS 3.1 dont l'information de joignabilité (par exemple son adresse IP) lui est communiquée par le serveur DNS 3-1. Cet autre serveur de résolution de nom peut typiquement être un nœud relais sélectionné par le serveur DNS 3-1 conformément à l'invention. Par « requêtes corrélées », on entend ici qu'il existe un lien entre les deux questions posées dans les deux requêtes, par exemple la première requête porte sur la résolution d'un nom de domaine « parent » (par exemple « service-s.com ») tandis que la deuxième requête porte sur la résolution d'un nom d'un sous-domaine du domaine parent (c'est-à-dire « *. service-s. corn » dans l'exemple envisagé ci-avant où * désigne une chaîne de caractères). Un autre exemple de corrélation est la découverte par le dispositif client 2 de noms (ou de « références » ou encore « referrals » en anglais) nécessitant une résolution lors du traitement de données envoyées par le serveur destinataire résultant de la résolution de la première requête ; la ou les deuxièmes requêtes envoyées pour résoudre ces noms sont corrélées au sens de l'invention à la première requête. La corrélation est établie par le dispositif client 2 dès lors qu'il associe le serveur destinataire comme source des noms. Le paramètre « partial-offload » peut être valorisé à 0 par défaut. Dans la suite de la description, si le paramètre « partial-offload » est valorisé à 1 par le dispositif client 2, on dit que celui-ci supporte la fonction « partial-offload » (fonction de « décharge » de requêtes DNS sur un autre serveur que le serveur DNS 3-1 chargé de traiter la première requête REQ-DNS) ; et le paramètre « AID » est utilisé par le dispositif client 2 pour indiquer s'il utilise déjà, pour des connexions actives, un nœud relais conformément à l'invention, dans le cadre d'une mise en œuvre du mécanisme AD ASTRA pour le service S associé au nom de domaine « service-S.com » hébergé par le serveur 5 (autrement dit pour envoyer des messages contenant des données destinées au serveur 5), et le cas échéant un identifiant de ce nœud relais. Aucune limitation n'est imposée quant à la forme de l'identifiant en question : il peut s'agir d'un alias, d'un nombre, d'un nom de domaine, d'un condensé (ou « hash » en anglais), etc. Le dispositif client 2 peut éventuellement associer cet identifiant à une préférence destinée au serveur DNS 3-1, par exemple « match » s'il souhaite que le serveur DNS 3-1 sélectionne le même nœud relais lors de son traitement de la requête REQ-DNS, ou « not match » pour demander l'utilisation d'un autre nœud relais. Dans le mode de réalisation décrit ici, cette préférence n'est pas nécessairement contraignante pour le serveur DNS 3-1 et peut ne pas être prise en compte par celui-ci. Bien entendu, ceci n'est qu'un choix d'implémentation et on peut en variante envisager que cette préférence du dispositif client 2 soit contraignante pour le serveur DNS 3-1.
[0106] En référence à la figure 6, sur réception de la requête REQ-DNS par son module 3A de réception (étape F10), le serveur DNS 3-1 détermine si cette dernière contient l'option EAO (étape test F20).
[0107] Si la requête REQ-DNS ne contient pas l'option EAO (réponse « non » à l'étape test F20), le serveur DNS 3-1 traite (c'est-à-dire résout) par l'intermédiaire de son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l'homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS comme évoqué précédemment (étape F30), puis envoie sa réponse REP-DNS-0 au dispositif client 2 (étape F40). Cette réponse REP-DNS-0 comprend ici l'adresse IP notée @IP5 du serveur 5 associé au nom de domaine « service-s.com ».
[0108] Si la requête REQ-DNS contient l'option EAO (réponse « oui » à l'étape test F20), comme c'est le cas dans l'exemple envisagé ici, le serveur DNS 3-1 traite (résout) via son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l'homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS (étape F50). Ce traitement est identique à celui réalisé lors de l'étape F30.
[0109] Le module 3B de traitement du serveur DNS 3-1 obtient en résolvant la requête REQ-DNS, l'enregistrement RR du serveur 5 (serveur destinataire au sens de l'invention) associé au nom de domaine « service-s.com » et plus particulièrement son adresse IP @IP5 qui est contenue dans cet enregistrement RR (information relative au serveur destinataire résultant de la résolution de la requête REQ- DNS au sens de l'invention). Il inclut l'adresse @IP5 dans la réponse REP-DNS à la requête REQ- DNS.
[0110] Par ailleurs, conformément à l'invention, le serveur DNS 3-1, supportant le mécanisme AD ASTRA, sélectionne via son module 3C de fourniture au moins un nœud relais 4 pour le serveur destinataire 5 (étape F60). Dans l'exemple envisagé ici, il sélectionne le nœud relais 4-1. Le nœud relais 4-1 ainsi sélectionné est destiné à être utilisé par le dispositif client 2 pour lui adresser les messages qu'il souhaite envoyer au serveur destinataire 5, dans le cadre de son accès au service S (au lieu de les envoyer directement au serveur destinataire 5). Le nœud relais 4-1 est chargé ensuite de relayer ces messages vers le serveur destinataire 5, directement ou par l'intermédiaire d'un autre nœud relais 4 lorsque des nœuds relais sont déployés en cascade.
[0111] Il convient de noter que si la requête REQ-DNS est adressée par le dispositif client 2 à un serveur DNS de confiance ne supportant pas le mécanisme AD ASTRA et en particulier l'option EAO (par exemple lorsque la liste L-DNS comprend à la fois des serveurs DNS de confiance supportant le mécanisme AD ASTRA et des serveurs DNS de confiance ne le supportant pas), alors celui-ci répond au dispositif client 2 en lui envoyant un message d'erreur. Sur réception du message d'erreur, le dispositif client 2 peut solliciter un autre serveur DNS, renvoyer la requête au même serveur mais sans l'option EAO, mettre fin à la communication et générer une notification locale (application, utilisateur, etc.) indiquant l'échec de la tentative de résolution, etc.
[0112] Pour sélectionner un nœud relais 4 pour un serveur destinataire 5 et un dispositif client 2, le module 3C de fourniture du serveur DNS 3-1 peut tenir compte d'un ou de plusieurs critères de sélection. Notamment, le module 3C de fourniture peut sélectionner un nœud relais 4 vérifiant une ou plusieurs conditions parmi les conditions suivantes : empêcher l'établissement d'une corrélation entre le nœud relais 4 sélectionné et le serveur destinataire. Typiquement, le module 3C de fourniture doit éviter qu'un nœud relais 4 ne soit sélectionné que pour un unique serveur destinataire, ou pour des communications distinctes entre le dispositif client 2 et le serveur destinataire, il peut sélectionner des nœuds relais 4 différents ; maximiser le nombre de dispositifs clients utilisant un nœud relais 4 sélectionné ; optimiser les dispositifs clients utilisant un nœud relais 4 sélectionné en fonction d'au moins un critère donné, comme par exemple des considérations de charge, des considérations géographiques, etc. ; disposer (déjà) d'une route depuis le nœud relais 4 sélectionné vers le serveur destinataire. Cette information peut être obtenue par le module 3C de fourniture en interrogeant les nœuds relais 4 du système 1 pour obtenir les tables de routage maintenues par ces derniers ; etc.
[0113] Dans un autre mode de réalisation, le module 3C de fourniture du serveur DNS 3-1 peut sélectionner de façon aléatoire un nœud relais 4 parmi une liste de nœuds relais avec laquelle il a été préalablement configuré. [0114] Par ailleurs, comme évoqué précédemment, le serveur DNS 3-1 peut également sélectionner une pluralité de nœuds relais en appliquant les critères évoqués précédemment, chaque nœud relais étant destiné à être utilisé par le dispositif client 2 pendant une durée déterminée (par exemple, la durée d'une connexion).
[0115] En outre, si l'option EAO de la requête REQ-DNS comprend un identifiant AID d'un nœud relais précédemment sélectionné pour le dispositif client 2 et le serveur destinataire 5 associé au service S, le serveur DNS 3-1 peut tenir compte de cet identifiant AID lors de la sélection du nœud relais (et le cas échéant de la préférence associée à cet identifiant AID indiquée par le dispositif client 2). Par exemple, si le dispositif client 2 a inséré dans l'option EAO un identifiant AID d'un nœud relais 4, le serveur DNS 3-1 peut sélectionner un nœud relais 4 de façon à éviter d'associer un même nœud relais avec un même serveur destinataire pour ce dispositif client 2, de sorte à minimiser le risque de traçage des communications DNS du dispositif client 2 par une entité malveillante (une telle entité éprouverait en effet une grande difficulté alors à établir une corrélation entre le serveur destinataire et l'identifiant du nœud relais). En variante, il peut décider de sélectionner un nœud relais coïncidant avec celui identifié dans l'identifiant AID de la requête REQ-DNS.
[0116] Il convient toutefois de noter qu'en fonction de sa configuration, le serveur DNS 3-1 peut ignorer les indications fournies par le dispositif client 2 dans le paramètre « AID » de l'option EAO de la requête REQ-DNS.
[0117] Suite à la sélection d'au moins un nœud relais 4 (le nœud relais 4-1 dans l'exemple illustratif envisagé), le module 3C de fourniture insère, dans une option EDNS EAO de la réponse REP-DNS à la requête REQ-DNS, une adresse du (ou des) nœud(s) relais sélection né(s) (étape F70). Dans le mode de réalisation décrit ici, cette adresse est une adresse IP (adresse IPv4 ou adresse IPv6). Elle fait partie de la pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture au dispositif client 2.
[0118] En variante, on peut envisager de fournir un nom de domaine associé à chaque nœud relais sélectionné comme adresse de joignabilité, au lieu d'une adresse IP. L'utilisation d'une adresse IP présente l'avantage de ne pas nécessiter de résolution de nom supplémentaire (ce qui permet au dispositif client 2 d'accéder plus rapidement au service S).
[0119] Dans une autre variante encore, l'adresse insérée par le module 3C de fourniture est une adresse de transport du nœud relais 4 et comprend une adresse IP du nœud relais 4 ainsi qu'un numéro de port à utiliser.
[0120] La figure 9B illustre un exemple de format de l'option EAO insérée par le serveur DNS 3-1 dans sa réponse REP-DNS (qui fait écho à l'option EAO insérée par le dispositif client 2 dans sa requête REQ- DNS). Comme représenté sur cette figure, le champ OPTION-DATA de l'option EAO comprend plusieurs paramètres, dont notamment un paramètre « relay-locators », dans lequel l'adresse IP du nœud relais 4-1 sélectionné (ou les adresses IP des nœuds relais sélectionnés) est (sont) insérée(s). [0121] Par ailleurs, conformément à l'invention, le module 3C de fourniture insère également dans l'option EAO de la réponse REP-DNS, dans la pluralité d'éléments AD ASTRA-ELTS qu'il fournit au dispositif client 2, au moins une instruction de brouillage INST devant être appliquée par celui-ci aux messages qu'il va adresser au nœud relais 4-1 et qui sont destinés au serveur destinataire.
[0122] Dans le mode de réalisation décrit ici, l'instruction de brouillage INST consiste en une instruction de bourrage (ou encore de remplissage ou de « padding ») des messages envoyés par le dispositif client 2 avant leur envoi au nœud relais 4-1. Elle est insérée dans un paramètre « padding » du champ OPTION-DATA de l'option EAO, comme illustré sur la figure 9. Cette instruction de bourrage est une instruction de compléter les messages destinés au serveur destinataire que le dispositif client 2 envoie au nœud relais 4-1 de sorte à homogénéiser leurs tailles. Le ou les motifs de bourrage appliqués par le dispositif client 2, notés PATT, sont choisis par exemple de sorte à rendre uniforme le gabarit des messages envoyés par plusieurs dispositifs clients. Ceci permet avantageusement de renforcer davantage l'anonymat des communications des dispositifs clients en question.
[0123] L'instruction de bourrage insérée dans le paramètre « padding » par le module 3C de fourniture peut prendre plusieurs formes. Elle peut comprendre une technique de génération à utiliser par le dispositif client 2 pour générer un ou plusieurs motifs PATT de bourrage. Une telle technique peut s'appuyer par exemple sur une technique d'apprentissage par renforcement (ou « Reinforcement Learning » en anglais) permettant au dispositif client 2 de déterminer les motifs de bourrage à appliquer et de les ajuster dans le temps si besoin.
[0124] En variante, une telle technique de génération peut être appliquée directement par le module 3C de fourniture du serveur DNS 3-1, et l'instruction de bourrage insérée dans le paramètre « padding » consigner le ou les motifs PATT de bourrage, générés par le module 3C de fourniture au moyen de cette technique de génération.
[0125] Dans le mode de réalisation décrit ici, le module 3C de fourniture notifie en outre le nœud relais 4-1 sélectionné pour le dispositif client 2 et le serveur destinataire 5, du contenu de l'instruction de bourrage (et plus particulièrement du ou des motifs PATT de bourrage ou de la technique de génération de tels motifs) qu'il demande au dispositif client 2 d'appliquer aux messages destinés au serveur destinataire 5 qu'il va envoyer au nœud relais 4-1 (étape F80).
[0126] Cette notification du nœud relais 4-1 par le serveur DNS 3-1 lui permet d'acquérir des informations relatives à ou au(x) instructions de brouillage ordonnées par le serveur DNS 3-1 au dispositif client 2 et d'être ainsi en mesure de traiter les messages en provenance du dispositif client 2 contenant des données destinées au serveur destinataire 5 avant de les relayer vers le serveur destinataire 5.
[0127] En variante, le nœud relais 4-1 peut acquérir de telles informations du dispositif client 2 lui-même. Par exemple dans le cas d'une instruction de bourrage, le dispositif client 2 peut notifier le nœud relais 4-1 en insérant dans ses messages contenant des données destinées au serveur destinataire 5 et adressés au nœud relais 4-1, des indicateurs délimitant ou identifiant les motifs de bourrage appliqués.
[0128] Dans un autre mode de réalisation, l'instruction de brouillage INST peut comprendre une instruction d'établissement par le dispositif client 2 d'une ou de plusieurs connexions fictives avec le nœud relais 4-1 et/ou via le nœud relais 4-1 (avec un ou plusieurs serveurs dédiés), en plus de sa connexion « principale » établie avec le nœud relais 4-1 pour transmettre des données au serveur destinataire 5 dans le cadre de l'accès au service S par le dispositif client 2. Le dispositif client 2 utilise alors ces connexions fictives pour transmettre des données « fictives » au nœud relais 4-1 et/ou au(x) serveurs) dédié(s), autrement dit, des données qui ne sont pas à proprement parler destinées à être exploitées (« consommées ») par le nœud relais 4-1 et/ou par le(s) serveur(s) dédié(s), mais qui ont uniquement vocation à brouiller les données destinées au serveur destinataire 5. Cette instruction d'établissement de connexions fictives peut être insérée dans un paramètre idoine du champ OPTION-DATA de l'option EAO, et être notifiée au nœud relais 4-1 comme décrit précédemment pour l'instruction de bourrage.
[0129] Bien entendu, d'autres instructions de brouillage peuvent être transmises par le serveur DNS 3-1 au dispositif client 2 dans le but d'introduire un bruit autour de la connexion du dispositif client 2 avec le serveur destinataire (serveur distant 5 dans l'exemple envisagé ici) et de rendre difficilement exploitables les informations interceptées par une entité malveillante placée sur le chemin de cette connexion. Elles sont notifiées également au nœud relais 4-1 afin qu'il puisse en tenir compte lors de la réception de messages brouillés en provenance du dispositif client 2.
[0130] Dans le mode de réalisation décrit ici, le module 3C de fourniture du serveur DNS 3-1 fournit deux autres éléments dans la pluralité d'éléments AD ASTRA-ELTS insérée dans l'option EAO de la réponse REP-DNS, à savoir : un paramètre « AID », dans lequel le module 3C de fourniture du serveur DNS 3-1 renseigne un identifiant du nœud relais 4-1 dont l'adresse figure dans le paramètre « relay-locators », et qu'il a sélectionné pour le nom de domaine « service-s.com » et le serveur destinataire 5. Si plusieurs nœuds relais sont sélectionnés, le paramètre « AID » comprend les identifiants de chacun des nœuds relais sélectionnés. Comme indiqué précédemment, aucune limitation n'est attachée à la forme de l'identifiant en question : il peut s'agir d'un alias, d'un nombre, d'un nom de domaine, d'un condensé (ou « hash » en anglais), etc. ; un paramètre « partial-offload » : si le dispositif client 2 a indiqué dans le paramètre « partial- offload » de l'option EAO de la requête REQ-DNS, le support de la fonction partial-offload, le serveur DNS 3-1 indique dans le paramètre « partial-offload » de l'option EAO de sa réponse REQ-DNS si le nœud relais qu'il a sélectionné (nœud relais 4-1) peut prendre en charge les échanges DNS ultérieurs du dispositif client 2 corrélés à la requête REQ-DNS (c'est-à-dire les « deuxièmes » requêtes au sens de l'invention), autrement dit s'il supporte la fonction partial- offload. Le module 3C de fourniture peut de façon optionnelle ajouter dans le paramètre « partial-offload » une indication supplémentaire identifiant les requêtes DNS concernées par la fonction partial-offload (par exemple, les requêtes portant sur un sous-domaine particulier ou tout autre filtre tel que l'origine des ressources DNS (noms de domaine (par ex. « ser- vice.example.com », service (SRV, par ex. "service._tcp.example.com"), etc.) à soumettre au système DNS). A titre illustratif, dans l'exemple envisagé ici d'une requête REQ-DNS portant sur le nom de domaine « service-s.com », le support de la fonction « partial-offload » par le nœud relais 4-1 indique au dispositif client 2 qu'il peut envoyer toutes ses requêtes ultérieures portant sur un sous-domaine « *.service-s.com » vers le nœud relais 4-1. Il convient de noter que le support de la fonction partial-offload par le nœud relais 4-1 n'implique pas nécessairement que les requêtes DNS ultérieures envoyées par le dispositif client 2 soient traitées (c'est-à-dire résolues) directement par le nœud relais 4-1. Celui-ci peut en effet être configuré pour adresser ces requêtes à un autre serveur DNS de confiance capable de les résoudre.
[0131] Les différents éléments indiqués par le serveur DNS 3-1 dans les paramètres « relay-locators », « AID » et « partial-offload » constituent comme évoqué précédemment une pluralité d'éléments AD ASTRA-ELTS fournie par le module 3C de fourniture du serveur DNS 3-1 au dispositif client 2. Dans le mode de réalisation décrit ici, cette pluralité d'éléments est fournie dans la réponse REP-DNS à la requête REQ-DNS, dans une option EAO. En variante, tout ou partie de cette pluralité d'éléments peut être fournie dans un ou plusieurs options ou messages distincts de la réponse REP-DNS.
[0132] La réponse REP-DNS incluant l'option EAO est ensuite envoyée par le module 3D d'envoi du serveur DNS 3-1 au dispositif client 2 (étape F90).
[0133] En référence à la figure 7 de nouveau, le dispositif client 2, et plus particulièrement son module 2B de réception, reçoit la réponse REP-DNS élaborée par le serveur DNS 3-1 à sa requête REQ-DNS (étape E20).
[0134] Le dispositif client 2 extrait de l'option EAO la pluralité d'éléments AD ASTRA-ELTS présents dans la réponse REP-DNS, et plus particulièrement les éléments compris dans les paramètres « relay-locators », « padding », « AID » et « partial-offload » de l'option (étape E30). Pour rappel, l'utilisation d'un transport DNS chiffré pour transmettre ces paramètres garantit avantageusement l'authenticité et l'intégrité des messages véhiculant ces paramètres, et donc incidemment, des paramètres reçus par le dispositif client 2.
[0135] L'identifiant AID est enregistré par le module 2B de réception dans un cache local du client DNS CL du dispositif client 2, en association avec la ressource IP correspondante, à savoir ici le nom de domaine « service-s.com ». Si une entrée est déjà présente dans le cache pour cette même ressource, le client DNS CL remplace son contenu par le nouvel AID renseigné dans la réponse REP-DNS. Lors de l'envoi de requêtes DNS ultérieures corrélées à la requête REQ-DNS, le client DNS CL renseigne le paramètre « AID » de l'option EAO de ces requêtes DNS ultérieures avec le contenu courant du cache local. [0136] Si le dispositif client 2 supporte la fonction partial-offload (comme c'est le cas dans l'exemple envisagé ici), le module 2B de réception enregistre également dans le cache local du client DNS CL les informations transmises dans le paramètre « partial-offload », à savoir que tout ou partie des nœuds relais indiqués dans le paramètre « relay-locators » peuvent être utilisés pour des requêtes DNS ultérieures corrélées à la première requête REQ-DNS ainsi que, le cas échéant, les indications supplémentaires fournies par le serveur DNS 3-1 et identifiant les requêtes DNS ultérieures concernées (étape E50). Il convient de noter que dans le mode de réalisation décrit ici, le paramètre « partial- offload » est renseigné par le serveur DNS 3-1 dans l'option EAO de la réponse REQ-DNS uniquement si le dispositif client 2 supporte la fonction partial-offload et l'a notifié au serveur DNS 3-1 en valorisant le paramètre « partial-offload » de la requête REQ-DNS à 1.
[0137] L'instruction de brouillage INST comprise dans le paramètre « padding » (instruction de bourrage des messages ici) est transmise par le module 2B de réception à l'application APP du dispositif client 2 à l'origine de la requête REQ-DNS de résolution du nom de domaine « service-s.com », afin qu'elle puisse exécuter (c'est-à-dire appliquer) cette instruction avant d'envoyer des messages destinés au serveur destinataire 5 au nœud relais 4-1 indiqué dans le paramètre « relay-locators » (étape E60). A cet effet, l'application APP comprend un module 2C d'exécution selon l'invention. Il convient de noter que l'ensemble des modules 2A à 2D du dispositif client 2 peuvent être hébergés dans l'application APP.
[0138] Comme illustré schématiquement par la figure 10, les messages destinés au serveur destinataire 5 contiennent des données utiles DATA échangées par l'application APP avec le serveur destinataire 5 lors de l'accès au service S. Comme évoqué succinctement précédemment, ces données sont chiffrées au moyen d'un premier mécanisme de chiffrement ENC1 selon les besoins du service S offert par le serveur destinataire 5, et consignées dans des paquets de données intérieurs notés I-PKT (« inner packets » en anglais). Chaque paquet de données intérieur I-PKT est destiné au serveur destinataire 5, c'est-à-dire qu'il a comme adresse de destination (contenue dans un entête du paquet IP I-PKT référencé par DEST dans la figure 10), l'adresse IP @IP5 du serveur destinataire 5 et le numéro de port P5 du serveur destinataire 5. Ce numéro de port est par exemple ici un numéro de port défini par défaut (en variante il peut avoir été obtenu lors de la résolution du nom de domaine associé au serveur destinataire 5, de façon connue en soi). Le paquet de données intérieur I-PKT constitue un paquet de données destinées au serveur destinataire au sens de l'invention. L'application APP applique alors, par le biais de son module 2C d'exécution, l'instruction de brouillage INST consignée dans les éléments AD ASTRA-ELTS, à chaque paquet de données intérieur I-PKT contenant des données destinées au serveur destinataire 5 (étape E60). Comme évoqué précédemment et illustré dans la figure 10, dans le mode de réalisation décrit ici, l'instruction de brouillage INST est une instruction de bourrage comprenant au moins un motif PATT de bourrage ou une technique de génération d'un tel motif PATT. Il en résulte que l'application APP ajoute des bits ou symboles de bourrage conformément au(x) motif(s) PATT de bourrage indiqué(s) dans l'instruction de bourrage INST ou généré(s) par le module 2C d'exécution en appliquant la technique de génération indiquée dans l'instruction de bourrage INST. L'application APP obtient ainsi un paquet de données B-PKT dit brouillé, constitué du paquet de données intérieur I-PKT complété par les bits ou symboles de bourrage du ou des motifs PATT de bourrage appliqué.
[0139] Il convient de noter que dans l'exemple illustré par la figure 10, le motif de bourrage PATT est inséré à la suite des données DATA. Cette hypothèse n'est toutefois pas limitative en soi ; le motif de bourrage PATT peut être inséré à d'autres endroits, ou être fragmenté et intercalé au milieu des données DATA.
[0140] Dans le mode de réalisation décrit ici, le paquet de données brouillé B-PKT est ensuite chiffré (conformément au schéma de chiffrement appliqué le cas échéant entre le dispositif client 2 et le nœud relais 4-1, référencé par ENC2 dans la figure 10), puis inséré par le module 2C d'exécution dans un message B-M dont l'adresse de destination comprend l'adresse IP du nœud relais 4-1 notée @IP4-1 (ou de l'un des nœuds relais 4 renseignés dans le paramètre « relay-locators ») fournie par la pluralité d'éléments AD ASTRA-ELTS, ainsi que son numéro de port P4-1. Ce numéro de port peut être un numéro de port défini par défaut, ou en variante avoir été consigné avec l'adresse @IP4-1 dans la pluralité d'éléments AD ASTRA-ELTS. Le message B-M obtenu, qui contient ici les données utiles DATA destinées au serveur destinataire 5, l'adresse IP @IP5 du serveur destinataire 5 et son numéro de port P5 (désignés communément par adresse de transport du serveur destinataire 5), et le motif de bourrage PATT, informations qui sont toutes sous forme chiffrée, est un message brouillé au sens de l'invention contenant des données destinées au serveur destinataire 5 mais adressées au nœud relais 4-1. Chaque message brouillé B-M obtenu par le module 2C d'exécution est ensuite envoyé par le module 2D d'envoi du dispositif client 2 au nœud relais 4-1 (étape E70).
[0141] On note que la figure 10 ne représente que partiellement le message brouillé B-M, et n'est fournie qu'à titre illustratif pour une meilleure compréhension de l'invention. Un tel message comprend bien entendu d'autres éléments, tels qu'une adresse IP et un numéro de port sources (qui peuvent également être chiffrés), etc.
[0142] En variante, comme évoqué précédemment, l'instruction INST de brouillage peut comprendre une instruction d'établissement de connexion(s) fictive(s) par le dispositif client 2 avec ou via le nœud relais 4-1 pour brouiller les messages contenant des données destinées au serveur destinataire 5 adressés au nœud relais 4-1. Selon cette variante, le module 2C d'exécution procède comme décrit précédemment : il insère dans un message M, sous forme chiffrée (au moyen du mécanisme de chiffrement ENC2), un paquet de données intérieur I-PKT ayant comme adresse de destination l'adresse @IP5 du serveur destinataire 5, et comprenant sous forme chiffrée au moyen du mécanisme de chiffrement ENC1 les données utiles DATA destinées au serveur destinataire 5 (pas d'ajout de motif(s) de bourrage sauf si l'instruction INST de brouillage contient également une instruction de bourrage en plus de l'instruction). Le message M a pour adresse de destination, l'adresse de transport du nœud relais comprenant son adresse IP @IP4-1 et son numéro de port P4-1.
[0143] Le message M ainsi formé est envoyé au nœud relais 4-1 par le module 2D d'envoi du dispositif client 2 sur la connexion principale établie par le dispositif client 2 avec le nœud relais 4-1 de façon connue en soi. Dans cette variante de réalisation, le module 2C d'exécution du dispositif client 2 établit en outre, en plus de la connexion principale utilisée pour adresser le message M au nœud relais 4-1, une ou plusieurs autres connexions fictives avec le nœud relais 4-1 et/ou via ce nœud relais 4-1 avec un ou plusieurs serveurs dédiés, conformément à l'instruction INST. Il envoie sur ces connexions fictives, simultanément à l'envoi du message M sur la connexion principale, des messages F-M contenant des données fictives, c'est-à-dire des données qui ne sont pas destinées à être consommées ou à être exploitées à proprement parler par le nœud relais 4-1 et/ou par les serveurs dédiés. Ces données fictives sont par exemple générées aléatoirement par le module 2C d'exécution.
[0144] Les connexions fictives ainsi émulées par le module 2C d'exécution viennent avantageusement s'ajouter à la connexion principale établie entre le dispositif client 2 et le nœud relais 4-1. Une entité tierce malveillante n'est donc pas en mesure de distinguer le message comprenant des données utile M destinées au serveur destinataire 5 des messages fictifs F-M envoyés simultanément sur les connexions fictives. Les connexions fictives établies par le dispositif client 2 viennent de ce fait par l'intermédiaire des messages fictifs F-M envoyés au nœud relais 4-1 ou via le nœud relais 4-1 en même temps que le message M « brouiller » le message M (que l'on désigne dans la suite par message brouillé B-M comme dans la variante précédente).
[0145] En référence à la figure 8, le nœud relais 4-1 reçoit via son module 4A de réception chaque message brouillé B-M envoyé par le dispositif client 2 (étape G 10).
[0146] Le nœud 4-1 déchiffre chaque message brouillé B-M reçu, puis supprime par l'intermédiaire de son module 4B de traitement le brouillage introduit par le module 2C d'exécution du dispositif client 2 (étape G20). Dans le mode de réalisation décrit ici, le brouillage introduit par le dispositif client 2 est un bourrage des paquets de données intérieurs émis par l'application APP au moyen d'au moins un motif PATT de bourrage fourni dans l'instruction INST ou généré à partir d'une technique de génération consignée dans cette instruction. Ce ou ces motifs PATT de bourrage ou la technique de génération permettant de les générer ont par ailleurs été transmis par le serveur DNS 3-1 au nœud relais 4-1 lors de l'étape de notification F80/étape G00. L'obtention de ce ou ces motifs PATT de bourrage ou de la technique permettant de les générer constitue en soi une étape d'acquisition d'informations relatives à l'instruction de brouillage INST appliquée par le dispositif client 2 au sens de l'invention.
[0147] On peut bien entendu envisager d'autres façons pour le nœud relais 4-1 d'acquérir des informations représentatives de l'instruction de brouillage INST appliquée par le dispositif client 2. Par exemple, le motif de brouillage peut être indiqué explicitement par le dispositif client dans le paquet brouillé lui-même, comme évoqué précédemment.
[0148] Ainsi, dans le mode de réalisation décrit ici, la suppression du brouillage introduit par le module 2C d'exécution du dispositif client 2 consiste pour le module 4B de traitement à retirer les bits/symboles de bourrage correspondant au(x) motif(s) PATT de bourrage qu'il a reçus du serveur DNS 3-1 ou générés à partir de la technique de génération reçue du serveur DNS 3-1. Il obtient ainsi les paquets de données intérieurs I-PKT destinés au serveur destinataire 5.
[0149] Dans la variante où l'instruction de brouillage INST comprend une instruction d'établissement de connexions fictives, le module 4B de traitement peut terminer localement les connexions fictives établies avec lui (ou relayer les messages F-M vers le(s) serveur(s) dédié(s) le cas échéant) et extraire le paquet de données intérieur I-PKT du message M reçu sur la connexion principale après déchiffrement du paquet.
[0150] Comme illustré schématiquement par la figure 11, le module 4B de traitement remplace dans chaque paquet de données intérieur I-PKT obtenu l'adresse IP et le numéro de port sources du dispositif client 2 (notés respectivement sur la figure @IP2 et P2) à l'origine du paquet de données intérieur I-PKT par son adresse IP et son numéro de port source externes (ou tout autre identifiant utilisé par le protocole de transport tel que par exemple les identifiants int-VTag ou rem-VTag pour le protocole SCTP), notés respectivement @IP4-l_e et P4-l_e. Il stocke le numéro de port P2 et l'adresse IP @IP2 sources du dispositif client 2 dans une table locale, dans sa mémoire non volatile NVM. Puis il transfère le paquet de données obtenu au serveur destinataire 5, de façon connue en soi (étape G30). Par souci de simplification, on considère ici que le paquet de données obtenu est transféré directement au serveur destinataire 5 (sans intermédiaire entre le nœud relais 4-1 et le serveur destinataire 5). Toutefois, cette hypothèse n'est pas limitative en soi, et l'invention s'applique également au transfert du paquet de données vers le serveur destinataire 5 par l'intermédiaire d'un ou de plusieurs autres nœuds relais.
[0151] De même, par souci de simplification on a considéré ici le même numéro de port P2 pour le dispositif client pour le message B-M et pour le paquet de données intérieur I-PKT. Toutefois, des numéros de port différents peuvent être utilisés par le dispositif client 2.
[0152] Dans un mode particulier de réalisation, le nœud relais 4-1 ajoute un brouillage avant de transférer le paquet de données I-PKT au serveur destinataire 5. Il peut notamment à cet effet, comme décrit précédemment pour le dispositif client 2, établir des connexions fictives avec des serveurs dédiés, ou avec d'autres (« vrais ») serveurs. Ce brouillage introduit entre le nœud relais 4-1 et le serveur destinataire 5 présente un avantage particulier notamment lorsque le nombre de dispositifs clients utilisant un même nœud relais 4 est inférieur à un seuil donné.
[0153] On suppose ici que le serveur destinataire 5 répond à au moins l'un des paquets de données I-PKT reçus du dispositif client 2 via le nœud relais 4-1, au moyen d'un paquet de données dit « retour » et noté R-PKT, les données utiles contenues dans ce paquet retour étant chiffrées selon les besoins du service S au moyen du mécanisme de chiffrement ENC1.
[0154] Conformément au numéro de port et à l'adresse IP sources indiqués dans les paquets de données intérieurs I-PKT reçus du nœud relais 4-1, le paquet de données retour R-PKT est envoyé par le serveur destinataire 5 au nœud relais 4-1. Sur réception de ce paquet retour R-PKT par le nœud relais 4-1 (étape G40), le module 4C de traitement remplace son numéro de port P4-l_e et son adresse IP @IP4-1 e externes dans l'adresse de destination du paquet de données retour R-PKT par le numéro de port P2 et l'adresse IP @IP2 du dispositif client 2. Par ailleurs, il brouille le paquet de données retour R-PKT ainsi modifié en lui appliquant ici le même type de brouillage que celui appliqué par le dispositif client 2 conformément à l'instruction de brouillage INST. Dans l'exemple envisagé ici, le module 4C de traitement applique ainsi le ou les motifs PATT de brouillage, notifiés par le serveur DNS 3-1 lors des étapes F80/G00 (ou générés à partir de la technique de génération fournie par le serveur DNS 3-1) (étape G50), puis chiffre le paquet de données retour brouillé obtenu dans son intégralité (c'est-à-dire incluant ses entêtes) conformément au schéma de chiffrement ENC2 utilisé entre le nœud relais 4-1 et le dispositif client 2. Le module 4C de traitement insère le paquet de données retour brouillé chiffré ainsi obtenu dans un message retour dont l'adresse de destination est l'adresse IP du dispositif client 2 (extraite de la table locale du nœud relais 4-1). Le message retour brouillé B-MR obtenu est ensuite transféré par le nœud relais 4-1 au dispositif client 2 (étape G60).
[0155] Dans une variante de réalisation (non illustrée sur la figure 11), le module 4C de traitement remplace également dans le paquet de données retour R-PKT le numéro de port P5 et l'adresse IP @IP5 sources du serveur destinataire 5 par son numéro de port P4-1 et son adresse IP @IP4-1 (que l'on peut qualifier d' « internes » par rapport au numéro de port P4-l_e et l'adresse IP @4-l_e externes visibles du serveur destinataire 5), avant de le brouiller et de le chiffrer.
[0156] Sur réception du message retour brouillé B-MR par le dispositif client 2 (étape E80), celui-ci le déchiffre, puis supprime le brouillage introduit par le nœud relais 4-1 (en enlevant les bits/symboles ajoutés conformément au(x) motif(s) PATT de bourrage) et accède au paquet de données retour R- PKT émis par le serveur destinataire 5 (étape E90).
[0157] Bien entendu, d'autres paquets de données intérieurs et retours peuvent être échangés de façon similaire ou identique entre le dispositif client 2 et le serveur destinataire 5 via le nœud relais 4-1 ou via un autre nœud relais 4 désigné par le serveur DNS 3-1 pour le dispositif client 2 et le serveur destinataire 5 et renseignés dans le paramètre « relay-locators » de la réponse REP-DNS.
[0158] On suppose maintenant qu'une nouvelle requête REQ'-DNS de résolution de nom est envoyée dans le cadre de l'accès au service S par le dispositif client 2, et que cette nouvelle requête REQ'-DNS est corrélée à la requête REQ-DNS précédemment envoyée (par exemple elle porte sur la résolution du nom d'un sous-domaine du domaine sur laquelle porte la requête REQ-DNS).
[0159] Si le dispositif client 2 supporte la fonction partial-offload (paramètre « partial-offload » valorisé à 1 dans la requête REQ-DNS), et que le serveur DNS 3-1 a indiqué dans le paramètre « partial-offload » de sa réponse REQ-DNS le nœud relais 4-1, alors le dispositif client 2 adresse la nouvelle requête REQ'-DNS au nœud relais 4-1 directement, comme illustré par la figure 12A. Il en est de même pour toutes les requêtes ultérieures de résolution de nom (REQ"-DNS, etc.) connectées à la requête REQ-DNS. On note que la résolution des requêtes ultérieures peut résulter en un serveur destinataire 5' différent du serveur destinataire 5, comme illustré par la figure 12A.
[0160] Si le dispositif client 2 ne supporte pas la fonction partial-offload (paramètre « partial-offload » valorisé à 0 dans la requête REQ-DNS), le dispositif client 2 continue d'utiliser le serveur DNS 3-1, comme illustré par la figure 12B. Il en est de même si la nouvelle requête DNS REQ'-DNS n'est pas corrélée à la requête REQ-DNS, y compris lorsque le dispositif client 2 supporte la fonction partial- offload.
[0161] Dans le mode de réalisation décrit ici, on a considéré des échanges DNS entre le dispositif client 2, le ou les serveurs DNS 3 et les nœuds relais 4. L'invention s'applique toutefois à tout type de noms à résoudre, quel que soit le format, et pas uniquement à un nom de domaine tel que défini par le document RFC 1034. Ainsi, tout ce qui a été décrit précédemment en référence à un nom de domaine s'applique à la résolution d'un nom quelconque d'une ressource IP.

Claims

Revendications
[Revendication 1] Procédé de traitement d'une première requête (REQ-DNS) de résolution de nom provenant d'un dispositif client (2), ledit procédé étant mis en œuvre par un serveur (3-1) de résolution de noms et comprenant un envoi (F90) audit dispositif client d'une réponse (REP-DNS) à la première requête comprenant au moins une information (@IP5) relative à un serveur dit destinataire (5) résultant d'une résolution de ladite première requête, ledit procédé étant caractérisé en ce qu'il comprend en outre un envoi (F90) audit dispositif client d'une pluralité d'éléments (AD ASTRA-ELTS) comprenant : au moins une adresse d'au moins un nœud relais (4-1) sélectionné (F60) par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et au moins une instruction (INST) de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
[Revendication 2] Procédé de traitement selon la revendication 1 dans lequel au moins un dit nœud relais (4- 1) sélectionné par le serveur de résolution de noms satisfait au moins une condition parmi : empêcher une corrélation entre ledit nœud relais et le serveur destinataire ; et/ou maximiser un nombre de dispositifs clients utilisant ledit nœud relais ; et/ou optimiser des dispositifs clients utilisant ledit nœud relais en fonction d'au moins un critère donné ; et/ou disposer d'une route dudit nœud relais vers le serveur destinataire.
[Revendication 3] Procédé de traitement selon la revendication 1 ou 2 dans lequel ladite au moins une instruction de brouillage (INST) comprend une instruction de bourrage desdits messages avant de les adresser audit au moins un nœud relais, ladite instruction comprenant au moins un motif (PATT) de bourrage à utiliser par le dispositif client pour brouiller lesdits messages ou une technique de génération d'au moins un tel motif de bourrage.
[Revendication 4] Procédé de communication mis en œuvre par un dispositif client (2), comprenant une réception (E20), en provenance d'un serveur (3-1) de résolution de noms, d'une réponse (REP-DNS) à une première requête (REQ-DNS) de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information (@IP5) relative à un serveur dit destinataire (5) résultant d'une résolution de la première requête, ledit procédé de communication étant caractérisé en ce qu'il comprend en outre : une réception (E20) d'une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais (4-1) sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages contenant des données destinées au serveur destinataire ; et o au moins une instruction (INST) de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais ; une application (E60) de ladite au moins une instruction de brouillage auxdits messages.
[Revendication 5] Procédé de communication selon la revendication 4 dans lequel ladite au moins une instruction (INST) de brouillage comprend une instruction de bourrage desdits messages et l'application (E60) de ladite au moins une instruction de brouillage comprend un bourrage d'au moins un dit message en utilisant un motif (PATT) de bourrage fourni dans ladite instruction de bourrage ou généré au moyen d'une technique de génération fournie dans ladite instruction de bourrage.
[Revendication 6] Procédé de communication selon la revendication 4 ou 5 dans lequel ladite au moins une instruction (INST) de brouillage comprend une instruction d'établissement d'au moins une connexion fictive avec et/ou via ledit au moins un nœud relais.
[Revendication 7] Procédé selon l'une quelconque des revendications 1 à 6 dans lequel lesdits messages adressés audit au moins un nœud relais comprennent, sous forme chiffrée, des données destinées au serveur destinataire et une adresse dudit serveur destinataire.
[Revendication 8] Procédé selon l'une quelconque des revendications 1 à 7 dans lequel ladite pluralité d'éléments (AD ASTRA-ELTS) comprend en outre une première indication qu'au moins un dit nœud relais peut être utilisé par ledit dispositif client pour envoyer au moins une deuxième requête de résolution de nom corrélée à la première requête.
[Revendication 9] Procédé selon la revendication 8 dans lequel ladite pluralité d'éléments (AD ASTRA-ELTS) comprend en outre une deuxième indication identifiant les requêtes de résolution de nom concernées par la première indication.
[Revendication 10] Procédé selon l'une quelconque des revendications 1 à 9 dans lequel ladite pluralité d'éléments (AD ASTRA-ELTS) comprend en outre au moins un identifiant (AID) dudit au moins un nœud relais sélectionné par le serveur de résolution de noms.
[Revendication 11] Procédé selon l'une quelconque des revendications 1 à 10 dans lequel la première requête (REQ-DNS) comprend au moins un identifiant (AID) d'au moins un nœud relais précédemment sélectionné pour le dispositif client auquel le dispositif client adresse tout ou partie de ses messages comprenant des données destinées au serveur destinataire.
[Revendication 12] Procédé selon la revendication 11 dans lequel au moins un dit nœud relais sélectionné par le serveur de résolution de noms coïncide avec un nœud relais identifié dans la première requête.
[Revendication 13] Procédé selon l'une quelconque des revendications 1 à 12 dans lequel tout ou partie de ladite pluralité d'éléments (AD ASTRA-ELTS) est envoyée au dispositif client ou reçue par le dispositif client dans ladite réponse (REP-DNS) à la première requête.
[Revendication 14] Procédé selon l'une quelconque des revendications 1 à 13 comprenant en outre une étape (F90) de notification audit au moins un nœud relais d'au moins une information relative à ladite au moins une instruction de brouillage.
[Revendication 15] Procédé de traitement de messages mis en œuvre par un nœud relais (4-1) sélectionné par un serveur (3-1) de résolution de noms pour un dispositif client (2) et un serveur dit destinataire (5), ledit procédé comprenant : une acquisition (G00) d'au moins une information relative à au moins une instruction de brouillage (INST) appliquée par le dispositif client à des messages comprenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception (G10) d'au moins un message brouillé comprenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, une suppression (G20), en utilisant ladite au moins une information acquise, du brouillage appliqué par le dispositif client ; et un transfert (G30) dudit au moins un message obtenu après suppression du brouillage vers le serveur destinataire.
[Revendication 16] Procédé de traitement selon la revendication 15 comprenant en outre sur réception (G40) d'au moins un message provenant du serveur destinataire et comprenant des données destinées au dispositif client, un brouillage (G50) dudit au moins un message avant de le transférer vers le dispositif client.
[Revendication 17] Serveur (3-1) de résolution de noms configuré pour envoyer une réponse à une première requête de résolution de nom provenant d'un dispositif client, ladite réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de ladite première requête, ledit serveur étant caractérisé en ce qu'il est en outre configuré pour envoyer audit dispositif client une pluralité d'éléments comprenant : au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages comprenant des données destinées au serveur destinataire ; et au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages avant de les adresser audit au moins un nœud relais.
[Revendication 18] Dispositif client (2) configuré pour recevoir, en provenance d'un serveur de résolution de noms, une réponse à une première requête de résolution de nom émise par le dispositif client, cette réponse comprenant au moins une information relative à un serveur dit destinataire résultant d'une résolution de la première requête, ledit dispositif client étant caractérisé en ce qu'il est en outre configuré pour : recevoir une pluralité d'éléments, en provenance du serveur de résolution de noms, comprenant : o au moins une adresse d'au moins un nœud relais sélectionné par le serveur de résolution de noms auquel le dispositif client doit adresser tout ou partie de ses messages comprenant des données destinées au serveur destinataire ; et o au moins une instruction de brouillage devant être appliquée par le dispositif client auxdits messages adressés audit au moins un nœud relais ; appliquer ladite instruction de brouillage auxdits messages.
[Revendication 19] Nœud relais (4-1) dans un réseau de communications sélectionné par un serveur de résolution de noms pour un dispositif client et un serveur destinataire, ledit nœud relais étant configuré pour : acquérir au moins une information relative à au moins une instruction de brouillage appliquée par le dispositif client à des messages comprenant des données destinées au serveur destinataire avant de les adresser au nœud relais ; sur réception d'au moins un message brouillé comprenant des données destinées au serveur destinataire et adressé au nœud relais par le dispositif client, supprimer en utilisant ladite au moins une information acquise le brouillage appliqué par le dispositif client ; et transférer ledit au moins un message obtenu après suppression du brouillage au serveur destinataire.
[Revendication 20] Système (1) dans un réseau de communications comprenant : un dispositif client (2) selon la revendication 18 ; un serveur (3-1) de résolution de noms selon la revendication 17 ; et au moins un nœud relais (4-1) selon la revendication 19 sélectionné par le serveur de résolution de noms pour ledit dispositif client.
PCT/EP2023/076686 2022-09-29 2023-09-27 Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants WO2024068722A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2209937A FR3140502A1 (fr) 2022-09-29 2022-09-29 Procédé de traitement d’une requête de résolution de nom, procédé de communication, procédé de traitement de messages et serveur, dispositif client et nœud relais configurés pour mettre en œuvre ces procédés
FRFR2209937 2022-09-29

Publications (1)

Publication Number Publication Date
WO2024068722A1 true WO2024068722A1 (fr) 2024-04-04

Family

ID=85037080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/076686 WO2024068722A1 (fr) 2022-09-29 2023-09-27 Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants

Country Status (2)

Country Link
FR (1) FR3140502A1 (fr)
WO (1) WO2024068722A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0887979A2 (fr) * 1997-06-27 1998-12-30 Sun Microsystems, Inc. Procédé et dispositif pour la communication de client-serveur par un réseau d'ordinateurs
EP1305914B1 (fr) * 2000-02-15 2017-10-18 VirnetX Inc. Améliorations apportées à un protocole de réseau agile afin de sécuriser les communications tout en garantissant la disponibilité du système

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0887979A2 (fr) * 1997-06-27 1998-12-30 Sun Microsystems, Inc. Procédé et dispositif pour la communication de client-serveur par un réseau d'ordinateurs
EP1305914B1 (fr) * 2000-02-15 2017-10-18 VirnetX Inc. Améliorations apportées à un protocole de réseau agile afin de sécuriser les communications tout en garantissant la disponibilité du système

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JONAS BUSHART ET AL: "Padding Ain't Enough: Assessing the Privacy Guarantees of Encrypted DNS", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 2 July 2019 (2019-07-02), XP081388573 *
MAYRHOFER NIC AT GMBH A: "The EDNS(0) Padding Option; rfc7830.txt", THE EDNS(0) PADDING OPTION; RFC7830.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 11 May 2016 (2016-05-11), pages 1 - 5, XP015112853 *
WICINSKI T ET AL: "DNS Privacy Considerations; rfc9076.txt", 23 July 2021 (2021-07-23), pages 1 - 15, XP015147778, Retrieved from the Internet <URL:https://tools.ietf.org/html/rfc9076> [retrieved on 20210723] *

Also Published As

Publication number Publication date
FR3140502A1 (fr) 2024-04-05

Similar Documents

Publication Publication Date Title
EP3503508B1 (fr) Procédé de traitement de requêtes et serveur proxy
FR3096202A1 (fr) Procédé et dispositif d’obtention d’une adresse IP
EP2294798B1 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
WO2018130796A1 (fr) Procédés et dispositifs de vérification de la validité d&#39;une délégation de diffusion de contenus chiffrés
EP3788762A1 (fr) Procédé d&#39;envoi d&#39;une information et de réception d&#39;une information pour la gestion de réputation d&#39;une ressource ip
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
FR3023098A1 (fr) Procede et systeme de traitement d&#39;une demande de resolution d&#39;un nom d&#39;un serveur, emise par une application cliente sur un reseau de communication.
WO2021123593A1 (fr) Procede de resolution d&#39;identifiants de nommage
WO2023083772A1 (fr) Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
WO2010072953A1 (fr) SYSTEME D&#39;ACHEMINEMENT D&#39;UN PAQUET DE DONNEES IPv4
WO2023083769A1 (fr) Procédé de traitement d&#39;au moins un paquet de données, dispositif et système associés.
WO2023083770A1 (fr) Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés
FR3081644A1 (fr) Procede de decouverte de fonctions intermediaires et de selection d&#39;un chemin entre deux equipements de communication
WO2023083771A1 (fr) Procédés de contrôle, de vérification et de configuration, et entités configurées pour mettre en œuvre ces procédés
WO2024121281A1 (fr) Procédé de gestion d&#39;un ensemble d&#39;adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés
WO2023117802A1 (fr) Procédés d&#39;identification d&#39;au moins un serveur de mitigation et de protection d&#39;un domaine client contre une attaque informatique, dispositifs et signal correspondants
WO2018234662A1 (fr) Procédé de contrôle de l&#39;obtention par un terminal d&#39;un fichier de configuration
WO2022117941A1 (fr) Procédé de détection d&#39;un équipement malveillant dans un réseau de communication, équipement de communication et programme d&#39;ordinateur correspondants
WO2024083694A1 (fr) Procédé de traitement d&#39;une requête en résolution d&#39;au moins un identifiant de nommage, dispositif et programme d&#39;ordinateur correspondants
FR3136922A1 (fr) Procédé de communication entre un premier équipement et un serveur distant, procédé de gestion des communications, premier équipement, serveur distant et programme d’ordinateur correspondants.
FR3084550A1 (fr) Procede de traitement d&#39;un paquet de donnees, dispositif, equipement de communication et programme d&#39;ordinateur associes
FR3018411A1 (fr) Procede et systeme de traitement d&#39;une requete dns emise par un noeud reseau au cours d&#39;une tentative dacces par une application cliente a un serveur distant sur un reseau ip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23783316

Country of ref document: EP

Kind code of ref document: A1