If you walk down the street of a big city, people will frequently ask you for directions. When asked for directions, we learn secrets about those seeking locations:
- Where is Boston Public Library → the person likes to read
- Where is Starbucks → the person will likely be quaffing café soon
- Where is the Four Seasons → the person is likely rich
While our conclusions are not always correct, we do indeed learn by directing strangers.
DNS monitoring reveals your network usage.
The Domain Name System (DNS) provides directions to locations on the internet. The system takes a human readable location (called a Uniform Resource Locator or URL) and returns the best IP address (network location) to connect to. Every time you enter a website directly, or indirectly through clicking a link, your DNS provider learns something about you. Approximately 78% of all DNS requests today are unencrypted in the United States which shares information with the networks you are using. So if you google and click on a link for “Diet pills” at work, it’s possible your local IT staff may learn something about you.
Currently, it can be very difficult to determine by IP address what specific website is requested.
When the Internet was small, each web site had a unique IP address. This meant that the IP address would reveal your destination like zip codes on a letter. Over time, websites started to share IP addresses and used actual request information for routing instead. Additionally, web caching sites delivered content on behalf of a large number of websites.
A DNS eavesdropper can still easily know what encrypted websites you are accessing.
Any credible Internet service today is encrypted. The unencrypted sites that remain are not safe to use, and popular browsers warn their users to avoid these. Many internal corporate services remain unencrypted for now, but will likely be encrypted. When a service is encrypted, the request information is not available to anyone that does not contain the “key” making the information private. But as stated earlier, 78% of our DNS requests are still open for eavesdroppers to listen on. So a DNS eavesdropper can still easily know what encrypted websites you are accessing.
End users can select and control their DNS servers, allowing users to select their DNS provider.
There are security services that are sold today whereby companies direct all DNS requests to a special server that knows about pornography, ad trackers, and other questionable sites, and simply redirects these requests to a web server indicating a policy violation. In the battle for “free/unhindered access”, many have learned it might be better to go into the network settings of your computer and force the DNS server to be a public DNS server from Google. Most of us accept that it’s better to let Google know our secrets than our company or carrier.
Outbound proxies provide 100% access to all Internet usage and personal information.
In the never-ending battle for everybody to know your secrets, companies today frequently utilize security proxies (TLS Man-in-the-middle). Most people don’t realize this, but every single activity that a user of the Internet does is 100% observable by these security proxies even when encryption is being used. So your browser gives you a “green” good to go signal when you access your on-line bank, but a proxy in the middle can observe ALL of your behavior. Companies argue they have the right to this information, and they need to protect their assets. To prevent corporate eavesdropping many banks and websites encourage mobile device access. To overcome this, many companies use Mobile Device Management software to insert their security proxies onto these mobile devices as well.
Outbound proxies can and do interfere with end-to-end security associations and real time performance for multi-media.
Network professionals have sought for years to find a way to apply policy without being a full outbound proxy. The outbound proxies are detectible by the cloud service, and frequently discouraged. Microsoft and Google have both written best current practices for connectivity that actively argue against outbound proxies.
SNI allows security policies to be applied without violating any more of your privacy than required.
An alternative mechanism for applying policy is the Service Name Indication. For encrypted traffic, a field called Service Name Indication was introduced in 2003 in the standard for encryption (TLS). All popular web browsers immediately supported it (despite it being labled “optional”) and in today’s networks, in the third packet (a TLS Client Hello) is a clearly visible URL. Sophisticated DPI equipment now can harvest information about your web usage by scraping the 3rd packet of any secured web request. This is how application fingerprinting is being performed today. Firewalls, and security IPS/DPI devices, and SD-WAN routers can retrieve this information to properly route and provide QoS for well known services. Blocking access to pornography, and other undesirable web sites can also be performed efficiently with SNI processing.
The SNI information has other benefits as well. The SNI information is used to determine which specific web server or cache a request should be routed to. It can also be used to determine the correct keys for a security association when using shared equipment. Thus this information is used for efficient edge routing at data centers. Its efficient because its plain text.
There is now work underway at the IETF to make SNI information private.
For the 22% of people using secure DNS, they could further cloak their request through encrypting the SNI field in the third packet. This would eliminate the ability for corporate firewalls, and network equipment from learning what specific website you are attempting to access. For the other 78% of us not using DNSSEC, we would get no benefit. There is of course a need for privacy, but I fear encryption of SNI will result in an increase of outbound proxies. This is clearly a case of which evil is greater. Companies that have policies about Internet usage, and want to enforce the rules will be forced to use much more expensive outbound proxies (Application Layer Firewalls) and disregard Microsoft’s recommendations for connectivity. This may result in higher costs, and less performant multi-media cloud services.
Does network equipment need service information?
Most people want the network to be responsive to applications. To make voice, and video co-exist with data. To have backups operate on spare bandwidth only, never interfering with real time client/server data flows. Everybody wants the network to be more secure. We all want to understand what the network is being used for. IT professionals want to assess vulnerabilities and behavior in real time. And at the same time, every user has rights to privacy of their personal information.
To answer this question, we must look at the future of the network. It is reasonable to believe that at some point, IPv6 will be the addressing scheme in use, and IPv4 will be deprecated. While this never seemed likely before, it is clearly possible now. A large portion of the Internet is already taking advantage of IPv6, and many corporations are switching their internal networks and data centers to IPv6. The impact of IPv6 is that each and every service can once again have its own unique address. The SNI field may no longer be required, and reverse DNS may be sufficient for identifying applications and applying policies. ACLs based on IP addresses would begin to work again. But most important in relation to privacy is that with IPv6 privacy by address obfuscation will no longer be available.
Today, your network knows what web sites you use, because your network gives you directions to get there. IPv4 addresses alone do not provide enough information to understand network usage. Service Name Indication provides a way to understand network usage today, but in the future this field may be encrypted, resulting in a full outbound proxy as the only technical tool available to understand network use and apply policy. Ultimately, when IPv4 is deprecated, we may return to an Internet where each unique service has a unique IP address. This will allow full policy application and forward/backward translation of IP addresses to services. Given all of the above is true, I would suggest leaving the SNI field unencrypted as it is a far lesser evil than outbound proxies.
 RFC 3546 superceded by RFC 4366