Things about IT security

Terminology

CA - Certificate Authority - basically a place that your app will trust for its digital certificate.

Certificate - A cert that contains the public key of the corresponding owner that owns the cert.

Handshaking

The www.youtube.com example is good.  When your browser talkes to www.youtube.com, Youtube gives back a cert that youtube owns, and signed by Google CA let's say.  The browser, since Google CA is its trusted CA list, will use the public key of Google CA to first verify that the cert is signed by Google CA, and then grab the public key from the cert.  It then use the public key to encrypt a secret key that the browser generates, and pass back to youtube.com. Youtube.com then uses its private key to decrypt the info from client, and then will start using the secret key the browser generates, and from now on, all information in this channel will be encrypted using this secret key, and this secret key is hard to be deciphered by anybody sniffing the channel.

Self Signed Certificate

Self Signed Certificate is a good thing used by app that does not go through the hassles of having cert to be signed by the trusted CA.  Remember, whenever a service wants to create a cert, it will first have to generate its own public/private key, and submit a certificate signing request to a trusted CA (Google CA let's say), and the trusted authority will sign the request using its own private key, so anyone having the CA's public key can verify that the cert is indeed from the trusted CA.   If you are developing an application in a staging environment (non live), it's quite a hassle to get trusted CA to do this process, so you may still generate your own key pair (public/private), and then you also create a certificate authority that also has its public/private key pair. Now you still submit CSR to this "certificate authority" and do the needy signing.  However, for your caller testing this service in staging environment, obviously the caller will not find this special "CA" to prove the certificate validity, but the caller can be configured to point to this special CA to do the necessary verification, and eventually grab the public key from the cert, and do all necessary business. This is called "self-signed certificate".

What is Root CA? Leaf CA? Man in the middle attack? 

https://searchsecurity.techtarget.com/definition/certificate-authority

https://www.thesslstore.com/blog/root-certificates-intermediate/

What is SSL and TLS

TLS is successor to SSL.  Both are important for the security of HTTP protocol.

mTLS

(reference:https://developers.cloudflare.com/access/service-auth/mtls/)

Mutual TLS is a common security practice that uses client TLS certificates to provide an additional layer of protection, allowing to cryptographically verify the client information. Basically put it this way, both client and server will ask for each other's certificate, that's where the word MUTUAL coming from: 

"In most cases when you try to access a secured HTTPS/TLS endpoint, you experience only the client-side check of the server certificate. The purpose of this check is to ensure that no fraud is involved and the data transfer between the client and server is encrypted. In fact, the TLS standard allows specifying the client certificate as well, so the server can accept connections only for clients with certificates registered with the server certificate authority, or provide additional security checks based on the information stored in the client certificate. This is what we call “Mutual TLS” - when both sides of the connection verify certificates. See the video below that gives you an introduction to mutual TLS and how it can be used to secure your APIs."

https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

- This article explains very well for something missing in the above cloudfare diagram.  Essentially, when client first sends hello to server, it sends over a client random key.  When server first returns the "hello" message, it also sends over a random server key.  When the handshake is establishing (no matter it's TLS or mTLS), essentially client will send over one thing called "premaster" secret with server's public key, and so server can decrypt it using its private key.  With the information server-random, client-random and premaster secret, both sides can computer a symmetric key for all other subsequent information, and this is something that only both sides will know, which secures the communication channel.

What is end to end encryption (E2EE) then?

Previously when telegram promises that it has end to end subscription, while people thinking whatsapp cannot do, essentially it is to promise that even the communication software has no way to decrypt the message (have no key to decrypt).  That is, let's say you use telegram to send a message to Person B, the encryption cannot be decrypted whatsoever besides you and and Person B.   Recently people complaining Zoom , although promising end to end encryption, essentially it may not be the case.  So what is the diff here? Imagine this case:

1. You send over something to a whatsapp friend, where whatsapp guarantees end to end encryption. Your message to whatsapp server is encrypted (TLS or mTLS, does not matter)
2. Whatsapp gets the message, and forwards to the friend, over encrypted channel.
3. However, this does not stop the immediate middle - whatsapp, to do whatever it can on the message. Don't forget in this case, both users are talking to the whatsapp server in the middle, so whatsapp server can do its "business"

So end to end encryption tries to guarantee that even the middle provider cannot interpret the message but simply just forwarding/routing. E2EE simply is a way that encryption take place between two users entirely, but no middle server in between do handle the exchange.  E2EE can be designed using TLS scheme though.  

private/public/asymmetric encryption

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

Reference

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

HSM

OAuth