Category: Privacy

2019 Resolution #2: Blocking Online Trackers

Lorin Olsen
The Myth of Online Privacy
The Myth of Online Privacy
Background

Welcome to the New Year. This year could be a banner year in the fight to ensure our online privacy. Before now, the tools of surveillance have overwhelmed the tools of privacy. And the perceived need for new Internet content has outweighed the real difficulty of protecting your online privacy. For years, privacy advocates (including myself) have chanted the mantra of exploiting public key encryption. We have told people to use Tor or a commercial VPN. And we have told people to start using two-factor authentication. But we have downplayed the importance of blocking online trackers. Yes, security and privacy advocates did this for themselves. But most did not routinely recommend this as a first step in protecting the privacy of our clients.

But the times are changing.

Last year (2018) was a pivotal time in the struggle between surveillance and privacy. The constant reporting of online hacks has risen to a deafening roar. And worse still, we saw the shepherds of our ‘trusted platforms’ go under the microscope. Whether it was Sundar Pichai of Google or Mark Zuckerberg of Facebook, we have seen tech leaders (and their technologies) revealed as base – and ultimately self-serving. Until last year, few of us realized that if we don’t pay for a service, then we are the product that the service owners are selling. But our eyes have now been pried open.

Encryption Is Necessary

Security professionals were right to trumpet the need for encryption. Whether you are sending an email to your grandmother or inquiring about the financial assets that you’ve placed into a banker’s hands, it is not safe to send anything in clear text. Think of it this way. Would you put your tax filing on a postcard so that the mail man – and every person and camera between you and the IRS – could see your financial details? Of course you wouldn’t. You’d seal it in an envelope. You might even hand deliver it to an IRS office. Or more recently, you might send your return electronically – with security protections in place to protect key details of your financial details.

But these kinds of protections are only partial steps. Yes, your information is secure from when it leaves your hands to when it enters the hands of the intended recipient. But what happens when the recipient gets your package of information?

Encryption Is Not Enough

Do the recipients just have your ‘package’ of data or do they have more? As all of us have learned, they most certainly have far more information. Yes, our ISP (i.e., the mail man) has no idea about the message. But what happens when the recipient at the other end of the pipe gets your envelope? They see the postmarks. They see the address. But they could also lift fingerprints from the envelope. And they can use this data. At the same time, by revealing your identity, you have provided the recipient with critical data that could be used to profile you, your friends and family, and even your purchasing habits.

So your safety hinges upon whether you trust the recipients to not disclose key personal information. But here’s the rub. You’ve made a contract with the recipient whereby they can use any and all of your personally identifiable information (PII) for any purpose that they choose. And as we have learned, many companies use this information in hideous way.

Resist Becoming The Product

This will be hard for many people to hear: If you’re not paying for a service, then you shouldn’t be surprised when the service provider monetizes any and all information that you have willingly shared with them. GMail is a great service – paid for with you, your metadata, and every bit of content that you put into your messages. Facebook is phenomenal. But don’t be surprised when MarkeyZ sells you out.

Because of the lessons that I’ve learned in 2018, I’m starting a renewed push towards improving my privacy. Up until now, I’ve focused on security. I’ve used a commercial VPN and/or Tor to protect myself from ISP eavesdropping. I’ve built VPN servers for all of my clients. I’ve implemented two-factor authentication for as many of my logons as my service providers will support.

Crank It Up To Eleven

