Privacy Canada is community-supported. We may earn a commission when make a purchase through one of our links. Learn more.

A lot of the internet has recently been switching to something called HTTPS protocol. This allows for all communications between the client and server to be encrypted through the use of public key encryption.

The non-secure HTTP (hyper-text transfer protocol) generally transmits all of it’s data in plaintext (though there are exceptions, such as when JavaScript is involved). This means that anyone that could intercept the message (such as on the same WiFi network) could plainly read the data being sent between the client’s machine and the server. This can include passwords, credit card data, and other sensitive information. For this reason, https was created.

Technically, it is not a protocol itself, but rather the laying of SSL(or TSL) encryption on top of the regular http protocol. TSL/SSL are assymetric (public) key encryption mechanisms specifically for communicating over internet protocols. The client and server communicate initially in plaintext, establish who each other are and exchange public keys, and then eventually say “alright — let’s switch to encrypted communication† — and that’s the last of their communication an eavesdropper would be able to read.

But that’s not all involved in HTTPS. Another thing needed to keep web connections secure is to prevent man-in-the-middle attacks, and HTTPS has a solution for this as well. Websites that use HTTPS also have something called a certificate that proves that they are in fact who they claim to be. How can we be sure that this certificate is valid? The answer is two fold. The web server signs a message with it’s certificate private key, and they are also registered with major web authorities that will certify their authenticity of the connection.