HTTPS or, Hypertext Transfer Protocol Secure, is a protocol to provide both authentication (ensuring you're connection to the correct website) and privacy (ensuring that your communications with the web application can't be intercepted); this is primarily achieved via encryption. To achieve this two types of encryption are utilised; public key encryption and symmetric key encryption. This is important because we often hear that a HTTPS certificate utilises a 2048 bit key, this sounds very large considering that the US government accept Top Secret information being encrypted with a 256 bit key. We therefore need to understand the difference between these two types of encryption and how these are used within HTTPS.
# Public key encryption
Public key encryption utilises two keys, a public key and a private key. The private key is kept by one individual or organisation whereas the public key can be printed in the newspaper! The algorithm utilises mathematical one-way functions ("Can the reader say what two numbers multiplied together will produce the number 8,616,460,799?") to ensure that any message encrypted with either key can only be decrypted by the other. Fundamentally, if I run a website and publish my public key then you will know that only the holder of the private key pair will be able to correctly decrypt any information that is encrypted with this public key. Public keys are also signed by trusted parties so that I know that i'm getting this keys from a trusted source. This sounds great, why do we need symmetric keys when public key encryption provide a secure way to communicate...it's all about performance, public key cryptography is slow therefore we need to use another method to share large amounts of information.
# Symmetric key encryption
Symmetric key encryption, like the name suggests uses only one key. Both parties have the same key and encrypt and decrypt messages with this key. The difficulty with this method of encryption is that it requires both parties to know the key, with some technologies this is not a problem; If you were setting up a VPN you could share the key with each party that you require secure communications with, however this encryption type would not suit the distributed and "anonymous" nature of the internet.
# How these keys are used within HTTPS
Public key encryption is utilised to authenticate the remote system whereas symmetric key encryption is utilised to encrypt data between the client and server. What happens when I navigate to https://hackmyweb.app? Let's skip over DNS and HTTP and we're not going to go into all of the detail associated with TLS (Transport Layer Security) handshakes, but let's try to understand what's going to happen:
- My computer (the client) resolves the remote address and tries to connect to that via a secure method
- The remote computer (the server) replies with a certificate; this is a public keys signed by another public key (normally a certificate authority, such as Let's Encrypt).
- The client will then look to confirm that the certificate issued is valid and therefore is associated with the server that it's trying to locate.
- The client and server now have a secure way to communicate; the client can encrypt information with the server's public key and the server can decrypt the message with its private key. When the server needs to send a message to the client, it can encrypt it with it's private key and the client can decrypt it with the public key
- As mentioned previously, public key encryption is slow, so this secure channel is used to agree on a suitable symmetric encryption algorithm and share information that is used to generate the symmetric key.
The above "glosses" over some of the complexity...but this highlights the first area of hardening that we're going to look at. These symmetric encryption algorithms can vary wildly, we need to makes sure we're not using something that's vulnerable.
Part two within this series, testing your server for HTTPS vulnerabilities, is available within the following article.