HTTPS Security | SSL | TLS | Network Protocols | System Design

In this video I explain the everything you need to know about HTTPS and Security in the context of System Design Interviews
System Design Interview Basics Playlist:
► • System Design Intervie...
AWS Certification:
►AWS Certified Cloud Practioner: • How to Pass AWS Certif...
►AWS Certified Solution Architect Associate: • How to Pass AWS Certif...
►AWS Certified Solution Architect Professional: • How to Pass AWS Certif...

[@lovishgoyal2814]

Just 1 word........ you are awesome

[@smritisharan-sfdcamplified]

beyond amazing

[@M_Novman]

Superb!!!! Thanks!!

[@ShekharKumar-sg3gd]

Congratulations @ByteMonk you are doing great job.

[@m3hdim3hdi]

Thank you great explanation

[@yrusTube]

Hi nice video and illustrations. What do you use for the illustration and animation?

[@kumarorlama]

At 13:02, when server sends the CA-private key-signed SSL cert, can middle man just intercept and decrypt using the public key of the signing authority and get access to the public key within SSL ? This CA very verification is still not clear to me

[@ByteMonk]

My apologies for the late response. MITM getting access to the public key is not a problem. The name "public" implies it's open to all. The importance of the (public key + SSL cert) is for the client to trust that the Server is the right entity. So if a MITM somehow intercepts the (public key + SSL cert) from the server to client and modifies it. The client will know that, because any modified SSL cert would be invalidated by the client(browser).

[@ByteMonk]

Part 2: However if the MITM pretends to be a client and tries to access a secure page, server will have its own authentication setup to tackle that. Which is also known as "client authentication." Its a long answer if you wish to understand, read on.. :)
During the SSL/TLS handshake, the server can use a feature called client authentication to verify the identity of the client. This is an optional feature that can be enabled by the server, and it is used when the server needs to authenticate the client before allowing access to a protected resource.
1. Here's how client authentication works:
2. The server requests the client to provide a client certificate during the SSL/TLS handshake.
3. The client responds with a certificate containing its public key.
4. The server verifies the client certificate by checking the digital signature on the certificate using the public key of the Certificate Authority that issued the certificate.
5. If the client certificate is trusted, the server can authenticate the client and allow access to a protected resource.