And now I have to step up my game.

  1. I must delete all of my social media accounts. That will be fairly simple as I’ve already gotten rid of Facebook/Instagram, Pinterest, and Twitter. Just a few more to go. I’m still debating about LinkedIn. I do pay for premium services. But I also know that Microsoft is selling my identity. For the moment, I will keep LinkedIn as it is my best vehicle for professional interactions.
  2. I may add a Facebook account for the business. Since many customers are on Facebook, I don’t want to abandon potential customers. But I will strictly separate my public business identity/presence from my personal identity/presence.
  3. I need to get off of Gmail. This one will be tougher than the first item. Most of my contacts know me from my GMail address (which I’ve used for over fifteen years). But I’ve already created two new email addresses (one for the business and one on ProtonMail). My current plan is to move completely off of GMail by the end of 1Q19.
  4. I am going to exclusively use secure browsing for almost everything. I’ve used ad-blockers for both the browser and for DNS. And I’ve used specific Firefox extensions for almost all other browsing activities that I have done. I will now try and exclusively use the Tor Browser on a virtual machine (i.e., Whonix) and implement NoScript wherever I use that browser. Let’s hope that these things will really reduce my vulnerability on the Internet. I suspect that I will find some sites that just won’t work with Tor (or with NoScript). When I find such sites, I’ll have to intentionally choose whether to use the site unprotected or set up a sandbox (and virtual identities) whenever I use these sites. Either way, I will run such sites from a VM – just to limit my exposure.
  5. I will block online trackers by default. Firefox helps. NoScript also helps. But I will start routinely using Privacy Badger and uMatrix as well.
Bottom Line

In the final analysis, I am sure that there are some compromises that I will need to make. Changing my posture from trust to distrust and blocking all online trackers will be the hardest – and most rewarding – step that I can make towards protecting my privacy.

Continuous Privacy Improvement

Lorin Olsen
In its latest release, Firefox extends its privacy advantage over other browsers. Their efforts at continuous privacy improvement may keep you ahead of those who wish to exploit you.
Firefox 63 Extends Privacy Lead

In the era of Demmings, the mantra was continuous process improvement. The imperative to remain current and always improve continues even to this day. And as of this morning, the Mozilla team has demonstrated its commitment to continuous privacy improvement; the release of Firefox 63 is continuing the commitment of the entire open source community to the principle that Internet access is universal and should be unencumbered.

Nothing New…But Now Universally Available

I’ve been using the new browsing engine (in the form of Firefox Quantum) for quite some time. This new engine is an incremental improvement upon previous rendering engines. In particular, those who enabled tracker protection often had to deal with web sites that would not render very successfully. It then became a trade-off between privacy and functionality.

But now that the main code branch has incorporated the new engine, there is more control over tracker protection. And this control will allow those who are concerned about privacy to still use some core sites on the web. This new capability is not fully matured. But in its current form, many new users can start to implement protection from trackers.

Beyond Rendering

But my efforts at continuous privacy improvement are also including enhanced filtering from my Pi-hole DNS platforms. The Pi-hole has faithfully blocked ads for several years. But I’ve decided to up the ante a bit.

  1. I decided to add regular expressions to increase the coverage of ad blocking. I added the following regex filters:
         
         ^(.+[-_.])??ad[sxv]?[0-9]*[-_.]
         ^adim(age|g)s?[0-9]*[-_.]
         ^adse?rv(e(rs?)?|ices?)?[0-9]*[-.]
         ^adtrack(er|ing)?[0-9]*[-.]
         ^advert(s|is(ing|ements?))?[0-9]*[-_.]
         ^aff(iliat(es?|ion))?[-.]
         ^analytics?[-.]
         ^banners?[-.]
         ^beacons?[0-9]*[-.]
         ^clicks?[-.]
         ^count(ers?)?[0-9]*[-.]
         ^pixels?[-.]
         ^stat(s|istics)?[0-9]*[-.]
         ^telemetry[-.]
         ^track(ers?|ing)?[0-9]*[-.]
         ^traff(ic)?[-.]
    2.      
  2. My wife really desires to access some sites that are more “relaxed” in their attitude. Consequently, I set her devices to use the Cloudfare DNS servers (i.e., 1.1.1.1, and 1.0.0.1). I then added firewall rules to block all Google DNS access. This should allow me to bypass ads embedded in Google devices that configure Goggle’s DNS (e.g., Chromecast, Google Home, etc). I then added these rules to my router.

         iptables -I FORWARD –destination 8.8.8.8 -j REJECT
         iptables -I FORWARD –destination 8.8.4.4 -j REJECT

