the confusion i was having for the last few weeks just vanished away at 5:12 , nobody on this platform ever bothered to mention that this was an old method and the new method incorporates DH key exchange algo. THANK YOU A LOT HUSSEIN !
The missing puzzle in all your existing CA/TLS video was what the CA exactly does which is explained here. It takes the public key of the server and signs (generates digital signature) with his private key so that any clients can decrypt the content and verify if the public keys are the same to trust the server. Love to learn more from you. Thanks 👍
@@cicher I don't know why my previous comment got deleted.... However... There is not one rootCA for each CA specificly, one rootCA may sign multiple CAs. The rootCAs are pre-installed on your OS and on Android you can view them in Settings > Security > More security settings > View security certificates; on Windows just run certlm.msc and navigate to Trusted root certificate authorities. When a new CA (not rootCA) is introduced it can be signed by a rootCA or another trusted CA, which is signed by a rootCA or another CA, which is signed by a rootCA or another CA, which is signed by a rootCA or another CA.......etc., which is signed by a rootCA. You can check the certificate path in your browser (click/tap on the lock icon and click/tap "Connection is secure" and (Android: Google Chrome) tap Certificate information (the you can see the path in the drop down menu at the top) or (Windows: Chromium Edge/Chrome) click the certificate icon and tab to certificate path). When a new rootCA is introduced worldwide the owner of the rootCA pays $ to the OS developers for including the rootCA in the next update. And this is why (except for Let's Encrypt e.g.) SSL cerfiticates usually costs something and because the CA checks the identity of requestors and enforces the policies given by the CA. However, often if you buy a domain, in my case, from IONOS.de a signed SSL cerfiticate for your domain and subdomains is included in the price tag (as well as an email-service). Instead of doing that you can create your own rootCA and install it on your devices, but of course this rootCA wont't be deployed worldwide or at least it's very unlikly if the you are not a major OS developer such as Microsoft, Google, Apple or Linux Foundation. Also on Android Deviced without root you will see the a warning "The network may be observed". And that could be true, because there could be a man-in-the middle attack. In a enterprise environment a proxy filter which is capable of https is exactly the same. The actual website has a encrypted connection to the proxy. The proxy decryptes the https to http, filters/alters the unencrypted data, encryptes back to https with it's own certificate, which is signed by a rootCA, which the company or a hacker installed on the client previously. On Android the rootCAs, which are pre-installed by the developer, and the addicional rootCAs, which are installed by the user, are in a seperate directories. To copy user rootCAs to the same directory as where the pre-installed rootCAs are stored, you need root-access to do so.
Ahhhhh! Thank you! You can create your own rootCA. Most of the explanation with SSL explains how it functions on public facing websites. I think creating your own rootCA is how you can use SSL in your own private network? This is what I’ve been wondering.
I was going to mock your comment because in every video there's a comment saying exactly what you did. After watching the video, yes this is the best explanation by far 😀😀😀
really this is a great explanation but at 11:45 you say that the way of verification is that it encrypt the certificate with the certificate authority public key and check if it output the same signature, I think this is not a way of verification as if the signature is the encryption of the certificate using the public-key then any one can fake the certificate easily I think the only of verification is the other way you mentioned in 11:54 which is decrypting the digital signature using the public-key of CA which result in a hash then compare this hash with the hash of the content of the certificate and if it match, then everything is correct I think that I read before that in digital signature, it is created by encrypting the content using private-key and other people decrypt it using the public-key
Man, you are genius!! I’ve spent almost an hour checking other videos about ssl but couldn’t understand it completely. But the way you explain it, it’s super clear now. Thanks a lot
Wow what a clear insight.when i search for this in youtube i got a video a guy in dark light and writing in transparent board but it was nothing near to your videos but his video got 100k views wondering comparing to that your content deserves 1M views. You’re missing some RUclips strategies
This entire process reminds me of the mid to late 70's. Every software developer out there was developing software by throwing software spitballs at the wall to see what would stick. The game was to capture market share by being first to market regardless of how good or bad the software was, and then go back to fix all the bugs after release. The product did not matter, you simply had to get sufficient market share to control the standards and hence the licensing. It happened time after time. 50 years later and it's still going on.
Thank you for your video. I have some questions: - Does the server send the certificate for every session? - Does the server asks the CA for a certificate for every session? Or does this happen only once? - Can't Karen get her certificate signed by a CA using the public key of the server? Because she has access to it since it is just send over? - Do I have a root certificate on my PC for every website? And does it expire? I've never had to renew one? How does this work?
As you mentioned in the video the public key of a server encrypted by CA's private .So the client who already have root certificate which include CA's public key can decrypt the certificate send by the server . Is it possible that publick key can decrypt the data which was encrypted by private key ?
Still very confusing where he gets to the part of what the CA does and what the issued certificate actually contains, and also how the client verifies the certificate received from the server. If you cannot explain it in simple terms, I am afraid you actually don't fully understand it. Moving on to the next video attempt to explain this process CLEARLY
I was clear about everything except the doubt that i used to have, how is public key of the rootCA shared with client..... apparently it comes pre-installed with OS and it is also auto-updated securely before, so new public keys are pulled before the old public key is expired.
Hii Hussein Thanks for all the videos you make and share ur knowledge with us. i have gained alot of knowledge from your videos ❤️❤️❤️ I am little bit confused on cipher suit which is exchanged during SSL or TLS it will great if you can make a video on how each algorithm in cipher suit syntax helps in establishing a secure connection Lots of love from India ❤️❤️❤️
I was following until you mentioned the green key the client has. So how does the client get the green key? Is that something automatically included in every browser? and who gives the server their public and private keys. Does the CA provide those with the certificate?
Hi Hussein, i am confuse since i am new at this and i already made my server secure with ssh with putty and what i don't understand is does making a certificate replace replace my ssh keys with the certificates keys from certbot? I have a hard time setting up my vps with 3 domains under a single wildcard certificate!
There can be n number of CAs across the world and every website I visit can have a different cert chain so how is it possible for anyone to predict those many cert chains to have it installed in my OS?
Good question, during the certificate creation the server establishes a secure connection with the CA first during which CA sends its certificate to the server. The server will securely send its public key in that secure connection so no one can intercept it. If someone tries to intercept they need to prove that they are the CA by providing the CA cert which is not possible
Could I ask, if you are a website such as ebay where your actual application requires a certificate, is the point of that cert to ensure -- as a customer -- that you are genuinely communicating with ebay and not an imitation site?
Your video was amazing. I understood it all but got a little confused at the end where the client has to then verify the CA's signature on the servers public certificate and then eventually makes its way back to the root certificate. I'm not sure I need to know either but still understanding the rest was important i.e. going from RSA to then signed certificates.
Hey Hussein... can you come up with a video on the details of the certificate itself... for example whats an Authority Key identifier, SCT List etc ... guaranteed atleast 5-10 views from my end and a like
Hi great video! Question- taking a simple example of accessing a new website, are you saying that as part of the negotiation and connection establishment my device will be communicating with 2 different hosts primarily: 1)the web server itself and also 2) the certificate authority- as part of the process to validate the authenticity of the certificate the web server claims is theirs? then my next question is who are the certificate authorities? are these just middlemen companies who have followed some red tape to become a qualified CA and we all just agree that we will trust them since its their only job to validate certs? so basically just trying to understand who the CAs are. would it be a true statement to say that if potentially this trusted CA company decides they want to intercept our traffic, they could do so since they are the ones who say whether the cert is legit or not
* Client connects to web server * Web server responds with its certificate full chain * client verifies the certificate chain locally up until the ROOT cert which should exists in the machine/cert store. (Client doesn’t need to contact CA for that) That is the happy path, there is however a case which a certificate isnt expired but has been revoked (eg private key leaked) in that case one solution was CRL (certificate revocation list) a list of all revoked certs, that was bad because the list grow very large and hard to maintain... So they came up with OCSP (online certificate status protocol ) which the client must ask the CA to see if a certificate is still valid and not revoked. That is when the client connects to CA. Obviously people didn’t like that because you are leaking the sites you are visiting to the CA.. The other better approach is OCSP stapling which let the server asynchronously ask the CA on the backend and staple and sign the certificate with date proving that it hasn’t been revoked.. So in a nutshell nowadays you only connect to webserver but depends on the revocation protocol you might connect to the CA
@@hnasr thanks! that mostly makes sense except step 3. i am really confused about what the client is able to do in order to validate the full certificate chain is authentic. is it built into the browser? so when i install chrome for example that comes along with the ability to validate certificate chains? also, locally... root... any chances of a video on all of this part? or is it already on this video and its just all over my head yes that is more likely
@@DrHoops21 I asked ChatGPT how does Chrome browser validates a Certificate Authority. And here is the response. "When you visit a secure website, the server presents its SSL certificate to your browser. Chrome checks if the certificate is issued by a trusted CA. It does this by looking at the certificate chain, where the website's certificate is signed by an intermediate CA, and the intermediate CA is ultimately signed by a root CA. The root CA's certificate is stored in the browser's trust store."
vert nice explanation. Τhe only thing I would like you to make clear is, where is the public key of the Certificate authority stored, and to whom is avaliable. The same for root authority's public key. And why it's not easy for someone to pretend it's the root or the CA it's self?
I'm a bit confused - i thought symmetrical was when you only used a private key, but here you say they use both private and public keys and that it is symmetrical?
Can someone please explain what prevents a hacker from faking a certificate chain? Why can't I locate the verisign root certificate under my computer, and create a chain with my keys, the target domain and a hash function?
Nice explanation but i didn't how server verify itself to CA since server is sending public key to CA and Karen might be inbetween server and CA and Karen might send her public key instead of servers public key ? Digital signature by sending private key of server will verify that its a legitimate server....
Ok, but then what if I issue a certificate for one of my websites, but then man-in-the-middle a user and say like "Hey, I'm Google.com and here's my public key. Don't trust me? Look it's signed by those CAs!" and just send them my website's signed public key. How will the user know that even though this key is signed, it's not for google.com?
It won’t be trusted by your device because no trusted CA will ever sign a certificate to google.com to you without proper domain verification. It did happen with Diginotar but that CA got banned immediately
@@hnasr Okz thanks Hussein.. Actually we have a custom cloud application which calls a web server.. and we are making Api callouts, from code, not from browser. So it should be the same concept for that as well..right..
I totally loved the explanation but I suggest you the find any other app so that you do not open your side toolbar multiple times. Its distracting many times.
couldn't you just intercept the certificate when it's being sent to the client, edit the top certificate (or idk how to call the one that is the oppositeof root) so that it has karen's public key and then just be able to do a man in the middle attack the same way you described at the start? I don't see how this certificate thing is more secure than the first method you showed
the confusion i was having for the last few weeks just vanished away at 5:12 , nobody on this platform ever bothered to mention that this was an old method and the new method incorporates DH key exchange algo. THANK YOU A LOT HUSSEIN !
The missing puzzle in all your existing CA/TLS video was what the CA exactly does which is explained here. It takes the public key of the server and signs (generates digital signature) with his private key so that any clients can decrypt the content and verify if the public keys are the same to trust the server. Love to learn more from you. Thanks 👍
So... there one root certificate (installed in all devices worldwide) for each CA, right??
What if a new CA needs to be introduced? Or how is it?
@@cicher I don't know why my previous comment got deleted....
However...
There is not one rootCA for each CA specificly, one rootCA may sign multiple CAs.
The rootCAs are pre-installed on your OS and on Android you can view them in Settings > Security > More security settings > View security certificates; on Windows just run certlm.msc and navigate to Trusted root certificate authorities.
When a new CA (not rootCA) is introduced it can be signed by a rootCA or another trusted CA, which is signed by a rootCA or another CA, which is signed by a rootCA or another CA, which is signed by a rootCA or another CA.......etc., which is signed by a rootCA. You can check the certificate path in your browser (click/tap on the lock icon and click/tap "Connection is secure" and (Android: Google Chrome) tap Certificate information (the you can see the path in the drop down menu at the top) or (Windows: Chromium Edge/Chrome) click the certificate icon and tab to certificate path).
When a new rootCA is introduced worldwide the owner of the rootCA pays $ to the OS developers for including the rootCA in the next update.
And this is why (except for Let's Encrypt e.g.) SSL cerfiticates usually costs something and because the CA checks the identity of requestors and enforces the policies given by the CA. However, often if you buy a domain, in my case, from IONOS.de a signed SSL cerfiticate for your domain and subdomains is included in the price tag (as well as an email-service).
Instead of doing that you can create your own rootCA and install it on your devices, but of course this rootCA wont't be deployed worldwide or at least it's very unlikly if the you are not a major OS developer such as Microsoft, Google, Apple or Linux Foundation. Also on Android Deviced without root you will see the a warning "The network may be observed".
And that could be true, because there could be a man-in-the middle attack. In a enterprise environment a proxy filter which is capable of https is exactly the same.
The actual website has a encrypted connection to the proxy. The proxy decryptes the https to http, filters/alters the unencrypted data, encryptes back to https with it's own certificate, which is signed by a rootCA, which the company or a hacker installed on the client previously.
On Android the rootCAs, which are pre-installed by the developer, and the addicional rootCAs, which are installed by the user, are in a seperate directories.
To copy user rootCAs to the same directory as where the pre-installed rootCAs are stored, you need root-access to do so.
Ahhhhh! Thank you! You can create your own rootCA. Most of the explanation with SSL explains how it functions on public facing websites. I think creating your own rootCA is how you can use SSL in your own private network?
This is what I’ve been wondering.
This is by far the best explanation I've seen on SSL certificates. Thank you!!
Wow, thank you! glad I could help
I was going to mock your comment because in every video there's a comment saying exactly what you did. After watching the video, yes this is the best explanation by far 😀😀😀
I understood public key cryptography, but was looking for how these certificates are exchanged. This explanation was spot on, thank you so much.
This is the best explanation that I've seen about keys and certs. Tanx Man!
really this is a great explanation
but at 11:45 you say that the way of verification is that it encrypt the certificate with the certificate authority public key and check if it output the same signature, I think this is not a way of verification as if the signature is the encryption of the certificate using the public-key then any one can fake the certificate easily
I think the only of verification is the other way you mentioned in 11:54 which is decrypting the digital signature using the public-key of CA which result in a hash then compare this hash with the hash of the content of the certificate and if it match, then everything is correct
I think that I read before that in digital signature, it is created by encrypting the content using private-key and other people decrypt it using the public-key
This guy's voice is perfect for teaching. So relaxing and calming :)
Man, you are genius!! I’ve spent almost an hour checking other videos about ssl but couldn’t understand it completely. But the way you explain it, it’s super clear now. Thanks a lot
I like your personality and your way of teaching. Listening to you is entertainment and learning at the same time. Keep up man ❤️
"take my public key beautiful" lmfao
kinda cringy lol
I've just watched this video ten times just to enjoy the stuff. Really cool way of teaching.
This left no questions open, amazing.
Wow what a clear insight.when i search for this in youtube i got a video a guy in dark light and writing in transparent board but it was nothing near to your videos but his video got 100k views wondering comparing to that your content deserves 1M views. You’re missing some RUclips strategies
Thanks!
Great job! As always I’d say... you deserve a lot more than 30k subs!
Exploited89 thanks!! Am soo grateful To have 30k couldnt ask for more awesome subs
Really helpful lecture to understand the fundamental of exchanging the keys and how do they encrypt.
Here is my comment, son.
This is a great video, thanks
This entire process reminds me of the mid to late 70's. Every software developer out there was developing software by throwing software spitballs at the wall to see what would stick. The game was to capture market share by being first to market regardless of how good or bad the software was, and then go back to fix all the bugs after release. The product did not matter, you simply had to get sufficient market share to control the standards and hence the licensing. It happened time after time. 50 years later and it's still going on.
Thank you Hussein for the great explanation. Finallyyyy I got the concept
Thank you Hussein, I am an IT student and this video helped me so much !
love the knowledge you have shared, it was extremely useful and it had a bit of humor in it to make the watcher feel engaged
I just want to say, i love your energy!! Great video btw!
I believe this channel is going to become the next Khan Academy for technology
Your key-drawing skills dramatically increased through the video!
Trying to get better still! Haha thanks though
@@hnasr who is this dangerous hacker, Karen, btw?
This explanation was exactly I was looking for. Thank you!
Oh man !! You just made it perfectly simple. Enjoyed learning.
Tq bro I love the way u explain the things it is so interesting..
Thank you for your video. I have some questions:
- Does the server send the certificate for every session?
- Does the server asks the CA for a certificate for every session? Or does this happen only once?
- Can't Karen get her certificate signed by a CA using the public key of the server? Because she has access to it since it is just send over?
- Do I have a root certificate on my PC for every website? And does it expire? I've never had to renew one? How does this work?
Or am I totally wrong here?
This is awesome, thank you. The visuals were helpful
As you mentioned in the video the public key of a server encrypted by CA's private .So the client who already have root certificate which include CA's public key can decrypt the certificate send by the server . Is it possible that publick key can decrypt the data which was encrypted by private key ?
Thank you! Just what I was looking for :)
Que vídeo incrível! Aplaudi por R$ 5,00 👏👏
❤️❤️❤️
This is a great video. Understood everything!!
Nice video Hussein, Thank you!
This is the video that I will watch when I need to review TLS certificate.
Thanks alot for the content youre puttting out man. Really appreciate it captain
.
this video is a hidden treasure!
The certificate authority uses its private key or public key to encrypt / sign the certificate?
Still very confusing where he gets to the part of what the CA does and what the issued certificate actually contains, and also how the client verifies the certificate received from the server. If you cannot explain it in simple terms, I am afraid you actually don't fully understand it. Moving on to the next video attempt to explain this process CLEARLY
Very nicely explained. Thank you Husein.
this video is really help，thanks a lot!
I wish you create more explaining video on how this all works on text and symbols level, what adds to what, and extracts from what
Excellent explanation!
I was really struggling to understand the chain of trust concept. Thanks for this wonderful explanation.
Thanks a lot for this video!
Such an amazing video Hussein. Thank you so much for a fun and interesting way of teaching this. Liked and Subbed :)
I was clear about everything except the doubt that i used to have, how is public key of the rootCA shared with client..... apparently it comes pre-installed with OS and it is also auto-updated securely before, so new public keys are pulled before the old public key is expired.
Hii Hussein
Thanks for all the videos you make and share ur knowledge with us. i have gained alot of knowledge from your videos ❤️❤️❤️
I am little bit confused on cipher suit which is exchanged during SSL or TLS it will great if you can make a video on how each algorithm in cipher suit syntax helps in establishing a secure connection
Lots of love from India ❤️❤️❤️
jain kapil thank you Jain! Great idea
Fantastic useful content!
Glad it was helpful Magomed!
Well explained Hussein
I was following until you mentioned the green key the client has. So how does the client get the green key? Is that something automatically included in every browser? and who gives the server their public and private keys. Does the CA provide those with the certificate?
Awesome video man
Best explanation ever
Hi Hussein, i am confuse since i am new at this and i already made my server secure with ssh with putty and what i don't understand is does making a certificate replace replace my ssh keys with the certificates keys from certbot? I have a hard time setting up my vps with 3 domains under a single wildcard certificate!
you should make nft with those beautifull drawings of yours. Thanks a lot for the explaination
Excellent Concept..
There can be n number of CAs across the world and every website I visit can have a different cert chain so how is it possible for anyone to predict those many cert chains to have it installed in my OS?
U made my day!!!
❤️
What happens if an attacker intercept the public key of server before reaching certificate authority and sends his public key to CA.
Good question, during the certificate creation the server establishes a secure connection with the CA first during which CA sends its certificate to the server. The server will securely send its public key in that secure connection so no one can intercept it. If someone tries to intercept they need to prove that they are the CA by providing the CA cert which is not possible
Could I ask, if you are a website such as ebay where your actual application requires a certificate, is the point of that cert to ensure -- as a customer -- that you are genuinely communicating with ebay and not an imitation site?
Correct , without certificate there is no way we know that someone in the middle has intercepted the traffic
Really great man
Your video was amazing. I understood it all but got a little confused at the end where the client has to then verify the CA's signature on the servers public certificate and then eventually makes its way back to the root certificate. I'm not sure I need to know either but still understanding the rest was important i.e. going from RSA to then signed certificates.
Hey Hussein... can you come up with a video on the details of the certificate itself... for example whats an Authority Key identifier, SCT List etc ... guaranteed atleast 5-10 views from my end and a like
Hi great video! Question- taking a simple example of accessing a new website, are you saying that as part of the negotiation and connection establishment my device will be communicating with 2 different hosts primarily: 1)the web server itself and also 2) the certificate authority- as part of the process to validate the authenticity of the certificate the web server claims is theirs? then my next question is who are the certificate authorities? are these just middlemen companies who have followed some red tape to become a qualified CA and we all just agree that we will trust them since its their only job to validate certs? so basically just trying to understand who the CAs are. would it be a true statement to say that if potentially this trusted CA company decides they want to intercept our traffic, they could do so since they are the ones who say whether the cert is legit or not
* Client connects to web server
* Web server responds with its certificate full chain
* client verifies the certificate chain locally up until the ROOT cert which should exists in the machine/cert store. (Client doesn’t need to contact CA for that)
That is the happy path, there is however a case which a certificate isnt expired but has been revoked (eg private key leaked) in that case one solution was CRL (certificate revocation list) a list of all revoked certs, that was bad because the list grow very large and hard to maintain...
So they came up with OCSP (online certificate status protocol ) which the client must ask the CA to see if a certificate is still valid and not revoked. That is when the client connects to CA. Obviously people didn’t like that because you are leaking the sites you are visiting to the CA..
The other better approach is OCSP stapling which let the server asynchronously ask the CA on the backend and staple and sign the certificate with date proving that it hasn’t been revoked..
So in a nutshell nowadays you only connect to webserver but depends on the revocation protocol you might connect to the CA
@@hnasr thanks! that mostly makes sense except step 3. i am really confused about what the client is able to do in order to validate the full certificate chain is authentic. is it built into the browser? so when i install chrome for example that comes along with the ability to validate certificate chains? also, locally... root... any chances of a video on all of this part? or is it already on this video and its just all over my head yes that is more likely
@@DrHoops21 I asked ChatGPT how does Chrome browser validates a Certificate Authority. And here is the response.
"When you visit a secure website, the server presents its SSL certificate to your browser. Chrome checks if the certificate is issued by a trusted CA. It does this by looking at the certificate chain, where the website's certificate is signed by an intermediate CA, and the intermediate CA is ultimately signed by a root CA. The root CA's certificate is stored in the browser's trust store."
vert nice explanation. Τhe only thing I would like you to make clear is, where is the public key of the Certificate authority stored, and to whom is avaliable. The same for root authority's public key. And why it's not easy for someone to pretend it's the root or the CA it's self?
Root CA is where the chain ends, and its public key is stored/hard coded in the browsers or in your device by the device's manufacturer.
if the certificate is my Apple ID thats considered private right ?
I'm a bit confused - i thought symmetrical was when you only used a private key, but here you say they use both private and public keys and that it is symmetrical?
Private public key is asymmetrical, using the same key to encrypt / decrypt is symmetrical.
This might help ruclips.net/video/Z3FwixsBE94/видео.html
thanks bro for the explanation
Am I the only one who find it is very confusing?😅😅😅
Can someone please explain what prevents a hacker from faking a certificate chain? Why can't I locate the verisign root certificate under my computer, and create a chain with my keys, the target domain and a hash function?
Nice explanation but i didn't how server verify itself to CA since server is sending public key to CA and Karen might be inbetween server and CA and Karen might send her public key instead of servers public key ? Digital signature by sending private key of server will verify that its a legitimate server....
Ok, but then what if I issue a certificate for one of my websites, but then man-in-the-middle a user and say like "Hey, I'm Google.com and here's my public key. Don't trust me? Look it's signed by those CAs!" and just send them my website's signed public key. How will the user know that even though this key is signed, it's not for google.com?
It won’t be trusted by your device because no trusted CA will ever sign a certificate to google.com to you without proper domain verification.
It did happen with Diginotar but that CA got banned immediately
Me on tinder- "Take my public key beautiful. Take it."
😂 Keep going explaining things this way
Nasser, you're great
Your free content is also great like your paid one
Aye yo you’ve gotten a new subscriber😃
Btw we share the same name😝
totally awesome !!!!
here's my public key SON
So... Client has to install the Certificate from the Server... So that it knows the request coming from the right Server... Am I correct?
Correct, most of the time those certs are preloaded with the OS cert store. Recently browsers are also coming up with their own cert store too
@@hnasr Okz thanks Hussein.. Actually we have a custom cloud application which calls a web server.. and we are making Api callouts, from code, not from browser. So it should be the same concept for that as well..right..
Excellent !
wow what an explanation
confused how certificates prevent karen from using her own public key? what if karen had same public key as server
Is not signature = server public key + ca public key ?
You say signature= server public key + ca private key
xD u made my day man, thanks 🤣
You are the best
Yeah I actually really need to understand what a certificate is.
01:59, very weird looking key. 👀
It's usually Alice, Bob and Eve in Cryptography.
Correct, but this is not a usual channel :)
@@hnasr Yeah, never heard a more boring thing than Alice and Bob!
ok, I understand ...... they make very complicated communication between public computers and servers ...just to make a money ...from nothing.
Why don't they just send a PDF instead of making me go through all 7 levels of HELL ?
i need SSL because chrome uses HTTPS for default connection
I totally loved the explanation
but I suggest you the find any other app so that you do not open your side toolbar multiple times. Its distracting many times.
Wish @ 193K subs flow diagrams were drawn a little better. Also other vids from Hussein are better (less cocky).
Hmm I was totally confused! Too much back and forth changing colours. Going to have to rewatch again
good stuff.. but too many times color changing was annoying for me...
PERFECT!
couldn't you just intercept the certificate when it's being sent to the client, edit the top certificate (or idk how to call the one that is the oppositeof root) so that it has karen's public key and then just be able to do a man in the middle attack the same way you described at the start? I don't see how this certificate thing is more secure than the first method you showed
great job but please leave KAREN out of this 😆🤣
PERFECT !!!!