An important point that's worth mentioning, otherwise the server-hello phase would be insecure, the client and server both have a trusted authority they could rely on for authenticating each other. The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
Yes because a certificate authority verified a domain owner and signed its data with its private key, that signature is included in the certificate , and the public key of known certificate authorities are stored in the browser
The client has a list of CA certs that it trusts, so it will accept any server cert that is signed by one of them. TLS can also be used for two-way authentication. Also for secure communication between different parts of your own organization, you can create your own CA cert and install that at the endpoints so they can trust each other.
How does the server know that the client is not the hacker that sits in the middle? Namely, how does the server knows that session_key is authentic and generated by the client, but not by the hacker in the middle?
HTTPS is HTTP + TLS (Transport Layer Security) TLS is a handshake process between the client and server with asymmetric encryption to exchange a session key used for Data Transmission with symmetric encryption.
@@noorzanayasmin7806 SSL cert is the certificate you bought from your hosting or anywhere you bought it from, which contains the public key, and when you create your csr, you will be given with the verified private key that can only be paired with your public key.
The session key isn't directly swapped between the client and server, even with asymmetric encryption. Instead, they exchange a random string of bytes, often referred to as a 'pre-master secret' or 'nonce', which serves as the basis for generating the session key on both ends using the algorithms previously agreed upon in the cipher suite exchange.
I like that you didn't mention TLS 1.1 and below. No need to teach something that's going out the door. And thanks for pointing out the ciphers. In teaching others about TLS, I've found ciphers to be the hardest concept for people to grasp.
I think that everyone needs to understand the ciphers involved, but most people aren't going to be concerned with the technical details of the cryptographic algorithms.
I can tell that you are a scientist. Wouldn't surprise me if you had a PHD. Really an articulate presentation with virtually no flutter. A rare sight on YT.
question: Diffie-Hellman (DH) is used for key exchange, the client and server exchange public keys and use them to generate a shared secret key that is used for symmetric encryption. Yes he share a public key also...
Bravo. 👏 This is a very succinct high level explanation. I’m already somewhat familiar with the handshake, but this does a fantastic job summarizing things in an approachable fashion without diving into too much detail. Great thing is, there’s still plenty more to dive into as well and this provides a well structured guide on how to do that.
it was really great fast and everything important was in this video thank you I watched more than 7 videos and put more than 1 hour to find you :) Thanks I understood everything clearly :)
Along with the top comment here, I think it is helpful to understand that step #2 Certificate Check involves the client cross referencing that the DNS name they resolved matches the hostname presented on the server's certificate. Otherwise, the TLS handshake will (appropriately) fail because even though the server certifcate may be valid and trusted, the server presenting it is not truly associated with it.
Thanks for the video. I think you could have explained more about what TLS and SSL are specifically, but thanks for explaining in detail how HTTPS works.
And one more main reason for not using symmetric key is : When server sends the public key only to the client. Not the private key.. so the client only can encrypt the data using public key it has received with the certificate, not able to decrypt any data came from the server. Thats why we use seasion key exchange..
SSL, TLS, and HTTPS are all cryptographic protocols used to ensure secure communication over the internet. They play a crucial role in protecting sensitive data transmitted between a client (such as a web browser) and a server. Let's explain each of these terms: SSL (Secure Sockets Layer): SSL is an older cryptographic protocol that was initially developed by Netscape in the 1990s. It was widely used to provide secure communication over the internet, especially for websites handling sensitive information like login credentials or credit card details. However, due to security vulnerabilities and weaknesses found in SSL, it has been largely deprecated and replaced by its successor, TLS. TLS (Transport Layer Security): TLS is the successor to SSL and was introduced as a more secure and robust cryptographic protocol. It operates at the transport layer of the internet communication stack and ensures secure data transmission between a client and a server. TLS uses a combination of symmetric and asymmetric encryption algorithms to establish a secure connection. The latest version of TLS at the time of writing is TLS 1.3, which has further improved security and performance over previous versions. HTTPS (Hypertext Transfer Protocol Secure): HTTPS is not a separate protocol but rather a combination of HTTP and TLS (or SSL in older implementations). It is the secure version of the standard HTTP protocol used for transmitting data between a client's web browser and a web server. When a website uses HTTPS, it means that the data exchanged between the client and the server is encrypted using TLS or SSL, ensuring that it cannot be intercepted or tampered with by unauthorized parties. When a user connects to an HTTPS-enabled website, the following steps occur: The client (web browser) sends a request to the server, indicating that it wants to establish a secure connection using HTTPS. The server responds with its SSL/TLS certificate, which contains the server's public key and other details. The client verifies the authenticity of the certificate by checking its validity and whether it is signed by a trusted Certificate Authority (CA). If the certificate is valid, the client and the server perform a handshake to negotiate the encryption algorithm and establish a secure connection. Once the secure connection is established, all data transmitted between the client and the server is encrypted and secure from eavesdropping or tampering. In summary, SSL and TLS are cryptographic protocols used for secure communication, with TLS being the more modern and secure version. HTTPS is the combination of HTTP and TLS (or SSL) and is used to ensure secure data transmission over the internet, especially for sensitive information. Enabling HTTPS on websites is crucial for protecting user data and ensuring a safe browsing experience.
Thanks a lot! This is very useful! 03:47 it s hard to follow due to -I think- you using indefinite artical "a" (as in "a symmetric") vs the way "asymmetric" is pronounced. Also the fact that you added "symmetric encryption" to the diagram AFTER you mentioned your point. Sorry for nit-picking, just hope this would help anyone else
Public keys were trapped sometimes and that's why no public keys travel. Mostly by NAT re-config. SSL means a set of algorithms accepted between with certificate means that the binary coded files used for decryption. Key means algorithm. Why public and private keys means that public used for encryption of the algorithm of choice and private is end to end algorithm transfer and use. About a thousand algorithm exchanges for a single transaction. So don't try.
DH alone is prone to man-in-the middle attack. So the certification verification is vitally important which the video doesn't cover much. Basically the server send a signature which is some private-key encrypted digestion of server identity information. The client then verify the public key through chain-of-trust by layers of authorities that issue certifications (system root authority is trusted unconditionally unless your local system is messed up). Using the verified public key the client decrypt the signature and compare the result to the digest generated through the negotiated digest/hash algorithm. If everything checks out, the server identity is trusted because only the private key owner is able to generate that signature.
I never wanted to understand those trivial details until I came across developing my own softwares...these things should be taught coherently together, not separately...
Wonderful video explaining the internal working of SSL TLS. This got me wondering that about what other questions related to HTTPS SSL TLS do web developers need to know the answers to to be able to do their jobs. I doubt they need the internals of how HTTPS SSL TLS work. Web developers just need to understand 1. Libraries that enable http requests and responses - client side and server side. 2. What are the steps in getting a certificate 3. what sort of attack are prevented through this kind of encryption 4. what are the libraries objects methods that enable https on both client side and server side 5. what are the steps relevant to setting up https tls and ssl on self hosted and cloud hosted servers
How does the client identify itself in the subsequent requests in the phase 4? Does the server need to keep in memory all the thousands of client specific session keys?
I have 2 doubts 1. which public key and private key is known as assymetric keys .on server under .ssh present keys or ssl keys 2. Secure data trasmission between client and server using client symmetric key or client will use server public key for encryption which will decrypt by server private key and server will use client symmetric key for encryption which will decrypt by client symmetric key
For 2nd question - a) AES, DES or similar algorithms are used for generating the session key (secret key ; symmetric key) b) This session key is then encrypted using the server's public key got from the digital certificate. c) The server on receiving this, decrypts it using its private key. d) Now, the client and the server have the session key.
I have a question. When this hand shake happens? It does for the first request and keep this connection stablished for the next calls or it does for every request? Im having difficult to imagine it if we have clusters, if the connection is kept alive.
Hi, thanks for your videos, very helpful. I'm writing my master thesis and I'm looking for a way to compare TLS cipher suites about their computational cost. My main idea is about counting number of operations and related weigth for each algorithm in every cipher suites, but I can't find any information about these metrics or just a tool to implement RSA (e.g.) and understand the computational weigth, in order to compare the main cipher suites. Can you or anyone else give me any input to implement this metric? Many thanks
I used to think after TCP Handshake we start transmitting data and I forgot about the other two steps (Certificate check and Key Exchange). I was wrong(((( Thank you
An important point that's worth mentioning, otherwise the server-hello phase would be insecure, the client and server both have a trusted authority they could rely on for authenticating each other. The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
Yes because a certificate authority verified a domain owner and signed its data with its private key, that signature is included in the certificate , and the public key of known certificate authorities are stored in the browser
I was wondering about this. Thank you!
The client has a list of CA certs that it trusts, so it will accept any server cert that is signed by one of them.
TLS can also be used for two-way authentication. Also for secure communication between different parts of your own organization, you can create your own CA cert and install that at the endpoints so they can trust each other.
How does the server know that the client is not the hacker that sits in the middle? Namely, how does the server knows that session_key is authentic and generated by the client, but not by the hacker in the middle?
@@alexandermiasoiedov6637 The man in the middle should not be capable of decrypting the client's message.
Comprehensive and easy to understand. The best part is that the video was short!
I love the audience of this channel, very polite, graceful and intellectual.
Thanks.
HTTPS is HTTP + TLS (Transport Layer Security)
TLS is a handshake process between the client and server with asymmetric encryption to exchange a session key used for Data Transmission with symmetric encryption.
is the key the SSL certificate verified by Certificate Authority?
You also watched the video? Interesting!
@@noorzanayasmin7806 SSL cert is the certificate you bought from your hosting or anywhere you bought it from, which contains the public key, and when you create your csr, you will be given with the verified private key that can only be paired with your public key.
Your explanation is easy to understand than watch the video
Good summary of the video!
I love how the audience effectively participating in Comments Sharing knowledge. That's the beauty of well educated environment.
Best animation aesthetics ever. Pure joy to watch.
Direct to the point, clean, and easy to understand. Great content!
You missed the phase where Client has to validate is Certificate is signed by the trusted CA.
The session key isn't directly swapped between the client and server, even with asymmetric encryption. Instead, they exchange a random string of bytes, often referred to as a 'pre-master secret' or 'nonce', which serves as the basis for generating the session key on both ends using the algorithms previously agreed upon in the cipher suite exchange.
yo my moroccan bro can we contact thru fb or ig or whatsapp?
I like that you didn't mention TLS 1.1 and below. No need to teach something that's going out the door. And thanks for pointing out the ciphers. In teaching others about TLS, I've found ciphers to be the hardest concept for people to grasp.
I think that everyone needs to understand the ciphers involved, but most people aren't going to be concerned with the technical details of the cryptographic algorithms.
Thank you bro, as my father always said, clean and easy, I want your room clean and attitude easy.
I can tell that you are a scientist. Wouldn't surprise me if you had a PHD. Really an articulate presentation with virtually no flutter. A rare sight on YT.
This was so so helpful straight to the point ! Worth every second ❤
It is very nice and clean exlaination without messing up terminology..great job
You are very professional with your videos and your teaching; is a suggestion you should do a video with an A.I voice
bytebytego team, i would like to thank you for your videos - they are not only illustrated really well, they are really informative!
question: Diffie-Hellman (DH) is used for key exchange, the client and server exchange public keys and use them to generate a shared secret key that is used for symmetric encryption.
Yes he share a public key also...
Exactly, that's also my surprise he said it doesn't transfer the public key over the network.
@ByteByteGo could you explain it?
You're the best presenter for this kind of stuff!
Excellent channel, well illustrated. A must watch for those in tech risk like me
Best explanation I found on utube about TLS and ssl
Bravo. 👏 This is a very succinct high level explanation. I’m already somewhat familiar with the handshake, but this does a fantastic job summarizing things in an approachable fashion without diving into too much detail. Great thing is, there’s still plenty more to dive into as well and this provides a well structured guide on how to do that.
🎉
Yeah even I was confused about the how does certificate check and key exchange serially happens this video cleared my doubt
Ordered your both system interview books, volume 1 and 2.
Can't wait to read the books!
Are the books worth it?
@@siddharthamohan6382 Definitely.
short and sweet tutorials
really loving your channel
Amazing!!
The best video about HTTPs, I ever seen before!
Bro's animation and explaination are superb. 👍
great explantion and to the point. also tls 1.3 solves forward secrecy problem of tsl1.2
it was really great fast and everything important was in this video thank you I watched more than 7 videos and put more than 1 hour to find you :) Thanks I understood everything clearly :)
Along with the top comment here, I think it is helpful to understand that step #2 Certificate Check involves the client cross referencing that the DNS name they resolved matches the hostname presented on the server's certificate. Otherwise, the TLS handshake will (appropriately) fail because even though the server certifcate may be valid and trusted, the server presenting it is not truly associated with it.
Wow... that is important and helped me today. I was having some problems with a broker and was receiving invalid IP error.
one of the best videos for overview on this.
so nicely explained , Thanks lot , Glad I found this video and channel . thanks again
wow, great and clear explanation! Thank you very much!
HTTPS is not a protocol technically, it is a scheme. The protocols used are actually called HTTP and TLS.
Thanks for the video. I think you could have explained more about what TLS and SSL are specifically, but thanks for explaining in detail how HTTPS works.
And one more main reason for not using symmetric key is :
When server sends the public key only to the client. Not the private key.. so the client only can encrypt the data using public key it has received with the certificate, not able to decrypt any data came from the server.
Thats why we use seasion key exchange..
clean and easy to understand thanks for this one
Thank you - beautifully explained!
perfect straightforward. love it
Your content is fantastic. Thank you.
very clear elaboration and good sharing!, Appreciate!
Great content. Simply explained
SSL, TLS, and HTTPS are all cryptographic protocols used to ensure secure communication over the internet. They play a crucial role in protecting sensitive data transmitted between a client (such as a web browser) and a server. Let's explain each of these terms:
SSL (Secure Sockets Layer):
SSL is an older cryptographic protocol that was initially developed by Netscape in the 1990s. It was widely used to provide secure communication over the internet, especially for websites handling sensitive information like login credentials or credit card details. However, due to security vulnerabilities and weaknesses found in SSL, it has been largely deprecated and replaced by its successor, TLS.
TLS (Transport Layer Security):
TLS is the successor to SSL and was introduced as a more secure and robust cryptographic protocol. It operates at the transport layer of the internet communication stack and ensures secure data transmission between a client and a server. TLS uses a combination of symmetric and asymmetric encryption algorithms to establish a secure connection. The latest version of TLS at the time of writing is TLS 1.3, which has further improved security and performance over previous versions.
HTTPS (Hypertext Transfer Protocol Secure):
HTTPS is not a separate protocol but rather a combination of HTTP and TLS (or SSL in older implementations). It is the secure version of the standard HTTP protocol used for transmitting data between a client's web browser and a web server. When a website uses HTTPS, it means that the data exchanged between the client and the server is encrypted using TLS or SSL, ensuring that it cannot be intercepted or tampered with by unauthorized parties.
When a user connects to an HTTPS-enabled website, the following steps occur:
The client (web browser) sends a request to the server, indicating that it wants to establish a secure connection using HTTPS.
The server responds with its SSL/TLS certificate, which contains the server's public key and other details.
The client verifies the authenticity of the certificate by checking its validity and whether it is signed by a trusted Certificate Authority (CA).
If the certificate is valid, the client and the server perform a handshake to negotiate the encryption algorithm and establish a secure connection.
Once the secure connection is established, all data transmitted between the client and the server is encrypted and secure from eavesdropping or tampering.
In summary, SSL and TLS are cryptographic protocols used for secure communication, with TLS being the more modern and secure version. HTTPS is the combination of HTTP and TLS (or SSL) and is used to ensure secure data transmission over the internet, especially for sensitive information. Enabling HTTPS on websites is crucial for protecting user data and ensuring a safe browsing experience.
LMFAO, did you really just get chatgpt to give you the answer? 💀
Love ALL your videos and channel! You rock!!!
Thanks a lot! This is very useful!
03:47 it s hard to follow due to -I think- you using indefinite artical "a" (as in "a symmetric") vs the way "asymmetric" is pronounced. Also the fact that you added "symmetric encryption" to the diagram AFTER you mentioned your point. Sorry for nit-picking, just hope this would help anyone else
hands down, you nailed it.
Public keys were trapped sometimes and that's why no public keys travel. Mostly by NAT re-config. SSL means a set of algorithms accepted between with certificate means that the binary coded files used for decryption. Key means algorithm. Why public and private keys means that public used for encryption of the algorithm of choice and private is end to end algorithm transfer and use. About a thousand algorithm exchanges for a single transaction. So don't try.
Excellent explanation!! Thanks
4:41 >_"as with most optimizations; it's a bit harder to explain"_
glad go be reminded of it (:
Thank you. And how do you draw these magic architecture pictures?
Very well explained - I love how soothing and insightful it is to go through your videos. How do you record these videos..curious?
Thank you.
For someone who may get confused, he is saying cipher suites not cyber suites
incredible video
That helped me a lot Thanks
Simple, very well explained, thank you!
Fantastic explanation.. Thank you
Love the cool channel name. Thanks for the great info.
Great expalantion, thanks!
As always, great job. Looking forward to the next book.
Very good explanation. Thanks man !
what about root CA, you did not tell about it, this is main thing which helps identify the server otherwise server can be spoofed with MITM attack
Beautifully explained. Classy video. Keep creating. !!!
DH alone is prone to man-in-the middle attack. So the certification verification is vitally important which the video doesn't cover much. Basically the server send a signature which is some private-key encrypted digestion of server identity information. The client then verify the public key through chain-of-trust by layers of authorities that issue certifications (system root authority is trusted unconditionally unless your local system is messed up). Using the verified public key the client decrypt the signature and compare the result to the digest generated through the negotiated digest/hash algorithm. If everything checks out, the server identity is trusted because only the private key owner is able to generate that signature.
bytebytego team, i would like to thank you for your videos , really informative!
This is excellent explanation.
I never wanted to understand those trivial details until I came across developing my own softwares...these things should be taught coherently together, not separately...
Wonderful video explaining the internal working of SSL TLS.
This got me wondering that about what other questions related to HTTPS SSL TLS do web developers need to know the answers to to be able to do their jobs. I doubt they need the internals of how HTTPS SSL TLS work.
Web developers just need to understand
1. Libraries that enable http requests and responses - client side and server side.
2. What are the steps in getting a certificate
3. what sort of attack are prevented through this kind of encryption
4. what are the libraries objects methods that enable https on both client side and server side
5. what are the steps relevant to setting up https tls and ssl on self hosted and cloud hosted servers
Could you tell us how you create the video animations?
Thank you. Great video!
Excellent video! Very well explained.
Great, just please add Certificate Verification as well
How do you make those video animations ?
1:03 Assymetric encryption alone can be proxied, at least in cases ECC and RSA. Where does the protocol prevent a man-in-the-middle attack ?
May I know which tool that you used for the Illustration or to make the presentation? It is simply impressive and easy to understand..
Great explanation , but please be loud next time
very nice explanation. Thx
Excellent explanation
Thanks so much for this video.
How does the client identify itself in the subsequent requests in the phase 4?
Does the server need to keep in memory all the thousands of client specific session keys?
Sir, what graphics software do you use for making your videos? Your illustrations are so good!
Thanks man. Good lesson
Very nice visuals!
I have 2 doubts
1. which public key and private key is known as assymetric keys .on server under .ssh present keys or ssl keys
2. Secure data trasmission between client and server using client symmetric key or
client will use server public key for encryption which will decrypt by server private key and server will use client symmetric key for encryption which will decrypt by client symmetric key
For 2nd question -
a) AES, DES or similar algorithms are used for generating the session key (secret key ; symmetric key)
b) This session key is then encrypted using the server's public key got from the digital certificate.
c) The server on receiving this, decrypts it using its private key.
d) Now, the client and the server have the session key.
Very interesting need to know
the animation looks great. which tool do you use?
I have a question. When this hand shake happens? It does for the first request and keep this connection stablished for the next calls or it does for every request?
Im having difficult to imagine it if we have clusters, if the connection is kept alive.
Great video, thanks.
Hi, thanks for your videos, very helpful. I'm writing my master thesis and I'm looking for a way to compare TLS cipher suites about their computational cost. My main idea is about counting number of operations and related weigth for each algorithm in every cipher suites, but I can't find any information about these metrics or just a tool to implement RSA (e.g.) and understand the computational weigth, in order to compare the main cipher suites. Can you or anyone else give me any input to implement this metric? Many thanks
Very useful information
which animation software you used to create this video?
Really good one! Thanks a lot!
Love the videos. What software do you use to make the video animations?
i have the same exact question..These animations are so clean
@@mario_luis_dev In some other videos, it is mentioned that He uses Adobe Illustrator or some other adobe product.
Thank you very much!🙏👌
Great video thank you!
Sir.... how does your channel NOT HAVE 20M SUBS???!?!?!?!
The client doesnt send the session key, both derive it from pre master key!
Question - so if we have private key. We can decrypt tcpdump file?
Please, does anyone knows what is the simulations program?
Thanks!
And thank you for the video, outstanding explanation.
I used to think after TCP Handshake we start transmitting data and I forgot about the other two steps (Certificate check and Key Exchange). I was wrong(((( Thank you
What tool are you using to present the tutorial? Very nice 👍
great video! thanks!!
amazing explanation
Am I correct in saying TLS1.3 uses Symmetric encryption for key exchange since DH is symmetric?
can you make video explain about CA certificate?