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 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 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 Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=85037080

Family Applications (1)

Country Status (4)

Family Cites Families (2)

• 2022
  • 2022-09-29 FR FR2209937A patent/FR3140502A1/fr not_active Withdrawn
• 2023
  • 2023-09-27 CN CN202380069882.4A patent/CN119999172A/zh active Pending
  • 2023-09-27 WO PCT/EP2023/076686 patent/WO2024068722A1/fr not_active Ceased
  • 2023-09-27 EP EP23783316.5A patent/EP4595408A1/de active Pending

Also Published As

Similar Documents

Legal Events