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
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Mueller Probe Yields Hacking Indictments for 12 Russian Military Officers
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/13/2018
10 Ways to Protect Protocols That Aren't DNS
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/16/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12959
PUBLISHED: 2018-07-19
The approveAndCall function of a smart contract implementation for Aditus (ADI), an Ethereum ERC20 token, allows attackers to steal assets (e.g., transfer all contract balances into their account).
CVE-2018-14336
PUBLISHED: 2018-07-19
TP-Link WR840N devices allow remote attackers to cause a denial of service (connectivity loss) via a series of packets with random MAC addresses.
CVE-2018-10620
PUBLISHED: 2018-07-19
AVEVA InduSoft Web Studio v8.1 and v8.1SP1, and InTouch Machine Edition v2017 8.1 and v2017 8.1 SP1 a remote user could send a carefully crafted packet to exploit a stack-based buffer overflow vulnerability during tag, alarm, or event related actions such as read and write, with potential for code t...
CVE-2018-14423
PUBLISHED: 2018-07-19
Division-by-zero vulnerabilities in the functions pi_next_pcrl, pi_next_cprl, and pi_next_rpcl in lib/openjp3d/pi.c in OpenJPEG through 2.3.0 allow remote attackers to cause a denial of service (application crash).
CVE-2018-3857
PUBLISHED: 2018-07-19
An exploitable heap overflow exists in the TIFF parsing functionality of Canvas Draw version 4.0.0. A specially crafted TIFF image processed via the application can lead to an out-of-bounds write, overwriting arbitrary data. An attacker can deliver a TIFF image to trigger this vulnerability and gain...