In recent years, several actions aimed at strengthening the security and privacy of users on the Internet have been taken. Focus on techniques that have been developed and deployed to prevent unintended third parties from accessing and manipulating the communication. One example is the large-scale deployment of HTTPS to provide encrypted communication for accessing web content. Efforts to deploy new protocols that encrypt associated data like Domain Name System (DNS) queries are another. These techniques prevent passive observers from knowing the exact data being exchanged, but they can still infer which parties are communicating and sometimes even what services have been requested.
More recently, attention has focused on various mechanisms that enhance user privacy by concealing even more data and metadata from Internet communications. These mechanisms often rely on a relay service that mediates communication between two hosts. Although at first glance it seems counter-intuitive to involve yet another party in the communication process to protect user privacy, the logic behind the use of relays is that ultimately each party does not can access only a limited set of information, and therefore each party knows less than before.
These relay services aim precisely to separate two important pieces of information: knowledge of the identity of the person accessing a service is separated from knowledge of the service to which he is accessing. This requires two levels of encryption.
Relay services in practice
Simple VPN services only add one level of encryption at￼ the relationship between the client and the VPN server: ￼the VPN server can always see which services are being accessed, and by whom. Within the Internet Engineering Task Force (IETF), the main standards body for Internet technologies, most of the activities related to these ￼information separation objectives are indicated using the term Oblivious, but there is also MASK (Application substrate multiplexed on QUIC encryption) and a new group to be created called PPM (Privacy Preserving Measurements) that applies this communication model to different use cases.
MASK is a new IETF working group that extends HTTP CONNECT to initiate and manage the use of QUIC-based relays. Check out the background of QUIC and MASK in our previous blog posts. MASK is a tunnel-based approach similar to VPN services. However, it establishes an encrypted connection to a relay, or so-called MASK server, using QUIC as the tunnel transport, and then forwards traffic through that tunnel to a target server or another relay (see Figure 1). However, it establishes an encrypted connection to a relay, or so-called MASK server, using QUIC as the tunnel transport, and then forwards traffic through that tunnel to a target server or another relay.
Currently, the most recent example of such services being rolled out is Apple’s new private relay service, which is in beta testing for iCloud+ users. When enabled, Private Relay uses both the MASK and Oblivious DNS protocols for Web traffic emitted by Safari, and for all DNS traffic.
In either case, user traffic for a web server or DNS resolver is encrypted and then first sent to a relay service that knows the user’s identity and IP address but does not see the user’s request. user itself. This relay service then forwards the encrypted traffic to another relay, which can determine where to forward the end-to-end encrypted service request, but does not know the user’s identity or IP address.
Although this approach seems simple, it is a substantial shift in communication patterns. Instead of sending traffic directly to a service, essentially all user traffic is routed to the same small set of intermediaries, and traffic received at the target server also comes from a more limited set of entities. This significantly changes the way traffic flows and is observed in networks, as well as for application service providers. Therefore, the large-scale deployment of these types of services will have an impact on the way we manage our networks.
Share the right data with the right entity
Without relay services, traffic effectively broadcasts information in the clear to potentially unknown third parties who may eavesdrop on the path, especially when the transport information is not otherwise encrypted. Tunnels between selected relays can allow users to control data and metadata that could reveal privacy-sensitive information. An example is usage patterns and details of accessible services that can reveal whether or not a user is home to anyone who passively enters the network path. The challenge is to ensure that the right data, and only the right data, is shared with the right entity. Ideally, users only share their identity with an entity with which they already have a trust relationship, such as the access network provider or the service provider. A setup like this is more complicated than what we have today and may make some of the network management techniques currently deployed more complex, but there are also opportunities for better collaboration between the network and, for example, the application to the endpoint.
Explicit trust relationships provide the basis for more targeted exchanges of information with intermediaries. Many network functions today – for example for performance tuning or zero rate – listen passively and attempt to derive useful data from what is revealed. However, the details of the information available may change at any time due to the continued deployment of encryption techniques, general protocol evolution and new services such as Private Relay, or simply due to a change in the behavior of the ‘application. Requesting explicit information from a relay service instead, or from an endpoint relay, provides better guarantees that the information is correct and useful and will not suddenly drop if traffic changes due to encryption deployment or new end-to-end services. This last point might even be the most important.
Network management techniques deployed today often rely on information exposed by most traffic, but without any guarantee that this information is accurate. For example, the zero notation today often relies on the Service Name Identifier (SNI) in TLS. However, a simple technique like domain facade can bypass and thus “trick” the respective network control functions. In the future, the SNI will probably be encrypted and therefore no longer usable for a passive observer.
Use relays to avoid information ambiguity
Similar challenges exist for techniques such as TCP optimizers that provide protocol-specific performance improvements in the network for unencrypted traffic. These techniques are used today because they can be deployed by the network without collaboration or coordination with other entities, and as such they provide a relatively simple approach to improving performance under difficult network conditions. However, these techniques often rely on plaintext protocol information (eg, the TCP header) or even unencrypted application layer data. This type of traffic interception or manipulation has caused ossification of the protocol in the past and therefore can hinder the deployment of new protocol features. As the share of encrypted traffic increases (HTTPS and QUIC traffic), these techniques become less applicable. Instead, having an explicit collaboration between one or more endpoints and a relay in the network to exchange information explicitly avoids ossification of the protocol and ambiguity of the information provided.
Another example is parental controls, which today relies on DNS filtering and is therefore also one of the functions that service providers have indicated as being affected when using Private Relay. The example perfectly illustrates the main problem with this technique: it breaks easily if, for example, another DNS server is used, or if the information simply becomes better protected. Using explicit relays instead of a DNS-based solution to provide this function not only makes this service less prone to failures. It also provides an opportunity for improvements by involving the content provider, or a relay that acts on behalf of the content provider, and can therefore provide much better input into the content control decision itself.
Turning a Challenge into an Opportunity: Strengthening User Collaboration and Privacy
Finally, the cases described above show that there is also an opportunity in this change. While adding relays seems technically more complex, trading relationships can become simpler. Whenever collaboration with a network service provider or content provider is required, this may also be mandated by the relay hosting provider, and therefore a potentially much smaller set of entities to cooperate with. In particular, it is an opportunity for mobile network operators to establish new well-defined and hopefully easier business relationships.
The deployment of relay-based services will indeed change the communication pattern and traffic flows on the Internet. Instead of direct communication between two parties that is observable by all elements in the path, intermediaries will be involved, and only limited information will be distributed to an explicitly selected set of trusted parties. However, given the importance of the Internet, greater control of privacy by users is long overdue and explicit collaboration between these parties could be the key to better networked support of new services. and emerging. Now is a good time to focus our work on these new communication models and make the most of emerging technologies for network collaboration!
Learn more about network security solutions from Ericsson
Learn more about our network services, tailored to today’s changing needs
Discover the benefits of network security automation
Listen: Why 5G is the most secure platform, with our Director of Product Security