OPINION - What does the Green Padlock Really Mean?

HTTPS is a way of securing your website. It gives you a nice, green padlock and, to most users, it means all is safe with that website and you can trust this website and feel free to enter credit card details and passwords on any site with such a reassuring, green padlock.

Many would be surprised to know that is not in fact what the green padlock means at all and, while you definitely shouldn't enter sensitive details when a green padlock is not present, the mere presence of it does not indicate the site is safe.

The green padlock simply represents that traffic to and from the website is encrypted. Encryption means no one else but that website can read any credit card details and/or any passwords you enter there. The key point, which is not obvious to the average user, is that there is nothing to say that this is not a dummy site specifically set up to gather credit cards and/or passwords. A certificate, provided by a certificate provider (Certificate Authority or CA), is used to set up the encryption. However a dummy site can get a certificate (and hence a green padlock) as easily as a real site. In fact some people are blaming free cert providers for potentially making it easier for phishing sites to get certificates - perhaps unfairly as this was always happening, but has got slightly easier now since it costs nothing and is fully automated. There is a massive push towards making all of the web HTTPS and part of that necessitates making it easy to get a HTTPS certificate and the automation is the only way to make this to happen.

One thing the green padlock does guarantee (within certain reasonable limits) is that the you are talking to the site in the address bar. So if you are on amazon.com and see a green padlock, then you are securely talking to amazon.com. However if you are on amaz0n.com with a green padlock then you will be securely talking to amaz0n, but there is no guarantee that this is the international retailer amazon.com and in all likelihood it is not and it is a fake phishing site, set up to trick you into thinking you are on Amazon.

And that is the real issue here. The green padlock represents security (through encryption) of the traffic, but that is not to say that any site that uses encryption, is to be trusted. A subtle distinction that is difficult for the average user to understand.

Well yes. But this, seemingly simple thing, is fraught with issues. First off all it's too easy to miss a simple typo. While amaz0n.com might be easy to spot can you honestly say you'd notice if you were on amazn.com? Especially if it had a nice, green, reassuring padlock in the address bar and looked exactly like Amazon.com? It could even just be passing details back and forth to the real Amazon.com so even has all your correct profile details and past history. And that's before we even getting started on homograph attacks, that use foreign character that look the same as regular ones.

Next up you don't necessarily know the address. While it's easy for well known brands like Amazon who's to say ExampleBank.com is the right address for your bank as opposed to ExampleOnlineBank.com? Or any of the branded terms a bank might use for their online offering? Then you've smart phones and other devices which often don't show the URL by default and just show the page name.

Well that's obviously at the heart of the problem and preventing that sounds entirely sensible, but again isn't as easy as it sounds. Should someone vet each website that's set up? Domain name registrations and https certificates have been on a race to the bottom, which has necessitated automating these. Now making the web cheaper and easier is ultimately a good thing, but does mean there is no manual checking of this sort of stuff anymore. And arguably should there be? What if you've a great idea and want to register a website with your brand name - can you not unless you can prove you own that name and have a website ready to go? What if you want to set up a protest site called examplebanksucks.com - again should you not be able to because you are not affiliated with example bank? Where do you draw the line? Ultimately I believe the web should be free (in terms of ideas) and cheap (in terms of money) for people to set up whatever websites they want. However with that comes the pain that some people are going to abuse that.