These updates now block ads on my Roku devices and on my Chromecast devices.

Bottom Line

In the fight to ensure your privacy, it is not enough to “fire and forget” with a fixed set of tools. Instead, you must always be prepared to improve your situation. After all, advertisers and identity thieves are always trying to improve their reach into your wallet. Show them who the real boss is. It should be (and can be) you!

Social Media Schisms Erupt

Lorin Olsen

A funny thing happened on the way to the Internet: social media schisms are once again starting to emerge. When I first used the Internet, there was no such thing as “social  media”. If you were a defense contractor, a researcher at a university, or part of the telecommunications industry, then you might have been invited to participate in the early versions of the Internet. Since then, we have all seen early email systems give way to bulletin boards, Usenet newsgroups, and early commercial offerings (like CompuServe, Prodigy, and AOL). These systems  then gave way to web servers in the mid-nineties.  And by the late nineties, web-based interactions began to flourish – and predominate.

History Repeats Itself

Twenty years ago, people began to switch from AOL to services like MySpace. And just after the turning of the millennium, services like Twitter began to emerge. At the same time, Facebook nudged its way from a collegiate dating site to a full-fledged friendship engine and social media platform. With each new turning of the wheel of innovation, the old has been vanquished by the “new and shiny” stuff.  It has always taken a lot of time for everyone to hop onto the new and shiny from the old and rusty. But each iteration brought something special.

And so the current social media title holders are entrenched. And the problem with their interaction model has been revealed. In the case of Facebook and Twitter, their centralized model may very well be their downfall. By having one central system, there is only one drawbridge for vandals to breach. And while there are walls that ostensibly protect you, there is also a royal guard that watches everything that you do while within the walls. Indeed, the castle/fortress model is a tempting target for enemies (and “friends”) to exploit.

Facebook (and Twitter) Are Overdue

The real question that we must all face is not if Facebook and Twitter will be replaced, but when will it happen. As frustration has grown with these insecure and exposed platforms, many people are looking for an altogether new collaboration model. And since centralized systems are failing us, many are looking at decentralized systems.

A few such tools have begun to emerge. Over the past few years, tools like Slack are starting to replace the team/corporate systems of a decade ago (e.g., Atlassian Jira and Confluence). For some, Slack is now their primary collaboration engine. And for the developers and gamers among us, tools like Discord are gaining notoriety – and membership.

Social Media Schisms Are Personal

But what of Twitter and what of Facebook?  Like many, I’ve tried to live in these walled gardens. I’ve already switched to secure clients. I’ve used containers and proxies to access these tools. And I have kept ahead of the wave of insecurity – so far. But the cost (and risk) is starting to become too great. Last week, Facebook revealed that it had been breached – again. And with that last revelation, I decided to take a Facebook break.

My current break will be at least two weeks. But it will possibly be forever. That is because the cost and risk of these centralized systems is becoming higher than the convenience that these services provide.  I suspect that many of you may find yourselves in the same position.

Of course, a break does not necessarily mean withdrawal from all social media. In fairness, these platforms do provide value. But the social media schisms have to end. I can’t tolerate the politics of some of my friends. But they remain my friends (and my family) despite policy differences that we may have. But I want to have a way of engaging in vigorous debate with some folks while maintaining collegiality and a pacific mindset while dealing with others.

So I’m moving on to a decentralized model. I’ve started a Slack community for my family. My adult kids are having difficulty engaging in even one more platform. But I’m hopeful that they will start to engage. And I’ve just set up a Mastodon account (@cyclingroo@mastodon.cloud) as a Twitter “alternative”. And I’m becoming even more active in Discord (for things like the Home Assistant community).

All of these tools are challengers to Facebook/Twitter. And their interaction model is decentralized. So they are innately more secure (and less of a targeted threat). The biggest trouble with these systems is establishing and maintaining an inter-linked directory.

A Case for Public Meta-directories

