Supporting Down Level Clients

 November 12, 2019: Apple finally released FIDO2 support in Safari. 

June 9, 2020: A review of several websites reveals that a number of them still block FIDO2 in Safari. 


On November 12 last year I thought that we finally would start seeing some adoption of FIDO2. However, this industry has a strange approach to protocol support. 7 months after Apple added FIDO2 support to Safari, AWS, Microsoft, and, yes, even GoDaddy, have code that blocks you from using FIDO2 security keys in Safari. 

However, while so many vendors still block support of modern security protocols, they still support old and outdated ones. For instance, all of them support TLS 1.0 and 1.1. The major browser vendors coordinated an announcement in 2018 that TLS 1.0 would be deprecated in their products in March 2020. This was hailed as a major precedent setting announcement at the time. However, less than 1% of the traffic in each of those browsers, even then, was over TLS 1.1 and 1.0. Microsoft claimed at the time that 99.28% of all connections in Edge were over TLS 1.2. This is not surprising. This is when the common browsers added support for TLS 1.2 (based on data from https://caniuse.com/#feat=tls1-2):

  • Safari - Support added in OS X 10.9, released in October 2013
  • Firefox - Default support added in Firefox 27, released in February 2014
  • Chrome - Support added in Chrome 22, released in September 2012
  • Internet Explorer (no longer supported) - Default support added in IE 11, October 2013
  • Edge - Always supported since original release in July 2015
  • Opera - Supported since Opera 16, released in August 2013

In other words, in the worst possible case scenario - Firefox - a customer that has updated their browser in the past six years can use TLS 1.2 without doing anything special. One wonders if we wouldn't do the customers who have not updated their browsers in that time a favor if we refused to serve them until they installed some patches.


This is extremely common in our industry. We are incredibly slow at adding new security features, and we make up for it by being even slower at deprecating old and vulnerable ones. 


Removing support for downlevel clients is frightening. Some organizations do not have very good tracking on what their customers are using, and those that do very often do not have tracking on what protocols and features those clients support. As a result, we do not have the data to make decisions on, and even when we do, at what point do we cut people off? In 2018 Microsoft reported that 99.28% of connections made in Edge were over TLS 1.2. Apple reported that 99.6% of connections in Safari were over TLS 1.2. Yet, they waited two years before they would remove support for the older protocols, and their websites STILL support these very old browsers. 

Companies need to develop predictable standards both for when to add support for new protocols, and for when to deprecate support for older ones. The usual argument for not adding support is that it simply isn't high enough priority. The customer centric point of view should be that we should support security protocols that help our customers protect themselves. Clearly, if we have to support millions of customers, and 2 of them would benefit, I can see the argument, but if, say 5% of customers could make use of the feature, that might be a good time to push it up the priority stack? 


Likewise, we need to set standards for when to deprecate features and protocols. My proposal is that we proceed down four steps:

  1. When we decide to deprecate it we make a public announcement that announces an expected sunset date.
  2. When less than 5% of customers need the feature we start warning those customers at the time of use.
  3. When less than 1% of customers need the feature we announce a 30-day sunset.
  4. After deprecation we navigate customers who are affected to an interstitial page that explains what happened and provides options for how to upgrade.

It is a fact of life in this industry that new features and protocols are introduced, and that eventually vulnerabilities are found in them and they become old protocols and features. As an industry, we need to own the responsibility for protecting our customers, which includes supporting modern security features and protocols and deprecating vulnerable ones. 

Comments

Popular posts from this blog

The Busy Executive's Guide to Personal Information Security, Part 2 of ?

MFA Post 7: Other Contact Mechanisms (Email, Phone,...)

Electric Car Charger Basics