Fix MAC Address Randomization
Visit Device Fingerprint & MAC Randomization for more details or Medium
Recent changes at Network and OS level by vendors like Apple, Google and Microsoft, are marking a trend of masking customer’s visibility on the network transport as much as possible — far more rigorously than in today’s state. These changes, which will be covered below, are marketed as means to create end-to-end user privacy, eliminating surveillance and censorship from threat actors on said transport.
De-facto, with the clear advantages of this important trend, comes a critical damage to ISP’s ability to supply security services for user networks and devices — as they rely on information extracted from data in transit.
In this paper, we will cover the three main upcoming changes that are soon to be standardized, and describe SAM’s strategy to overcome the challenges they bring, for us to continue providing our cutting edge technology from day-one of their deployment.
Trends in Transport Visibility
MAC Randomization
Although NIC devices still do have a static MAC Address for L2 communications (and that’s not going to change anytime soon), more and more OS vendors are implementing a functionality of software-level MAC randomization, which presents the LAN a fake MAC address upon connection. This feature makes the user untraceable across different networks, and of course removes the device manufacturer information from the address (Present in the first 3 bytes).
There are numerous ways to implement a feature as such. While Google Android is generating a new MAC address for each SSID the device is connected to, Apple chose for it’s IOS14 Beta 3 to generate a new address every 24hrs. In Beta 4 they’ve altered the functionality to act the same as in Android. Microsoft is also offering this feature in it’s Windows 10, with 24hrs enrollment, though it is disabled by default for now.
Needless to say, this feature is harmful for Service Providers on the transport — not only for security means, but also for provisioning and customer service. From an ISP’s point of view, a network with a random-MAC device is flooded with numerous addresses, all representing the same device. These addresses do not point out the device’s type anymore, and could not be aggregated to represent a single device without some advanced technological means. Because MAC addresses were used up until today as a strong identification key for a connected device, many security, provisioning and customer support applications will need a complete overhaul for them to keep functioning.
DoH
As of today, many public DNS servers like Google and Cloudflare are offering “DNS over HTTPS/TLS” or DoH support, meaning an encryption of DNS queries and responses over a TLS or HTTPS secure connection layer — an idea that was standardized at DNSSEC in the early 2000’s. In that way, a threat actor on the transport could not eavesdrop or intervene in the resolving process of services the user consumes. This is highly important against censorship for example, as many non-liberal states use DNS traffic to analyze a users ‘illegitimate behaviour’ and block it accordingly.
On the client side, the adoption rate of this feature is on the rise. both IOS and Android in its current versions offer a DoH client, meaning a user / service provider could easily configure the DNS queries to be made encrypted-only. On Windows 10, one can enable DoH via a dedicated Registry value.
The implications of a feature as such is obviously bad for security services that rely on the transport, for DNS queries are the main vector they have to analyze services consumed by a user. This is needed for features like safe browsing and DNS reputation, firewall policies, anomaly detection and parental controls. When DoH is applied, a security service as such needs to create a new way to extract and monitor the user’s activity.
ESNI
Following the need for user activity monitoring as mentioned above, service providers could extract the needed information from the connection to the encrypted service itself via a field named “Server Name Indication” or SNI, that is passed as cleartext at the start of the TLS handshake.
The purpose of this field is to indicate the server which certificate should be handed to the user during the handshake. The certificate has to correspond to the specific DNS address that was reached by the client — for the client’s browser is going to validate the server’s authenticity based on this DNS name. Because no pre-shared secrets are being held by both sides of the conversation, this field has to be unencrypted.
But no longer! A new mechanism called ESNI, brings the ability to encrypt this field, removing the last exposed feature for security services to monitor users activity. This is done via a public DNS record that holds a server’s public encryption key, that could be used by the customer upon connection to encrypt the SNI field. The server, which holds the corresponding private key, can decrypt the SNI field and extract the requested service name for the TLS connection.
In summary, implementing both DoH and ESNI eliminates user activity monitoring, both by ISPs and malicious actors. So how can we sustain quality security services in an age of complete user masking?
SAM Got You Covered
As a technology leader in the field of ISP security services, SAM has designed dedicated solutions to overcome the mentioned challenges without compromising on the features provided to the consumer.
To overcome MAC randomization, SAM maintains a highly sophisticated cloud fingerprinting service that relies on many features collected from a connected device by our software agent, and uses AI to aggregate a device’s identity — regardless of its MAC address. This feature is integrated through our entire security suite, allowing us to continue delivering features like Network Mapping and Control, Dynamic Firewall and Digital Wellbeing on randomised-devices.
As for the user activity monitoring challenge, it is important to note that the only client implementation that could limit us is when BOTH DoH and ESNI are activated. For that situation, SAM is creating a dedicated Secure DNS server for our consumers that could reside both in the cloud or on the router itself, allowing us to be exposed to DNS queries, while still offering DoH and ESNI support. This mechanism will allow us to continue offering our Safe Browsing and Firewall features without any compromise on the user’s security and privacy on the transport.
With the techniques mentioned above, SAM is prepared for this new era of user masking — allowing all of our clients to maintain their security and support services unharmed.
Visit Device Fingerprint & MAC Randomization for more details
Comments
Post a Comment