Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13295
PUBLISHED: 2020-08-10
For GitLab Runner before 13.0.12, 13.1.6, 13.2.3, by replacing dockerd with a malicious server, the Shared Runner is susceptible to SSRF.
CVE-2020-6070
PUBLISHED: 2020-08-10
An exploitable code execution vulnerability exists in the file system checking functionality of fsck.f2fs 1.12.0. A specially crafted f2fs file can cause a logic flaw and out-of-bounds heap operations, resulting in code execution. An attacker can provide a malicious file to trigger this vulnerabilit...
CVE-2020-6145
PUBLISHED: 2020-08-10
An SQL injection vulnerability exists in the frappe.desk.reportview.get functionality of ERPNext 11.1.38. A specially crafted HTTP request can cause an SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerability.
CVE-2020-8224
PUBLISHED: 2020-08-10
A code injection in Nextcloud Desktop Client 2.6.4 allowed to load arbitrary code when placing a malicious OpenSSL config into a fixed directory.
CVE-2020-8229
PUBLISHED: 2020-08-10
A memory leak in the OCUtil.dll library used by Nextcloud Desktop Client 2.6.4 can lead to a DoS against the host system.