[ad_1]
Over the past few years, several measures have been taken to strengthen user security and privacy on the Internet. Focusing on methods that have been developed and implemented to prevent inadvertent access and manipulation of communications by third parties. One example is the large-scale deployment of HTTPS to provide encrypted communication for accessing web content. Efforts to deploy new protocols that encrypt related data, such as 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 which services have been requested.
Recently, attention has been focused on various mechanisms that improve user privacy by hiding 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 counterintuitive to involve one more party in the communication process to protect user privacy, the logic behind using relays is that ultimately each party can only access a limited set of information, and therefore each party knows less. than before
These relay services specifically aim to separate two important pieces of information: information about the identity of the person accessing the service is separated from information about the service being accessed. This requires two levels of encryption.
Relay services in practice
Simple VPN services only add one layer of encryption to communication between the client and in VPN server: the VPN server can still see what services are available being access, and by whom At the Internet Engineering and Technical Group (IETF), the leading standardization body for Internet technologies, most activities related to these information sharing purposes are denoted by the term Oblivious, but there is also MASQUE (Multiplexed application substrate through QUIC encryption) and a new group called PPM (Privacy Preserving Measurements), which applies this communication pattern to various use cases.
MASQUE is a new IETF working group that extends HTTP CONNECT to initiate and manage the use of QUIC-based relays. Learn about the history of QUIC and MASQUE in our previous blog posts. MASQUE is a tunnel-based approach similar to VPN services. However, it establishes an encrypted connection to a relay or so-called MASQUE server, using QUIC as the tunnel transport, and then forwards the traffic through that tunnel to the target server or another relay (see Figure 1).
Figure 1: Setup with two MASQUE proxies, for example hosted by a Mobile Network Operator (MNO) and a Content Delivery Network (CDN).
Currently, the latest example of the deployment of such services is Apple’s new Private Relay service, which is in beta testing for iCloud+ users. When enabled, Private Relay uses DNS MASQUE and Oblivious protocols for web traffic sent by Safari and for all DNS traffic.
In both cases, the user’s traffic to either the web server or the 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 itself. This relay service then forwards the encrypted traffic to another relay, which can determine where to forward the service’s end-to-end encrypted request, but does not know the user’s identity or IP address.
Figure 2. Setting up Apple’s private repeater. Only the inbound proxy can see the client’s IP address, and only the outbound proxy knows the destination server name.
Figure 3. Using inbound and outbound proxies to provide Oblivious DNS over HTTP (DoH)
Although this approach seems simple, it significantly changes communication patterns. Instead of sending traffic directly to the service, essentially all user traffic goes 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 and for application service providers. So, deploying this kind of service at scale will have an impact on how we manage our networks.
Exchange the right data with the right organization
Without relay services, traffic effectively broadcasts information in the clear to potentially unknown third parties who can eavesdrop along the way, especially if the transport information is not otherwise encrypted. Tunnels between selected relays can provide users with control over data and metadata that may reveal sensitive information. Examples include usage patterns and details of available services, which can reveal whether a user is at home or not to anyone passively enumerating the network path. The challenge is to ensure that the right data, and only the right data, is provided to the right organization. Ideally, users will only disclose their identity to an organization with which they already have a trusted relationship, such as an access network provider or service provider. This setup is more complex than what we have today and may complicate some of the network management techniques currently deployed, but there are also opportunities for better collaboration between the network and, say, an application at the endpoint.
An explicit relationship of trust provides the basis for a more targeted exchange of information with intermediaries. Today, many network functions – for performance optimization or zero-rating, for example – passively listen and try to extract useful data from what is exposed. However, the details of the available information may change at any time due to the ongoing deployment of encryption methods, general protocol evolution and new services such as Private Relay, or simply due to changes in application behavior. Requesting explicit information from a relay service instead or relay from an endpoint provides better guarantees that the information is correct and useful and will not be suddenly broken if traffic changes due to the deployment of encryption or new end-to-end services. The last point may be even more important.
Current network management methods often rely on information that is exposed to most of the traffic, but without any guarantees of the accuracy of the information. For example, zero rating today often depends on the Service Name Identifier (SNI) in TLS. However, such a simple technique as domain fronting can bypass the relevant network control functions and thereby “cheat”. In the future, SNI will likely be encrypted and therefore no longer used for a passive observer.
Use of repeaters to avoid ambiguity of information
Similar problems exist for techniques such as TCP optimizers that provide network performance improvements for unencrypted traffic. These techniques are used today because they can be deployed in a network without cooperation or coordination with other entities, and as such provide a relatively simple approach to improving performance in complex network environments. However, these methods often rely on plaintext information from the protocol (such as the TCP header) or even unencrypted application layer data. Such traffic interception or traffic manipulation has in the past caused the protocol to become rigid, and therefore may prevent the deployment of new protocol features. As the proportion of encrypted traffic (HTTPS and QUIC traffic) increases further, these methods are less applicable. Instead, having an explicit cooperation between one or more endpoints and a network relay to exchange information clearly avoids the ossification of the protocol and the ambiguity of the information provided.
Another example is parental controls, which today are based on DNS filtering and are therefore also one of the features that service providers have indicated are affected by the use of Private Relay. The example perfectly illustrates the main problem of this technique: it is easily broken if, for example, a different DNS server is used, or the information simply becomes better protected. Using explicit relays instead of a DNS-based solution to provide this functionality not only makes this service less prone to failure. It also provides an opportunity for improvement by involving a content provider or a relay acting on behalf of the content provider and therefore can provide much better information as input to the content management solution itself.
Turning a challenge into an opportunity: Empowering user collaboration and privacy
Finally, the cases described above show that this change is also possible. Although adding a relay seems technically more difficult, the business relationship can become simpler. Whenever collaboration is required with a network service provider or content provider, it may also be a proxy for the relay hosting provider, and thus potentially a much smaller pool of organizations to collaborate with. This is especially a chance for mobile network operators to establish new, clearly defined business relationships, and hopefully easier.
The deployment of relay-based services will truly change the communication structure and traffic flows of the Internet. Instead of a direct link between two parties that is observed by all elements along the path, intermediate links will be involved and only limited information will be disseminated to a carefully selected set of trusted parties. However, given the importance of the Internet, the need for greater control over user privacy is long overdue, and clear collaboration between these parties could be the key to better supporting new and emerging services online. Now is the time to focus our work on these new communication patterns and make the best use of new technologies for networked collaboration!
Learn more
Learn more about Ericsson solutions for network security
Learn more about our network services that meet today’s changing needs
Learn about the benefits of network security automation
Hear: Why 5G is the safest platform, with our Chief Product Security Officer
[ad_2]
Source link
