Threatpost sat down with Helme to discuss the state of web security, including certificate transparency, HTTPS deployment, Let’s Encrypt, content security policy and HTTP strict transport security.
Scott Helme, the well-known security researcher, international speaker and the founder of the securityheaders.com and report-uri.com free tools for web security, has devoted himself to improving the security environment of the internet for the past decade.
Scott Helme
Threatpost sat down with Helme to discuss the state of web security, particularly on the encryption front — including certificate transparency, HTTPS deployment, Let’s Encrypt, Content Security Policy and HTTP Strict Transport Security.
Threatpost: Tell me a little bit about some of your recent research and what’s been interesting to you these days.
Scott Helme: I’ve spent a lot of time researching the uptake of security features on websites recently, like how many sites are using things that are probably more commonly known, like HTTPS, and then which ones are using features that appear to be less known, like Content Security Policy (CSP) or HTTP Strict Transport Security (HSTS).
CSP is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.
A CSP header is a whitelisting function that allows you to define approved sources for content on your site that the browser can load. By specifying only those sources that you wish the browser to load content from, you can protect your visitors from a whole range of issues.
If an attacker uses a specially crafted comment to load JavaScript from another domain, a CSP header would prevent the browser from loading malicious content.
HSTS meanwhile is a policy mechanism that allows a web server to enforce the use of TLS in a compliant web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.
Some of these features can be simple to deploy and get started with, and they offer huge levels of protection, but we’re not seeing sites adopting them in large numbers. I want to find out why that is, and what we can do to increase adoption and make the web a safer place.
TP: You’ve been looking at features built in to modern browsers that allow them to report problems back to the website if things go wrong or if the user sees an error. Some of them can even detect attacks against a visitor and warn the website operator that it happened. Could you elaborate a bit on this?
Helme: This ties in with my first point about all of these modern security features that browsers now have built in. Not only can they offer additional security and protect your visitors, they can also report back to you when they detect an attack. Imagine the browser of every visitor to your site being on the lookout for security issues, malicious code or attacks, being able to stop them, and then report back what they found. They’re incredibly powerful features that I think more sites should be taking advantage of.
TP: One of your primary topics when it comes to web security is encryption — what are some of the new approaches on the horizon that are interesting?
Helme: Over the last two years we’ve seen an explosion in the number of sites using HTTPS on the web. This is because sites are starting to realize they need it in more places than they thought.
There are positive factors now, like better performance and SEO, and the technical barriers are being reduced. And, of course, the cost barriers are also being reduced or removed with initiatives like Let’s Encrypt. Let’s Encrypt are a free certificate authority (CA), and you don’t have to pay them for certificates to setup HTTPS on your site.
This has allowed countless sites to deploy HTTPS that previously couldn’t. There has been some controversy around phishing sites now using HTTPS, but if we want 100 percent of the web encrypted, and we should, then it means phishing sites will be using HTTPS too.
TP: Does HTTPS cut it?
Helme: If you properly deploy HTTPS we can have huge levels of confidence in communications being secure. So much so that attackers will find ways around HTTPS because it’s just so hard to crack. We are seeing huge leaps in the deployment rate of HTTPS, but we do need to keep that up as we have a long way still to go.
TP: Certificate transparency (CT) is on your radar screen. Why are you so excited about it? How is it a gamechanger?
Helme: CT is one of those features that, now that we have it, I wonder why it took us this long to roll it out. We should have had it from Day 1.
There are many benefits to CT, and the obvious one if for site operators is to be able search for certificates issued to their domain names. This means if a cert is issued, you as the domain owner now have the chance to find out about it, where it was previously impossible to make such assurances.
Alongside that, it allows the wider community visibility into a certificate authority’s operations. It’s not that I don’t trust CAs, but they have a huge level of power on the web. I think that power is in the right hands, but we should audit and verify the use of that power. CT gives us this capability.
TP: How can we detect phishing sites with CT? It seems easy enough — do you predict more people taking advantage of this capability? How will it change the phishing landscape, potentially?
Helme: Sites can do this themselves by monitoring logs and looking for certs, but Facebook has just released a great tool so you can do this for free.
In short, you tell Facebook which domains you own, and if they see any certs that look like they could be attempting to phish your users, they will notify you.
TP: Some say that the bad guys are using HTTPS to their advantage.
Helme: The web is going HTTPS, and it’s not just good sites it’s bad sites too. Lots and lots of phishing sites are now using HTTPS because it’s become easy and free to deploy. There has been a lot of discussion and resistance against CAs like Let’s Encrypt issuing certs to these sites; whether or not you agree with this happening, it is happening right now, so we have to think how can we turn this to our advantage.
To wit: When a phishing site gets a certificate, we can see it in CT so we can know about the site probably before they’ve even brought it online. All we need to do is look for domains that are similar to popular sites or contain their domain as a substring.
What if we kept an eye on the CT logs for certificates issued to paypa1.com or secure-paypal.com? That would probably be a pretty good idea and it could certainly turn up some interesting information.
TP: Overall, where are we in the process of securing the web, and what are the most glaring places that still need solutions? What obstacles should we be looking at? What new tools?
Helme: We really do have a long way to go in securing the web. We’re making great progress on HTTPS right now, but it’s taken an entire industry effort and years of work to build the momentum we have at present. Without browsers driving the change or the creation of a free CA, I do wonder where we’d be.
Outside of HTTPS, I think we need more education around security. There’s no point encrypting usernames and passwords, or credit-card details, if we’re just going to leak them via other means. We need more secure code, security-aware staff and better processes in place.
Source: threatpost.com