In a strange way, I am back to where I was twenty years ago. In the late nineties, my employer had many email systems and many directories. So we built a directory of directories. Our first efforts were email-based hub-and-spoke directories based upon X.500. And then we moved to Zoomit’s Via product (which was later acquired by Microsoft). [Note: After purchase, Microsoft starved the product until no one wanted its outdated technologies.] These tools served one key purpose: they provided a means of linking all directories together

Today, this is all  done through import tools that any user can employ to build personalized contact lists. But as more people move to more and different platforms, the need for a distributed meta–directory has been revealed. We really do need a public white pages model for all users on any platform.

Bottom Line

The value of a directory of directories (i.e., a meta-directory) still exists. And when we move from centralized to decentralized social media systems, the imperative of such directory services becomes even more apparent. At this time, early adopters should already be using tools like Slack, Discord, and even Mastodon. But until interoperability technologies (like meta-directories) become more ubiquitous, either you will have to deal with the hassle of building your own directory or you will have to accept the insecurity inherent in a centralized system.

Home Automation “Quest for Fire”

Lorin Olsen
Home-Automation-Diagram
Home Automation

This weekend, we took another step in our home automation quest. We have used smart switches (for lamps), smart thermostats, smart music, smart cars, and even smart timers. But until Saturday, we did not have any smart lights, per se. On Saturday, we bought some Philips Hue lights (and the associated hub). That means that we now have Ethernet (i.e., wired) devices, Wifi devices, and now Zigbee devices.

Is this a big deal? The answer to that is somewhat nuanced. We’ve had smart home puzzle pieces for a while. And we almost bought a Z-Wave infrastructure to put smart switches in place. But the age of our house makes this impractical. [We don’t have neutral wires on any switches in the house. And the price to refurbish these switches would be prohibitive.]  So our home automation quest stalled. But on Saturday, I could take it no more. When we went out on errands, we stopped and picked up five (5) Hue lights.

Just Add Lights

The installation and setup was simple. It took almost no time to get everything installed and paired. And within a little more than an hour, we had functioning lights in the second floor hallway and in our master bedroom.  Over the next year, we can start to populate the various ceiling fans in the house. I figure that we can do this whenever we need to replace the incandescent bulbs that are currently installed. Given our current pace of replacement, I’m figuring that it will take a year or so to retrofit the house.

After getting everything installed, I started to make an inventory of our various smart home investments. As of today, we have the following pieces:

Current “On-Premises” Infrastructure

Today, we have so many physical (and logical) pieces in our home automation puzzle:

  • Network: Cisco network switch, Cisco VPN appliance, Netgear router, NordVPN proxy, Raspberry Pi ad blocking, Raspberry Pi DNS
  • Print: Hewlett-Packard printer
  • Entertainment: Plex media server (on PC desktop), Roku media player, Samsung TV, Silicon Dust HDHomeRun player
  • Storage: Synology storage, WD MyCloud storage
  • IoT: Amazon Echo Dot speakers, Huawei sensor/camera (on surplus phone), Kia Soul, Personal location / presence (on personal phones), Philips Hue lights, Raspberry Pi home automation appliance, TP-Link Kasa switches, WeightGURUS scale

Current “Off-Premises” Services

While we have lots of smart pieces in the house, we also have more than a few external cloud services providers. In most of these cases, these services allow us to extend “access” beyond the confines of our network. Our current list of services includes:

  • Lobostrategies Business: Bluehost, GoDaddy
  • Olsen Personal: Amazon Alexa, Dropbox, Google Drive, Google GMail, Home Assistant cloud, IFTTT cloud, Plex cloud, Pushbullet cloud, TP-Link Kasa cloud, WD MyCloud

So after adding yet another home automation “category” to the premises, we learned an important lesson: external access requires a measure of trust – and diligence. If you aren’t willing to secure your devices, then you must accept the consequences of an electronic intrusion.

Browser Security Bypasses Abound

Lorin Olsen
browser security at risk
Browser Security At Risk

Browser Security Threats Discovered

