TLS , How http, https works - sharmasadhna/mylearnings GitHub Wiki

https://www.youtube.com/watch?v=AlE5X1NlHgg

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

  1. http server runs on port 80, This port no can be anything from your application, but most port who do google.com, implicitly port 80
  2. https server on port 443
  3. http/https generally runs over TCP (statefull), but http/https can also runs on UDP. http/https(stateless protocol), and needs httcp only for transferring the data.

How vanilla http works:

  1. Client opens TCP connection on server (browser do when type google.com)
  2. Client sends "request" to server
  3. Server replies "Header+data" // server can do many operations here, setting cookies, depending on actual data, so this is time taking op, latency caused
  4. Client closes TCP connection (in older versions closed for every request,)

This is insecure, no checks performed

How https works (general)

  1. Client opens TCP connection on server (browser do when type google.com)
  2. HANDSHAKE --> this process differs based on TLS version,
  3. Client sends "request" encrypted by symmKey to server, this sending by encrypting is done at layer 7/6... For TCP it's just a data
  4. Server decrypts "request" using symmKey, process it, encrypt again with symmKey and replies "Header+data" (encrypted response) //this takes longer than vanilla http, because of decryption involved
  5. Client closes TCP connection (in newer versions do not close after every request but keep it alive)

HANDSHAKE --> both client and server agrees for a symmetric key, used for encryption/decryption of data to be transmitted (difference between symm & asymm encryption, https not using assymm ?)

TLS versions differs on how symmKey is generated for HANDSHAKE

After Client opens connection TLS 1.2 ()

  1. Client : Hey I am client, I support all these ciphers, ex: 4 Key exchange, RSA, diffie-heilmann for key exchange and x,y,z symm algo etc... (ex: Internet explorer supports something, Chrome supports something else)
  2. Server : OKAY, we will use "x algorithm" for key exchange, "y alogorithm" for symmKey generation. It chooses highest level of "x and y" availaible for client. Server : take my "certificate" (publicKey of server + many other things)
  3. Client : takes server publicKey, use it to generate master sessionKey(symmKey), encrypt sessionKey with publicKey of server, and send to server
  4. Server : receives sessionKey by decrypting using it's private key

NOW both Client and server have sessionKey

  1. Server : I am finished, let's start communication (FIN)
  2. Client will start by sending requests, and communication begins

ISSUES with TLS 1.2: insecure key exchange over n/w and many steps only for handshake

  1. encrypting symmKey and sending over network --> anyone hacks server PrivateKey, can decrypt all communication between client and server (difficult but possible)
  2. 4 round trip between Client and server before actual data transfer, --> slow

SOLUTION to TLS 1.2: Diffie-Helmann --> TLS 1.3

  1. send data about the sessionKey, not actualKeys and let both Client and server generate sessionKey for themselves
  2. sessionKey (privKey) = PrivKey_Client + PubKey_Client + PrivKey_Server,
  3. never ever send PrivKey_Client or PrivKey_Server, can send PubKey_Client, or (PubKey_Client + PrivKey_Client = publicKey) or (PubKey_Server + PrivKey_Client = publicKey)

NOTE:

  1. Keys are only numbers
  2. PrivKey_Client & PrivKey_Server, are not kept, they are destroyed each time, and regenerated again.

TLS 1.3

  1. Client : Hey I am client, I support diffie-heilmann (only choise with TLS 1.3), choice for what symm Algorithm to use is given to server Client : generates PrivKey_Client + PubKey_Client, and sends PubKey_Client and (PrivKey_Client + PubKey_Client)
  2. Server : generated PrivKey_Server, use (PrivKey_Client + PubKey_Client)+PrivKey_Server = Got sessionKey (privKey) Server : sends PubKey_Client + PrivKey_Server to Client, handshake finished ...
  3. Client will use from server this (PubKey_Client + PrivKey_Server) + PrivKey_Client = Got sessionKey

Now, client and server actual Data begins

Key exchange is secure and both Client and Server have the masterSessionKey in 2 round trips only so faster also

https://www.youtube.com/watch?v=PPt7yvBtGRI

https://www.youtube.com/watch?v=r1nJT63BFQ0

Still ISSUE: : with IP spoofing, one can present itself as Client or Server, because there is no way, to prove that they are Client or Server. (IP address is not the proof, at router someone can sniff it and change). For example in 1st Step, in spoofer can intercept PubKey_Client and (PrivKey_Client + PubKey_Client), and generate master session Key, and send it's own keys, and Client also generates session key for same... and communication happens between wrong parties. This was because Client had no mechanism to ensure that the Key received from Server are from genuine server.

Checkout http://www.steves-internet-guide.com/ssl-certificates-explained/ for more information

Solution : Certificates from Certificate Authority

  1. Client have Root certificates installed in the OS, Browser have all the certificates from CA (ex: verizon) from all around the world
  2. Server request the certificate from CA, and install certificate on their WebServers, certificate = (serverPubKey + signed with CA privKey) their is whole chain of certificate until Root certificate.
  3. Client says "hello" 1st step from TLS 1.3, server receives PubKey_Client and (PrivKey_Client + PubKey_Client)
  4. server sends certificate + (PubKey_Client + PrivKey_Server = this is some randomNo)
  5. Client verifies certificate, (decrypt with Root certificate) finally get PubKey_Server --> send response to server, verified, server generates master SessionKey
  6. Client takes (PubKey_Client + PrivKey_Server)+PrivKey_Client, generates master sessionKey.

Now, when someone sniff and send their own publicKey in their certificate, since it's not genuine, Client will not verify this... and cannot proceed.

Said everything, 100 % security is not guaranteed, CA were also hacked in past.