This is not to say CAs do not do any checks before issuing certificates to phishing sites. As well as checking you have access to the domain you are requesting the certificate for, Certificate Authorities do some checks - particularly on high profile targets (you're unlikely to get a certificate for a Google domain - though it has happened!). However some argue they should do more of this. Also this is of little help to smaller companies who aren't on such a "high profile" list. Additionally while we're on the subject, the likes of Google may have whole teams of people monitoring for fraudulent certificates and sites set up in it's name, most companies do not. And most companies do not run the worlds most popular browser so cannot shut off any phishing sites aimed at their company, as easily as say Google can.

Saying all that we should be able to shut down phishing sites quickly by contacting the domain registrar and any CA which issued a certificate for that site. This works reasonably well and most phishing sites don't tend to hang around too long to be honest. However that's very reactive and again difficult for the user to tell when they visit a website. Browsers could of course check the age of a domain and flag new ones, but nothing to stop some one registering a phishing site in advance to get around this, and also that would unfairly penalise legitimate new sites.

So any thing we can do to give confidence to users that they are on a "real" website?

Extended Validation (EV) Certificates were proposed as a solution to this issue. The idea here is that you give an extra special cert to those sites willing to pay extra for it, and the cert provider (CA) do some extra checks to validate the authenticity of the website. Those checks take time and effort and hence why EV certs are more expensive. In return the browser gives a bigger, greener notification that this is a special cert and also usually shows the actual legal company name the site belongs to:

There is also an in-between Organisation Validaion (OV) certificate, which does some of those checks and so is a little harder and more expensive to purchase, but gives no obvious indication to the user that differentiates it from a standard Domain Validation (DV) certificate. OV certificates are a halfway point that are almost completely pointless to be honest. They demand some of the validation of EV certs but give no real noticeable UI benefit to let the visitor know the website owner has been through this hassle.

EV sounds great - perfect solution to a problem. However there are a number of issues with EV certificates:

• Most users don't know the difference between a normal Domain Validation (DV) certificates and EV certificates. So this defeats the whole point.
• Even if users did recognise the extra value in them, they still don't know if the website they are looking at uses them or not. Some big names use EV (Twitter, Microsoft) but some even bigger names do not (Google, Amazon). So if you went on Twitter tomorrow and didn't see the all-green address bar and company name, but did see the usual green padlock, would you immediately stop and assume it's a fake site? Nope. It's all too confusing at the moment.
• EV certificates ultimately do not provide any better encryption than DV certificates and the value in them is that the company has been vetted but you see all sorts of claims (particularly from CAs themselves, such as DigiCert, GlobalSign and Comodo) that they are more secure and/or have "better encryption". They are more secure in terms of trust (as the requesting company has been vetted), but not in terms of encryption technology (though that's not 100% accurate as often newer features like Certificate Transparency are enforced for EV certificates first, and Chrome only does revocation checks for EV certs only - something which Firefox looks to be doing soon too.).
• There is little definitive evidence that EV certificates provide any value to websites. While some talk about an increase in user trust and conversion rate, few studies are available for this and those that are, are usually published by those with vested interests (CAs) and are disputed.
• Some see EV certificates as a barrier to those that can't afford them. Fine for Twitter to splash out on an EV cert as they can afford it, but smaller mom and pop shops struggle to justify the cost. Though it has to be said that all certs are getting cheaper and cheaper and an EV cert can be picked up for less than €100 now.
• Similarly it can be time consuming to get them as you have to provide ownership of the name used in the domain. This can involve sending legal documents back and forth and the CA verifying them and then performing their other checks. Though in a lot of ways that's entirely the point, it would be better if it was somehow easier to verify legitimacy.
• Some names potentially are not valid for EV certificates without registering the brand name and/or setting up a company in that name. Wildcard certs are also deliberately not allowed for EV certs. Non-companies (e.g. a little blog like this), would struggle to qualify for an EV cert without registering the name as a company.
• There are limits to what can be checked. How secure is the website? The company? The EV certificate may convey trust but the CA has of course not completed a full audit of the company and it's security and financial standing, but merely verified identity of the company.
• CAs should not be certifying content. Personally I disagree with this argument as I think an EV certificate merely states this is genuinely from a real company and says nothing about the content they put on that site, but it's a fine line.
• HTTPS was intended to be a secure transport layer and was never intended to indicate trust in the other party at the other end of the line (except to validate the server name) and using it for that is stepping outside it's original remit. I would argue there is no harm in extending a service to other uses, providing you don't break it's original use if it's still being used for that. EV is as an extension and not a replacement for DV in my eyes.
• Are they just a money spinner for the CAs? Now there are undoubtedly costs to EV certs, but given the questions around their benefits, the value should of course be questioned.

Unlike some, I like the principal of EV certificates. I see a value in doing extra checks, and I appreciate those extra checks are going to cost. I also don't see why the CAs shouldn't be the ones to do those extra checks and so why the HTTPS certificate can't be the place to highlight those extra checks. The problem is mainly that the user cannot differentiate between the two.

EV certificates are seen as a CA invention to make money from nothing. This is something I disagree with, as I say, as I do recognise there is a cost to providing this service, and do think there could be benefits if it was made clearer to the user. However every time the EV subject creeps up there's usually a lot of shouting and blame aimed at the CAs for all sorts of other problems problems. Which distracts from the real conversation in my eyes. There are problems with some of the CAs - read Ryan Sleevi from Google's long lament about some of the bad choices made by CAs for some cringe worthy examples here, but that's a completely different topic in my eyes.

I'm not sure that EV is the right solution to the phishing problem (certainly not in it's current implementation where the difference between DV and EV is not clear to most people), but I don't see any better proposal and I don't think drowning out the real problems EV was attempting to address, with other issues you have with the CAs, is going to get us to a solution here. Maybe the CAs are just pushing EV as a money spinner, but to me I can see value in the concept of EV, if not the current implementation.

HTTPS is increasingly becoming the norm. With a number of free cert providers (e.g. Let's Encrypt and AWS) the cost of certificates should no longer be the barrier it once was (though that's not to say there are not other costs meaning HTTP is still a premium service for many). So should we redefine the green padlock and make it easier for the users? Should HTTP-only be red to indicate a problem, HTTPS without EV be grey to indicate the new norm and HTTPS with EV be green to indicate "Safe"? I would certainly be a fan of that but I think we are still some way off of this. Perhaps in the next few years that may become a real possibility but for now this would break too many sites who do not yet support HTTPS. It also still doesn't address all the points above - mom and pop stores might still have to live with grey, but that might be fine if they are not hosting a complex ecommerce site and just want a home on the web to direct people to their actual store.

There are safe lists like Google’s Safe Browsing list, which is used by Google in their site search, by many browsers and by many CAs to verify known fraudulent sites. However this does require an awful lot of effort to maintain and is only as good as the last time it visited a site. It's a good additional check for fake or dangerous sites, but I still think we need some way to proactively identify "good" sites.

There are also various technologies used to ensure the correctness of the certificate behind the green padlock, but they are mostly concerned with protecting the real domain name, rather than protecting against fake phishing domains.

Well generally yes, but there's all sorts of fun and games to be had once you start down this path. There's a few other things to be aware of, which really are beyond the scope of this post but we'll touch briefly on them.

• It's possible (though not easy) to redirect traffic to real sites (e.g. set up a fake amazon.com). This requires DNS poisoning and also having a HTTPS certificate that the browser accepts for the amazon.com site (remember the green padlock does verify the domain name). This risk is best addressed with Certificate Transparency (which attempts to make it easy to see if someone other than you has requested a cert for your site) or Certification Authority Authorization (CAA) which lists the CAs that can issue certificates for your domains and is soon to become mandatory (without which it's been fairly useless so far!). Additionally there are more complex technologies like HPKP or DANE (both of which aim to restrict the certs that can be used on your domain name), but they require significant understanding of them before use.
• It's possible to intercept unsecured HTTP traffic and change it. So if you go to www.twitter.com, this by default goes to http://www.twitter.com which then sends a message directing you to https://www.twitter.com. As HTTP is unencrypted you could change this to send you instead to https://www.twtter.com (assuming you managed to register that) and hope no one notices. This is best addressed with only using HTTPS on your site and then enforcing this with HSTS
• Even if you are on a real website, it can be compromised with Cross Site Scripting (XSS) or Cross-Site Request Forgery (CSRF) issues which can compromise the website itself and leak your credit card information just as you are entering it: HTTPS is but one piece of the security puzzle for a website. Other problems include that the security ciphers used to secure the HTTPS connection could be weak and insecure. More and more secure methods of encryption are coming out all the time, but at the same time, flaws in encryption methods (particularly older ones), and an increase in cheap compute power mean some encryption methods should not be used and, unless you're a complete security expert, you would struggle to know the encryption used on a HTTPS site and whether that's good enough. Again browser makers attempt to make these risks obvious by changing the green padlock to a red cross out padlock warning you of these issues. The best advice I can give to ensure decent HTTPS set up is to run your site through SSLLabs Server Test at least once a quarter.
• The website owner could come under some complete other attack or poor security, completely unrelated to their website. For example someone could otherwise gain access to their data.

