A Green Padlock Doesn’t Mean Safe

For at least the past decade you have been told not to enter any private or secure information on a website unless you saw the little padlock icon which indicated you were on a secure website. Over the last few years, and with different browsers sharing the internet browsing market, that little padlock has evolved into an even more noticeable indicator which is usually a color coded button near the address bar. Green means good, red means bad, right? Well, it’s not quite that simple.

Before I explain, I first want to emphasize that this security indicator is not a malware check. It doesn’t indicate if a site is safe or not or if it contains malicious code. It also doesn’t always guarantee that you are on the website that you expect or think you are. It is simply an indicator that tells you if the connection to the website is secure or not. So why would a website get a green indicator yet be unsafe?  To understand this, you need to understand exactly whay this little green button really means and how the browsers determines when a site is secure or not.

SSL, or Secure Socket Layer, is a protocol that is used to transfer encrypted data over a network (i.e. the internet) between two machines (i.e. your computer and the server running the secure website).  When SSL is used to secure a website, this is referred to as HTTPS, as opposed to regular unsecure HTTP.  You will see this used at the beginning of a URL when you visit a secure website.  SSL does this encryption using certificates and private keys combined with complex mathematical algorithms to scramble the data that is being transmitted in both directions.  The host at each end has the necessary information to decrypt the data and anyone who tries to capture the data in between will only see scrambled useless data.

Now that you understand the basic function, let me explain as simply as possible how it works. Let’s use https://www.example.com as an example.  In order for example.com to be a secure website, the owner must first request a certificate from a public Certification Authority, or more easily referred to as a CA. Public CAs are world wide trusted organizations who can issue and digitally sign certificates to those who request them.  After requesting a certificate, the requester is asked to perform some sort of verification to prove ownership of the domain being secured which is www.example.com in our example.  This step ensures that the CA is issuing a certificate to the legitimate domain owner, and not someone attempting to impersonate ownership.  For instance, I would not be able to go and request a certificate for www.paypal.com since I would not be able to verify ownership.

Once the requester has completed the necessary verification, the CA will then issue and sign a new certificate to the domain requested which in our example will be www.example.com.  Certificates are issued with an expiration date, after which certificates are considered expired and become invalid.  The website owner will then install this certificate onto the server along with the private key that they created in order to request the certificate. The private key is exactly what it sounds like. It is kept private and usually password protected.  The key is used to encrypt data being transmitted from the server so if an attacker were to obtain this private key, they would then be able to decrypt any of that scrambled data between your browser and the server.

Now let’s take a look at how this works within your browser.

  1. You enter the URL into your browser. (https://www.example.com).
  2. Your browser connects to the server that is hosting the requested website.
  3. The server responds back with it’s certificate.
  4. Your browser reads the certificate and performs a few checks as follows:
    • Is the domain in the certificate the same as the URL that was requested?
    • Is the certificate within the valid date range?
    • Has the certificate been revoked?
    • Is the certificate signed by a trusted public CA?
  5. If any one of the previous checks fail, your browser will generally give you a full page warning indicating that there is an issue.
  6. If all of the checks pass, then the browser will continue with connecting to the server and an encrypted session is setup so that further transmissions will be secure.

Let’s take a brief look at each of these checks.  Is the domain in the certificate the same as the requested URL?  When the website owner requested a certificate, they provided the domain that they wanted to be protected (www.example.com).  When the certificate was issued, the domain was included in the certificate.  When the browser reads the certificate, it checks to see if the domain in the certificate matches the domain that was used to connect to the server.  So if the certificate that was returned contained the domain www.test.com, verification would fail, but the browser will usually present a warning but allow you to proceed if you are certain the error is expected.

Is the certificate within the valid date range?  A certificate is issued for a certain period of time.  This date is hard coded into the certificate by the signer.  The certificate can’t be valid before the date it was issued or after the date which it is set to expire.  The browser checks the validity period of the certificate against your systems clock.  This is why it is important that your computer has the correct date and time set, otherwise this type of verification will fail.  If the certificate fails the validity period check, the browser will present an error and will not allow you to proceed.  You can check your date and time to make sure it’s not your computer, but otherwise the only fix is for the website owner to request a new certificate.

Has the certificate been revoked?  Because a certificate (and it’s associated private key) are used to encrypt and verify identity it is important for the owner to keep the key secure.  If the private key gets compromised, it can be used by a hacker to decrypt data or it could even be used to setup a malicious server which pretends to be the original website without a user’s knowing.  If this happens, the certificate can be revoked.  This causes your browser to reject the certificate and you will get an error without the ability to continue.  There are other reasons a certificate could be revoked, but that would generally be the most common.

Is the certificate signed by a trusted CA?  Your computer has a list, or a certificate store, which contains certificates for all known public CAs.  In Windows, these types of certificates are called Truested Root Certification Authorities.  Your operating system developer (Microsoft, Apple, etc.) maintains the list though regular OS updates.  Some software, such as Firefox, actually has it’s own certificate store built in rather than using the operating system’s certificate store, but it works in the same way and is maintained by the software developer.  When a CA issues a certificate to a website, the certificate is signed using the CA’s certificate.  When the browser checks a website’s certificate for trust, it verifies that it has been signed by a CA which is published in the local system (or software) Trusted Root Certification Authority store.  If so, then the browser considers the website’s certificate as trusted.  If not, then you are presented with a warning that the certificate can’t be trusted, but you will usually be able to continue to the website as long as you expect this error.

Knowing all of this, let’s look at an example of how you could encounter a malicious site which shows to be trusted and secure.  Let’s say a malicious user sets up a website with the domain www.paypal.com.summary-support.com.  If you think this looks like a strange URL, well, it is.  But it is also valid.  Even though you see www.paypal.com in the URL, the actual parent domain of this URL is summary-support.com.  The www.paypal.com part is just a subdomain and is used to give the malicious URL a familiar look so that at a glance, users would trust it.  Now the malicious user can simply go to a public CA and request a certificate for their website.  Most CAs will automatically reject this sort of request just for knowing that this is going to be used maliciously.  Common sense says that PayPal wouldn’t request a certificate for a website with the parent domain summary-support.com.  However, some CAs, such as Let’s Encrypt, do not perform such requests and are completely automated so a certificate will get issued.  This certificate can then be used to secure the malicious site and users visiting it who aren’t paying close attention to the URL could fall victim to any attacks performed by the website.  Because the certificate was issued by a public CA, your computer will trust it and the website will show the green bar indicating it is a secure connection.  And, indeed, it is a secure connection, but it does not at all indicate that it is a safe connection.

There are other mechanisms such as Microsoft Windows’ SmartScreen technology (when using Internet Explroer or Microsoft Edge) which checks a website against a database of known malicious sites in order to prevent a user from connecting to a malicious site.  However, this requires that the site already be listed in SmartScreen’s database and these kinds of sites are popping up in mass numbers every day, so it is very possible to end up at such a site with absolutely no warning of malicious intent.  This is why, even with antivirus, online scanners, website checkers, certificate validation, and every other possible security mechanism in place, it always comes down to the user to pay attention and play it safe when working on the internet.

I hope this article has helped to give you a basic understanding of website security and, more importantly, that it will help you to browse more safely.  If you have any questions or comments, feel free to comment below.  I try to respond to comments as frequently as possible, especially if I can help someone to be safer on the web in these days of massively expanding cyber attacks.  Thanks for reading!

Leave a Reply