Tag: cybersecurity

Categories
Cyber Security Tech

Basics Of The Internet: TCP, HTTP, and HTTPS

Recently, I tumbled into a YouTube video of a documentary of a New York Times journalist who got hacked in a hacker conference. The result was mind-blowing. He got a password added to his phone account. His computer got hacked and all of his bank accounts are compromised. It’s entertaining to watch, but it doesn’t sound fun if that happens to me and you. That video got me interested in learning about network security. I’m going to put down some notes with some basics.

TCP connection

Transmission Control Protocol(TCP) is the foundation of communication between two computers on the internet. A TCP connection starts with a three-way handshake between two computers.

For example, when we want to browse lokarithm.com from a laptop computer. Here’s what happens behind the scene of the browser. When we hit ENTER after typing the URL(i.e. lokarithm.com) in the address bar, the URL will be sent to the Domain Name System(DNS) server using User Datagram Protocol(UDP) on port 53. Then the DNS will find the IP address of lokarithm.com and send it back to the browser. Now the browser knows where to visit. It will start a three-way handshake process with the server to establish a TCP connection.

The three-way handshake of a TCP connection

The Three-way Handshake

  1. The browser sends a TCP segment with an SYN(Synchronize Sequence Number) flag set to 1. Basically it’s saying “hi” to the server and see if something is there. That’s the first handshake.
  2. When the server sees the TCP segment, it replies with a TCP segment where the SYN and ACK(Acknowledgment Number) flags are both set to 1. The server simply just waves back to us and says “oh hey, I’m here”. That’s the second handshake.
  3. Now we know that the server can hear us. But the server doesn’t know that we can hear her yet. So the browser will send a TCP segment with ACK flag set to 1 back to the server. Now, the server knows we could hear her. That’s the third handshake. Then, the two machines can start talking to each other.

HTTP vs HTTPs

HTTP stands for Hypertext Transfer Protocol. It’s a protocol to transfer data between computers over the internet. It sits on top of the TCP/IP protocol. Basically transfer data in plain text.

Hypertext Transfer Protocol Secure(HTTPS) on the other hand, is an extension of the HTTP. HTTPS encrypted data with Transport Layer Security (TLS). After establishing the TCP, HTTPS has a few additional steps to make sure the transaction of data is secure. Then the data transfer in between will be encrypted with a session key generated by your browser. Data transferred by HTTPS ensure that even if someone intercepted your data, they cannot see the message unless they have the session key. To understand how HTTPS works we also need to understand the concept of private key and public key.

Private Key and Public Key

Private Key is a bunch of randomly generated characters that can be used to decrypt messages. Public Key is also a bunch of randomly generated characters created with the private key. Public Key can be used to encrypt a message that can only be decrypted by the private key.

Encryption and Decryption

To simplify this concept, imagine I am using my method to encrypt a message “hello” by substituting each character with 1 character after it. For example, if the character is “a”, I will substitute it with the character “b”; “g” will be replaced by “h”; “z” will go back to “a”. So, the word “hello” will become “ifmmp”. I don’t share my secret method of encrypting the message. This secret is similar to a private key.

Now, you are given this message “ifmmp” and you don’t know what it means. But I gave you a box which when you throw in the message that I give you, it will decrypt the message for you. And you will see the actual message, i.e. “hello”. I can give a box like that to anyone who I want them to see my secret message. The box serves the exact purpose of a public key.

Public-key cryptography

In Addition, in an asymmetric encryption key pair, the private key can encrypt a message that only the public key can decrypt. For example, Alice signed a message with her private key. Then anyone who has Alice’s public key can decrypt that message. Therefore, anyone who has Alice’s public key can verify that a message is indeed signed(encrypted) by Alice. Because she is assumingly the only one that knows the private key. Note that you should keep the private key private and not sharing it with anyone.

That’s how private key and public key work. The actual encryption process is more complicated, but you got the idea.

The HTTPS magic

Now, imagine you’re visiting lokarithm.com this time via HTTPS. After establishing a TCP connection, a TLS handshake will happen before the data transfer occurs. Here’s what happens:

  1. The browser will initiate the handshake with a “hello” message. The message includes which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the “client random“.
  2. The server will present two things to your browser: A TLS certificate, a digital certificate signed by a Certificate Authority(CA), to your browser. A “server random,” another random string of bytes that’s generated by the server. It’s basically telling your browser “I’m the real lokarithm.com. Here’s my ID issued by the Certificate Authority. You may verify that.”
  3. The browser has a list of trusted CAs when it’s installed. It knows the public keys of those CAs. So it will decrypt the certificate and see whether it’s a valid certificate. The browser will confirm the server is who it says it is.
  4. Then the browser sends one other random string of bytes called a “premaster secret” to the server. The premaster secret is encrypted with the server’s public key and can only be decrypted with the private key of the server. (The client gets the public key from the server’s TLS certificate).
  5. The server decrypts the premaster secret.
  6. At this point, the browser and the server both have the “client random”, “server random” and the “premaster secret”. Both sides use those three pieces of information to generate a “session key“. The session key is only valid throughout the connection session.
  7. The browser sends a “finished” message that is encrypted with a session key.
  8. The server sends a “finished” message encrypted with a session key.
  9. The TLS handshake is completed. The communication will encrypt all the data using the session key.

That’s a lot of handshakes. Actually, there is a different way of handshake called an ephemeral Diffie-Hellman handshake. The rabbit hole is deep. Let’s talk next time.

If my note helped, please consider buying me a coffee😁.

Cheers,
Lok