According to the Catholic University of Leuven in Belgium (KU), every modern browser is susceptible to at least one method of bypassing browser security and user privacy.  In an article on the subject, Catalin Cimpanu (of BleepingComputer) reported that new (and as yet unexploited) means of bypassing cookie controls are apparently possible.  KU researchers reported their findings to the browser developers and posted their results at wholeftopenthecookierjar.eu.

Don’t expect all browser vendors to solve all browser security issues immediately. Indeed, expect many people to howl about how these vulnerabilities were reported. But regardless of the manner in which the news was delivered, every customer must take it upon themselves to implement multiple layers of protection. A comprehensive approach should (at a minimum) include:

  1.  A safe browser,
  2. Safe add-ons (or extensions) that include cookie and browser element management (e.g., uBlock Origins, NoScript, and uMatrix)
  3. A means of reducing (and possibly eliminating) Javascript, and
  4. Effective blocking of “well-known” malware domains.
Bottom Line

Shrek was right.  Ogres are like onions – and so is security. Effective security must include multiple layers. Be an ogre; use layers of security

Browser Security: Who Do You Trust?

Lorin Olsen
Browser Security Defended by Mozilla

So you think that you are safe. After all, you use large, complex, and unique passwords everywhere. You employ a strong password safe/vault to make sure that your passwords are “strong” – and that they are safe. At the same time, you rely upon multi-factor authentication to prove that you are who you say that you are. Similarly, you use a virtual private network (VPN) whenever you connect to an unknown network. Finally, you are confident in your browser security since you use the “safest” browser on the market.

Background

Historically, geeks and security wonks have preferred Mozilla Firefox. That’s not just because it is open source. After all Google Chrome is open source. It’s because Firefox has a well-deserved reputation for building a browser that is divorced from an advertising-based revenue stream. Basically, Firefox is not trying to monetize the browser. Unlike Chrome (Google) and Edge (Microsoft), Firefox doesn’t have an advertising network that must be “preferred” in the browser. Nor does Firefox need to support ‘big players’ because they are part of a business arrangement. Consequently, Firefox has earned its reputation for protecting your privacy.

But as Robert “Bobby” Hood has noted, the browser that you choose may not make much difference in your browser security posture. He wrote more bluntly; he said, “[Browser difference] …doesn’t matter as much as you may think… Is it important which browser we use? Sure, but with a caveat. Our behavior is far more important than nitpicking security features and vulnerabilities.” He is right. There are far more effective means of improving security and ensuring privacy. And the most important things are your personal practices. Bobby said it best: “Would you park your Maserati in a bad part of town and say, ‘It’s okay. The doors are locked!’ No. Because door locks and alarm systems don’t matter if you do dumb things with your car.”

What Have You Done For Me Lately?

