How Web Browser Encryption Works

We hear that the connection between our browser and a website like amazon.com is encrypted when we use ‘https’ but how does that actually work?

A few concepts before the explanation:

• • Key means password
  • Some passwords are really big. They are so big they are like a large file and has structure to it. We call those files/keys “certificates” for this discussion.
  • Public key encryption – this is a key which has two parts. The public part is used to encrypt and the private part is used to decrypt in its simplest forms. That means that once a web browser encrypts a message with the web servers public key, the browser or anyone else that has the public  key can’t decrypt that message.
  • Symmetrical key encryption – both sides use the same key to encrypt and decrypt the message

When our browser connects to a server with the ‘https’ protocol, it is asking that the connection be encrypted so that our private information/ communication can not be stolen by someone watching the interaction between your computer and the server.  Here is what goes on:

• • The server sends your web browser a certificate which is the server’s public key, and some evidence that this public key actually belongs to this server.
  • Your browser verifies the evidence in the certificate, to confirm that it has the proper public key for this server.
  • Your browser creates a random and new symmetric key to use for its connection to the server. It encrypts this symmetric key under the servers public key. to safeguard and prevent anyone form stealing it because we plan on using it to encrypt/decrypt further communication.
  • The server decrypts this messages from the browser using its private key and now has this new secret key.
  • Your browser and the server know a shared secret key  or password  but no one else does.
  • Anytime your browser wants to send something to the server, it encrypts it under this key and the server decrypts it upon receipt. Anytime the server wants to send something to your browser, it encrypts it under this key and your browser decrypts it using the same key

So what does all this mean? It shows that web browsing can be extremely secure with various sites using different levels and sizes of key encryption. Because we glanced over how the browser knows that the public key belongs to the server you are attempting to connect to, it might be helpful to do another high level discussion of that exchange. In general it happens quietly without any knowledge on our part… however at times we can receive an error message from our web browser claiming that the site is bad or there is an error or someone is watching us and that the site is dangerous – how did the browser determine this?

1. Your browser has a list of public keys from different Certificate Authorities (CA) that have paid to be included in your browsers list of predefined authorities. Different browsers have different lists of CA’s so keep in mind if you find a trusted site suddenly shows this message after a browser update that his might be the cause. These CA’s saves us time and effort of having to import keys directly ourselves into our browser. While convenient, we do it at the expense that we must trust anything that has been signed by anyone in the chain including bad guys. Note: it is possible to forge a certificate and you will receive no warning when it has been done with one of the preloaded certificate authorities from your browser which is very rare.
2. To use this certificate authority (CA), the server you are connecting to needs to have their public key signed by the private key of the certificate authority in advance and the company will pay money to the CA per year to determine the level of security based on cost per certificate. The more money, the more bits used to encrypt the servers public key.
3. Now to answer how the browser thinks the certificate is bad – it uses the public keys preloaded from the paid certificate authorities and/or ones you have imported yourself. If you do not have the key then it issues the warning message. If you accept and load the key into your browser for sites that are self-signed (most browsers will prompt you after a big scary warning) – you will not be warned again.  Unfortunately unless you know something about the certificate such as it is self signed and were told by someone of authority in your company –  it is much safer to not accept the certificate and move on to another website.
4. On the other hand, if you are a small company and you have been told that your company has self-signed their certificates and to import the company’s CA or the public key then you should do that.  You will only have to do this once and in the future, if someone attempts to trick you then you have absolute proof that is a bad certificate. Unfortunately, a forged public certificate will be quietly accepted by your browser and you will never know. This is an edge case and very rare.  How ironic but its the PKI (Public Key Infrastructure) that is to blame here and not the encryption that failed.  PKI makes it possible for servers and browsers to work without any previously knowledge of each other. It is almost always better than self-signed certificates  which are public keys has been signed with its own private key because self-sign are really only practical for small sites where you have agreed in advance what  you plan on doing. After everyone agrees, you may have better security and any attempt to forge a certificate will be instantly discovered in the future. An especially great practice is to load the local CA for your company ahead of time because then you will never see the scary warning message that the certificate is untrusted. You also mitigate an attack vector should the PKI being targeted as your certificate is still secure.

I hope this discussion explains the advantages and why ‘https’ is very trustworthy in your day to day Internet browsing and should be your first choice when available. Don’t let self-signed public keys scare you away unless you will be entering personal information like passwords, etc.  You can also try this interactive version at this link. https://tls.ulfheim.net/

Additional References for those that want to learn more:

How is it possible that people observing an HTTPS connection being established wouldn’t know how to decrypt it?

How do the processes for digital certificates, signatures and ssl work?

Purpose of certificates signed and trusted by CA

Why is faking SSL certificate difficult?

Why is HTTPS not the default protocol?

Is visiting HTTPS websites on a public hotspot secure?

Cloudflare and its keyless SSL idea – great ssl/tls discussion

I think those articles should give you an excellent understanding of SSL, how it works, and why it is designed the way it is.

If that’s not enough, you must have more more more, here are some articles from Wikipedia:

How certificates work

How SSL works