Endpoint

10/18/2017
11:00 AM
Guy Podjarny
Guy Podjarny
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

What's Next After HTTPS: A Fully Encrypted Web?

As the rate of HTTPS adoption grows faster by the day, it's only a matter of time before a majority of websites turn on SSL. Here's why.

HTTPS, the encrypted form of delivering websites, was slow to catch on. Over 20 years after its inception, it was still only used by roughly 1 in 20 websites, despite experts praising its security. This adoption finally started picking up speed in mid-2015, more than doubling, to reach 12% of the Web.

The rate of adoption is getting faster by the day. Data from BuiltWith marks adoption at 32.2% of the top 1 million websites, and the HTTP Archive shows 52% of the requests in the top 500,000 websites used HTTPS (up from 22% a mere two years back).

These are staggering numbers, and a huge security win. Even more impressive is the fact the adoption was not driven by compliance, which is the usual suspect when it comes to growing adoption of security controls. Unless you're communicating private data, none of the major regulations require the use of HTTPS. Instead, this was achieved by making it easier and cheaper to use HTTPS — and making it more costly not to.

On the ease-of-use side, we saw the Let's Encrypt initiative make SSL certificates free and easy to deploy. Platforms like Cloudflare and WordPress.com make HTTPS free and on by default, and developer tools like SSLTest and Chrome's dev tools flag SSL configuration mistakes at no cost.

If you didn't switch, the biggest penalties came from Google and the browser vendors, penalizing your search ranking, displaying increasingly harsh "this site is not secure" messages to users, and more. The same players, collaborating with standards bodies and content delivery networks, went on to limit new Web technologies such as HTTP2 and ServiceWorker to HTTPS, blocking unsecured websites from enjoying their performance and functionality improvements.

So, with all this great progress, what will happen next? Will we actually reach (or approach) a fully encrypted Web? I believe the answer is absolutely yes. I doubt we'll ever reach 100% coverage, but I expect the vast majority of websites to turn on SSL within a handful of years.

The main reason for that is that the Web's giants are pushing for it. As adoption grows, it will become increasingly easier for browsers to mark HTTP sites as insecure, which they are already doing more and more. The Web's primary standards body, the W3C, has explicitly stated new capabilities will often require TLS, and the IEEE favors that sentiment. Apps on Apple and Google have to work harder to make non-HTTPS API calls, and Google is making entire top-level domains it controls require HTTPS. With all this momentum behind it, I believe HTTPS is on its way to victory.

I, for one, am thrilled to see this change take place. It shows the market and community can promote security controls without government regulation — though those don't hurt. It also shows the value of making security easy, forecasting a great opportunity for security tools that emphasize user experience and simplicity. Lastly, I'm simply happy more of my personal and business communication will be better protected — at least while in transit!

So where else can we replicate this type of success? The same HTTPS advocates are already working on it! The best two examples of such work deal with the risk of third parties, both services and code.

Most websites rely on a frightening number of third-party services, doing anything from analytics to advertising to social content. The fairly recent Content Security Policy (CSP) standard helps contain what those services can do on your site, reducing the risk of data theft and cross-site scripting. Google, Mozilla, and Microsoft all support CSP and highlight it in their dev tools, trying to raise visibility, but configuring it needs to get a lot easier for true adoption to occur.

Alongside third-party services, websites also rely on third-party libraries, such as the popular jQuery. Such libraries often carry known vulnerabilities, the same type of risk that led to the Equifax breach. Microsoft and Google both recently added a test for such vulnerable libraries to their browser's auditing tools, Lighthouse and Sonar. These widely used auditing tools are sure to raise developers' awareness about the risk, and tools will make it increasingly easy to fix such Javascript flaws.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

 

Guy Podjarny is CEO & Co-Founder at Snyk.io, focusing on securing the Node.js and npm world. Guy was previously CTO at Akamai, founded Blaze.io (acquired by Akamai), helped build the first Web app firewall and security code analyzer, and was in the Israeli army cyber units. ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: White Privelege Day
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17282
PUBLISHED: 2018-09-20
An issue was discovered in Exiv2 v0.26. The function Exiv2::DataValue::copy in value.cpp has a NULL pointer dereference.
CVE-2018-14592
PUBLISHED: 2018-09-20
The CWJoomla CW Article Attachments PRO extension before 2.0.7 and CW Article Attachments FREE extension before 1.0.6 for Joomla! allow SQL Injection within download.php.
CVE-2018-15832
PUBLISHED: 2018-09-20
upc.exe in Ubisoft Uplay Desktop Client versions 63.0.5699.0 allows remote attackers to execute arbitrary code. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of URI ha...
CVE-2018-16282
PUBLISHED: 2018-09-20
A command injection vulnerability in the web server functionality of Moxa EDR-810 V4.2 build 18041013 allows remote attackers to execute arbitrary OS commands with root privilege via the caname parameter to the /xml/net_WebCADELETEGetValue URI.
CVE-2018-16752
PUBLISHED: 2018-09-20
LINK-NET LW-N605R devices with firmware 12.20.2.1486 allow Remote Code Execution via shell metacharacters in the HOST field of the ping feature at adm/systools.asp. Authentication is needed but the default password of admin for the admin account may be used in some cases.