About

Intro

Welcome to the demo! You can find this text either by clicking on the info button in the top right corner of the home page, or by clicking the about link at the bottom.

This page will serve as a guide throughout the demo to clarify steps in the process, as well as connect the concepts in the demonstration to what actually happens in the real world.

Not Secure

If there are no protections in place for encrypting the messages you send, the messages are freely available to anyone listening in. When there's no HTTPS protocol in place, this is exactly what's happening!

Entering any sensitive information into a site marked as "Not Secure" is equivalent to shouting your credit card number to the cashier at the supermarket. Anyone that cares to listen in will have enough information to purchase things on your behalf.

The HTTPS Protocol

The http:// that sits in front of any url stands for Hypertext Transfer Protocol, and it's used to transer text from place to place over the internet (Like this website!)

HTTPS is a layer that is added on top of the HTTP protocol, that ensures the messages that are sent are Encrypted.

The two text boxes with the line between them represents the HTTP protocol. This demo shows the steps that go into adding the encryption to the existing protocol.

Client Hello

Alice's message seems very cryptic right now. It's hard to explain it all right now but here's what you need to know:

  • RSA is an example of an asymmetric cipher.
  • AES is an example of a symmetric cipher.

We'll learn more about the difference between asymmetric ciphers and symmetric ciphers when we talk about the server hello.

The client hello is one of two messages that are unencrypted during the HTTPS process, the other being the server hello. This means that whoever is in charge of your internet, your ISP or workplace, will be able to see the delivery target. In other words, they'd be able to see that you are visiting youtube.com, but they wouldn't be able to know what video you're watching.

A note on VPNs

VPNs have become quite popular in recent years mostly due to advertising. While it is true that a VPN can make your connection more secure, some of the advertising and promotion you hear may give the wrong impression.

A VPN is essentially just a program that directs all your internet traffic to another computer, where that computer makes all the requests for you and sends them back.

When you use a VPN, your ISP will no longer be able to tell what websites you visit, but they will be able to tell that you're using a VPN. Moreover, instead of your ISP knowing what websites you visit, your VPN provider now has access to that information because the client hello is unencrypted.

Server Hello

Communicating securely with another party over the internet using the HTTPS protocol requires both an asymmetric cipher, and a symmetric cipher. In the server hello, the server decides which systems to use based on what the client (in this case, Alice) said they supported.

Asymmetric and Symmetric Ciphers

There are two types of cryptosystems, or ways in which to send an encrypted message. As stated above, HTTPS uses both.

  • Public Key/Asymmetric cryptosystems are systems in which a message is encryped with a public key, and then can only be decrypted using a private key. In the HTTPS process, this cipher is used to share the key for a private key cryptosystem

  • Private Key/Symmetric cryptosystems are systems in which a message is encrypted and decrypted with the same, or closely related keys. These systems are more secure because no information is made public besides the encrypted version of the message being sent.

More on Asymmetric Ciphers

Bob just sent Alice his RSA Public Key. The reason he can send an encryption key like this is because it's meant to be public. Even though Bob's key is public, anything encrypted with that key can only be read by Bob because only Bob knows his own private key.

The Safe Analogy

If the public and private keys are confusing, think of it instead like this: Alice wants to send a message to Bob that can only be read by Bob, and nobody else. To accomplish this, Bob sends a metal safe to Alice. The safe is unlocked, and only Bob knows the combination to unlock it.

Alice places the message she wishes to send in the safe, and locks the safe. She then sends the safe back to Bob. Alice can now be confident that the only person that can read the message is Bob.

In the HTTPS process, Alice places a key to a symmetric cipher in the safe, and sends it to Bob. Only Bob and Alice know the key to the symmetric cipher, so the key exchange is complete!

Key Exchange

A lot just happened, let me break it down:

  1. Bob sent Alice his public key
  2. Using Bob's public key, Alice encrypted her passphrase.
  3. Alice sent the encrypted passphrase to Bob.
  4. Using Bob's private key, Bob decrypted Alice's passphrase

Rewritten using the Safe Analogy

  1. Bob sent Alice his unlocked safe
  2. Using Bob's safe, Alice put her passphrase in the safe and locked the safe.
  3. Alice sent the safe to Bob.
  4. Using Bob's ability to open the safe, Bob unlocked the safe and revealed Alice's passphrase

Why can't Eve replicate the message?

Eve never gained access to any materials that would allow here to get the passphrase. If Eve was watching every exchange between Alice and Bob, all she would have is:

  • The ClientHello
  • The ServerHello
  • The Public Key/Unlocked Safe
  • The Encrypted Message/Locked Safe

What was the poitn of all this?

The point of the key exchange is to use a symmetric cipher. The thing stopping Alice and Bob from using a symmetric cipher was that they didn't have a shared secret. The key exchange is the act of exchanging that secret, so now we can use a symmetric cipher instead.

Why not always use an asymmetric cipher then? An asymmetric cipher is weaker. It needs two keys that need to be related enough that the cipher works, but distant enough that nobody can deduce the private key in a reasonable amount of time. While RSA is pretty secure, it is crackable.

Additionally, at least with RSA, the message it can send is limited to a certain size. In this demo, the limit is set to around 80 characters, so it should cover most passphrases.

So why share the passphrase?

The passphrase is for the symmetric cipher. Remember that a symmetric cipher user the same key for both encrypting and decrypting.

With a shared, private key, Alice can send a message to Bob, and Bob can send a message to Alice symmetrically. That way resources can freely and securely be shared between Alice and Bob without requiring the whole song and dance that goes into an asymmetric cipher.

Conclusion

HTTPS is a protocol, or procedure, for securing the web's standard communication. At it's core, it's just another layer built on top of HTTP called TLS, or the Transport Layer Security protocol.

HTTP on its own handles the sending of messages. The layers that TLS adds are as follows:

  • Client Hello
  • Server Hello
  • TLS Handshake (Key Exchange)

After the handshake, the server and client can freely communicate back and forth.

How can you trust the server?

Making sure the server is who they say they are is quite important. In the safe analogy, Eve could technically get access to the key. If Eve snatches the safe while in transit, and sends Alice an exact replica of the safe that Eve can open, Alice will assume its Bob's and be giving the passphrase to Eve. If Eve then puts the passphrase in Bob's safe and sends it back to Bob, Alice and Bob will have no clue that they've just been tampered with.

This is where a Certificate Authority, or CA comes in.
The CA is an organization that keeps records on the servers to verify that a server, is the same as it's url, and can be trusted. For a safe, it would be equivalent to a patch or stamp on the safe, that it's not only Bob's safe, but that the Safe has been recognized by an external CA to be trustworthy.