Most users are aware that HTTPS is a secure protocol that encrypts their communication with a web server. We rely on HTTPS to ensure that unauthorized parties cannot “snoop” on our conversation with a webserver, for example our bank’s website.
But HTTPS helps maintain security in another, lesser known way: Authentication.
A brief history of authentication
Most of us have a good understanding of encryption: encoding conversation so that eavesdroppers can’t understand it. We have a more superficial understanding of Authentication, however.
Authentication is nothing more than verifying that we are who we say we are, or that the website we visit is who they say they are: verifying an identity. The most common ways we do this are by presenting some credentials: an ID card, or a username and password. This identifies us to another person or a website. But we seldom ask that the website we visit prove their identity to us. This can be a problem, especially with phishing sites that pretend to be something else.
HTTPS solves this problem. In addition to encryption, HTTPS is used to authenticate to us, the visitor, that the website belongs to a specific entity. For example, when I navigate to https://twitter.com/, the address bar in Chrome tells me that I am visiting “Twitter, Inc”:
Websites uses certificates to authenticate themselves and encrypt traffic. These certificates provide varying levels of authentication: from simply authenticating the website URL itself to verifying the business entity to which it belongs (in this case, “Twitter, Inc”). Chrome knows this because the certificate includes the business entity.
Further, the certificate is issued by a trusted certificate authority (CA). The browser (Chrome) trusts the CA to verify the ownership of the domain and the validity of the encryption. If the certificate has expired, or the certificate authority is not trusted, the address bar will show a broken security icon, and often the browser will show a page warning that the site’s security cannot be trusted.
What does HTTPS Authenticate
Certificate authorities can prove the authenticity of the business or individual who owns the website. But doing so is a cumbersome process for the business owner, and a lot of websites choose a path of less resistance: They simply authenticate their website address, with little or company information. This is an acceptable practice, and the address bar simply tells us that the connection is secure, without providing identity information:
This examples tells me that my connection to infamia.com is encrypted, but does not further authenticate that infamia.com is in fact Infamia, Inc. In this case, the CA verified only the domain itself (infamia.com), but did not verify ownership by our corporate entity (Infamia, Inc.). I, as a user, can use my own judgement to decide if I trust infamia.com to represent Infamia, Inc.
The lack of ownership on the address bar also alerts me to look out for possible phishing attacks. I want to double-check that the URL is correct, since similar URLs can use HTTPS encryption.
HTTPS doesn’t encrypt everything
HTTPS only encrypts the data exchanged between your browser and the remote website. It does not encrypt “metadata”, notably which website and pages you are visiting, what time, what browser you’re using, and other related details. In other words, an eavesdropper will know who you’re talking to, even if she doesn’t know what you’re saying.
This metadata can still be valuable: Your communication may be encrypted, but metadata will expose that you’re visiting AshleyMadison.com (to use a famous hacking example).
If you’re looking for ways to protect your members’ privacy using HTTPS, let us know!