The green padlock is a complicated thing. And the issue is how to condense those complications for the average user. While I, and others, may be interested in the subject my parents, for example, are not. And they should not be restricted from using the web simply because they do not have an university degree in software engineering. While there is of course some onus on people not to be tricked into obvious fraudulent websites, I do think there is a real problem here, and we as a technology community have not come up with a solution to that problem and we should.

HTTPS is an important feature and there are many benefits to providing a secure transport layer between client and server, which are not covered here (including privacy and confidence the content has not been altered). The main problem is one of understanding of it's use. To techies it represents just that - a secure link between client and server, but to the average user it means much more than that - it means the site itself is safe and can be trusted, and there in lies the problem.

Personally, I do not think that solution is to explain what the green padlock really means (encryption of traffic between client and server), but instead to make the green padlock mean what the vast majority of the user base think it means (safe). Of course no solution is going to work 100% of the time, and someone will always find ways around security solutions, but in my mind we are falling far short of where we should be in making the web a safe environment for it's users. Phishing sites are too easy to set up and be accepted by the average user, and training them to look for the green padlock for safety, and then laughing at their stupidity for not understanding that's not what that actually means, was never the right answer.

We need a simple indicator to quickly indicate a site is likely safe and two states green (good) or red (bad) is as simple as we can make it. How we go about that is up to us. Whether this is down to domain name registrars, certificate authorities, browser developers or some other party we need to improve on where we are.

Do you agree? Disagree? Let me know below your thoughts below.

This page was originally created on 27-Jan-2016 and last edited on 28-Jun-2022.