(2 votes, average: 3.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

September 5, 2018 4

Google’s plan to kill the URL is a golden opportunity for Certificate Authorities

in Industry Lowdown

Who is better equipped to assist in authenticating website identity than CAs?

Google wants to kill the URL. That’s the headline from Wired. As Google Chrome turns 10 and looks to the future, its next target will be Uniform Resource Locators, or URLs.

Most people just know URLs as web addresses. The term URL is actually a bit of a misnomer because in this context we are referring to a very specific kind of URL. Typically a URL is used in conjunction with a website, but they can also be used for file transfer, email and database access.

On a technical level, URLs are associated with IP addresses. Generally people are familiar with IPv4 addresses, they look something like this:

97.76.174.114.

But remembering a string of numbers (or something even more complicated in the case of IPv6) for every website you want to visit would be prohibitively difficult for all but the most precise of memories. So in 1994, the inventor of the world wide web, Al Gore Tim Berners-Lee defined URLs in RFC 1738. We have used them to navigate the internet ever since.

So why does Google want to kill the URL and why is this a major opportunity for certification authorities?

Let’s hash it out…

Why does Google want to kill the URL?

The average internet user does not know a whole lot about web security or what to look for when visiting a website. We are keenly aware of this because every week nearly 5,000 people read our guide on how to spot a fake website. So, asking users to know what to look for within the URL itself is not going to yield good results.

In fact, just displaying the URL is a problem for browsers, especially with their mobile versions.

RELATED: How popular iOS apps display URLs

Eric Lawrence, a former Googler currently in his second stint with Microsoft, has written about a concept that is extremely informative when trying to understand browser security and where Google is coming from on this. It’s called the line of death. The idea is this: the browser can only control the top of the window, none of the pixels below the so-called line of death can be trusted.

If a user trusts pixels above the line of death, the thinking goes, they’ll be safe, but if they can be convinced to trust the pixels below the line, they’re gonna die.

One of the things that Lawrence, the browser community as a whole and specifically Google have realized though is that some (for lack of a better term) attacker data does make it above the line of death.

The web page’s title and icon (1) are controlled by the website itself. But the more problematic area is the address bar. As we already covered, people really don’t understand URLs. And hackers and cyber criminals are acutely aware of this and use it to their advantage on a near constant basis.

This is an example of a URL:

Ideally, people could look at the domain itself and get a sense of website identity. But again, as we mentioned earlier, the reality is that browsers can’t rely on their users to discern a legitimate URL from a fake one.

Website identity continues to be a major issue.

“People have a really hard time understanding URLs,” Adrienne Porter Felt, Chrome’s engineering manager told Wired. “They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity.”

Google doesn’t have any idea what to replace URLs with

The problem Google is facing is that it doesn’t exactly have a URL replacement handy. It knows a change needs to be made but it doesn’t know what that change should be.

Right now Google says its main focus is just identifying all the ways people use URLs.

Eventually, the idea will be to replace the URL with something that is not only more user-friendly, but that also enhances security and provides authenticated website identity information.

“I don’t know what this will look like, because it’s an active discussion in the team right now,” said Parisa Tabriz, the director of engineering at Chrome. “But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.”

This is not the first time Google has tried something like this. Back in 2014 it briefly tried to replace URLs with “origin chips” that only displayed the domain name. But it paused on that before it ever got to an official release because of push-back from users.

Lately Google’s initiatives to change the web have gone a little more smoothly, as evidence by its push to mandate HTTPS earlier this year. And even before announcing its intentions, Google was already tinkering with URLs. It announced plans to phase out showing the protocol at the beginning of the URL with Chrome 69, which is literally being rolled out to its users as you read this.

Per Porter Felt, Google plans to speak publicly about its plans to further deprecate the URL either this Fall or next Spring.

Google’s plan to kill the URL is a golden opportunity for certification authorities

At the heart of any changes to the use of URLs will be the need to assert website identity. This has never been more crucial than it is right now with phishing at an all-time high and a range of malicious actors using social engineering to phish and defraud internet users.

Perhaps no industry is better suited to assist in authenticating various identities – end entity ID, machine ID, website ID, corporate ID – than the Certificate Authorities that issue digital certificates.

There has already been a push to decouple business authentication from SSL, the thinking being that SSL/TLS serves its function as a security mechanism but struggles with the authentication aspects. This would be the perfect opportunity to fix that.

CAs already have the infrastructure built out to validate businesses and other entities, helping them to assert their corporate and web identities.

Let’s put that to use finding a replacement for URLs that can both enhance security while also helping businesses and organizations assert their identity in a way that is unmistakable to internet users.

Obviously, not every website would need extensive authentication, but there are myriad businesses and other organizations that could make ample use of a mechanism that more visibly confirms their identity to its customers or users.

Authenticating identities is probably not something most of the browser community would want to take responsibility for. While Microsoft, Apple and Google all have the resources to do it, putting together that kind of apparatus would take considerable time. It also seems fairly out of scope for all three corporations.

No, authentication would need to be outsourced, and the CA industry is in perfect position to step into that role.

There would still be a lot of work that needs to be done. Regardless of whether it’s decoupled from SSL/TLS or not, Extended Validation needs to be strengthened. And we would need to find a way to display the information that avoids name collisions or confusion over which entity you’re transacting with. But this is a golden opportunity for certificate authorities to realize a new future where identity continues to exist at the core of everything we do.

The future may be calling, now it’s time to figure out if we’re ready to answer.

As always, leave any comments or questions below…

• #Certificate Authorities
• #Eliding
• #Google
• #URLs