It is always good to see when one of the browser creators takes positive steps to improve the security of their product. On August 16th, Catalin Cimpanu highlighted the recent (and extraordinary) steps taken by Mozilla. In his article on BleepingComputer (entitled “Mozilla Removes 23 Firefox Add-Ons That Snooped on Users”), he highlighted the extraordinary steps take by Mozilla’s addons.mozilla.org (AMO) team. In particular, they researched hundreds of add-ons and they determined that twenty-three (23) of them needed to be eliminated from AMO. Mozilla removed the following browser plugins from AMO [Note: These include (but aren’t limited to…]:

  • Web Security
  • Browser Security
  • Browser Privacy
  • Browser Safety
  • YouTube Download & Adblocker Smarttube
  • Popup-Blocker
  • Facebook Bookmark Manager
  • Facebook Video Downloader
  • YouTube MP3 Converter & Download
  • Simply Search
  • Smarttube – Extreme
  • Self Destroying Cookies
  • Popup Blocker Pro
  • YouTube – Adblock
  • Auto Destroy Cookies
  • Amazon Quick Search
  • YouTube Adblocker
  • Video Downloader
  • Google NoTrack
  • Quick AMZ

Mozilla also took the extraordinary step of ‘disabling’ these add-ons for users who had already installed them. While I might quibble with such an ‘authoritarian’ practice, I totally understand why Mozilla took all of these actions. Indeed, you could argue that these steps are no different than the steps that Apple has taken to secure its App Store.

Bottom Line

In the final analysis, browser security is determined by the operation of the entire ecosystem. And since very few of us put a sniffer on the network whenever we install a plugin, we are forced to “trust” that these add-ons perform as documented. So if your overall browser security is based upon trust, then who do you trust to keep your systems secure? Will you trust companies that have a keen interest in securing ‘good’ data from you and your systems? Or will you trust someone who has no such vested interests?

DNS Security At The Edge

Lorin Olsen

DNS-Security-From-The-Edge
DNS Security From The Edge

In my third installment of this series about DNS security, I am focusing on how we can audit all DNS requests made in our network.  In the second installment, I focused on secure communications between DNS servers. And I highlighted the value of DNSSEC and the potential of DNS-Over-HTTPS (DOH). I outlined some of the changes that we’ve made – including the deployment of DNSMasqd on our router and on our Pi-hole. Today, I will focus upon ensuring that end-to-end auditing is possible – if desired.

As noted previously, we upgraded our router (i.e., a Netgear R8000 X6) from stock firmware to DD-WRT. We did this for numerous reasons. Chief among these reasons was the ability to set up an OpenVPN tunnel from our network out to our VPN providers’ VPN endpoints. But a close second was a desire to run DNSMasqd on the router. Since we haven’t chosen to move DHCP functions to the Pi, we wanted a DHCP service that would have better capabilities. More importantly, we wanted to update DHCP option #6 so that we could control what name servers our clients would use. In our case, we knew that all clients would use our Pi-hole as their name server.

After we realized that DNS options on the admin panel didn’t apply to DHCP clients, we figured out how to set name servers for all of our DHCP clients. Once done, all clients began direct interaction with the Pi-hole. [They had previously used the router as a DNS proxy to our Pi-hole system.]

But as is often the case, there were unforeseen consequences. Specifically, reverse lookups (for static address) failed. This meant that DNS security would suffer because we couldn’t correlate elements across the entire request chain. We could have moved dhcpd to the Pi-hole. But we wanted to have a DNS fall-back – just in case the Pi-hole failed. So we changed our processes for assigning static addresses. Now, we will add them to the router as well as to the /etc/hosts file on the Pi-hole. Once implemented, we had clear visibility between request origination and request fulfillment. [Note: We will probably turn this off as it defeats the very anonymity that we are trying to establish. But that is for another day.]

So what’s left?  In the first two articles, we set up DNS authentication wherever possible. We also established DNS payload encryption – using DNS-Over-HTTPS. Now we have a means of authenticating DNS server communications. And we have an encrypted payload. But there is one last need: we have to limit the ‘data at rest’ stored by each DNS resolver.

Consider this: If we validate our connection to Google, and we encrypt the traffic between us, then Google can still look at all of the DNS queries that it receives from us. That is fine if you trust your principal DNS resolver. But what if you don’t? A more secure process would be to ask for name resolution directly, rather than through a trusted (or un-trusted) intermediary. In my next article, I will discuss how we implemented a recursive DNS resolver alongside our Pi-hole. Specifically, I’ll talk about using Unbound to limit the amount of ‘data at rest’ that we leave with any single DNS service.

DNS Security Is A Necessary Key To Privacy

Lorin Olsen
DNS Security Is Not Too Expensive
Comparison of DNS Services


Yesterday, I wrote about how Mozilla is updating Firefox to improve DNS security. But my conclusion was that Mozilla may have designed a system with a single point of failure. In fairness, this assessment was far too simplistic. Today, I want to amplify on my thoughts.

The Firefox implementation assumes something that is probably false. It assumes that most people are using Firefox. It also assumes that all Firefox users can choose an appropriate resolver/referrer to meet their specific needs. I would argue that the first assumption is patently wrong while the second assumption is altogether naive. As noted yesterday, I would have much preferred that Mozilla be more transparent about their proposed changes. Also, rather than assume that the code is open and thus reviewed, Mozilla could have asked for more extensive input. [Note: I suspect that Mozilla was transparent with a somewhat limited community. I just wish that their design had been explicitly shared.]

The real problem that I have with their approach is that it is a Firefox-only solution. No, I don’t expect Mozilla to solve this problem for their competitors. But most organizations need a broader solution that will meet everyone’s needs. Enter dnsmasq. In my case, I have implemented DNS over HTTPS (DoH) as my mechanism to improve DNS security. 

I am quite fortunate: I am using a DNS server that was just updated. The Pi-hole team has just released Pi-Hole 4.0. And a DNS service provider (Cloudflare) has released an AMD and ARM DNS-over-HTTPS implementation. [Note: Their solution is in binary form. So I will add my voice to the chorus asking for the software to be published under a free/open license. Until that happens, I’m testing the system to see how it performs.]

So what am I seeing thus far?

After switching to cloudflared on Pi-hole 4.0, I ran some benchmarks. And as expected, there was quite a bit more activity on my DNS server. But the overall DNS response time (i.e., the server at 10.42.222.22) was quite acceptable. I want to get about a week’s worth of data. But at this moment, I am very hopeful that the software will maintain acceptable performance levels.

So what should you do? If you’re bold, then use a test system and try it out for yourself. Or keep close tabs on folks who are testing this technology. At the current time, I am thrilled to close down yet another vector of surveillance.
 

TRR = Totally Risky Referrer

Lorin Olsen

Totally-Risky-Resolver
TRR Is Anything But Trusted

When Homer Simpson says “doh”, you know that something stupid is about to happen. Unfortunately, I believe that the same thing is true about the upcoming Firefox feature called DNS over HTTPS (i.e., DOH). Developers at Firefox noted a real problem: DNS queries aren’t secure. This has been axiomatic for years. That’s why DNS developers created DNSSEC. But DNSSEC is taking forever to roll out. Consequently, the Firefox developers baked Trusted Recursive Resolver (TRR) into Firefox 61. [Note: TRR has been available since Firefox 60. But TRR will move from an experiment to a reality as Firefox 61 rolls out across the Internet.]

Background

One of the key design points of TRR is  the encapsulation of data in a secure transport mechanism. Theoretically, this will limit man-in-the-middle attacks that could compromise your browsing history (or redirect your browser altogether). Of course, theory is not always reality. Yes, SSL/TLS is more secure than plain text. But it is widely used. So it is burdened by the need to retain backward-compatibility. Nevertheless, it is more secure than plain text. And security conscious consumers can implement TRR even if their local DNS provider doesn’t currently offer DNSSEC.

Risk

So why is TRR so risky? That’s simple: Mozilla is implementing TRR with a single recommended resolver: Cloudflare. I don’t think that anyone has an axe to grind with Cloudflare. From all that I have read, Cloudflare has never used customer data exclusively for its own benefit. That’s not true for Google, or OpenDNS, or a lot of other DNS providers. Of course, Cloudflare is a relative newcomer. So their track record is limited. But the real issue is that Mozilla has designed a system with a single point of failure – and a single choke point for logging and control.

Mitigation

Fortunately, Mozilla has enabled changing the TRR mode and TRR URI. Unfortunately, it is currently managed only through the about:config interface. That’s fine for a technician. But it is a dreadful method for end users. I am hopeful that Mozilla will provide a better interface for users. And I certainly hope that it is implemented on an “opt-in” basis. If they don’t, then folks who use their own DNS (e.g., every Pi-hole user) or folks who specify a different public provider than Cloudflare (e.g., Google, OpenDNS, DNS.Watch, etc) will be forced to “touch” every workstation.

Bottom Line:

Is Firefox acting badly? Probably not. After all, they are trying to close a huge DNS hole that infrastructure providers have yet to close (i.e., DNSSEC). Nonetheless, their approach is ham-handed. Mozilla needs to be transparent with the why’s and when’s – and they need to trust their users to “do the right thing.”