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 and cofounder 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 & 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
Microsoft Word Vuln Went Unnoticed for 17 Years: Report
Kelly Sheridan, Associate Editor, Dark Reading,  11/14/2017
Companies Blindly Believe They've Locked Down Users' Mobile Use
Dawn Kawamoto, Associate Editor, Dark Reading,  11/14/2017
121 Pieces of Malware Flagged on NSA Employee's Home Computer
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/16/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Managing Cyber-Risk
An online breach could have a huge impact on your organization. Here are some strategies for measuring and managing that risk.
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.