Thumbs up for wireshark all things comment lol. You get off track easily (like I tend to do), but you also go deep and I really appreciate that! Thanks man. You've taught me a lot
Good stuff Hussein. The reason it shows TLS 1.2 when you are using TLS 1.3 is to avoid a problem called "version intolerance" because some servers do not implement it properly. It is discussed in RFC 8446.
I am going to make a video on this . This is due to protocol ossification the same problem preventing us from running HTTP/2 on port 80 en.wikipedia.org/wiki/Protocol_ossification
I can't even understand what these things are, I'm just here to support. I'v been working as a Front End Engineer for 2years now, maybe now Its time to explore the Back End aswell PS: I am a hardcore Node Js Mongo MySQL backender, apart from these I dont know anything in backend not even php 😅
Great video Hussein! I just discovered your channel today and you are awesome. This is your third video I've checked out today and I have found them all very informative while still managing to crack me up :D Anyone know why Client Hello packet at 4:32 shows "Version: TLS 1.0 (0x0301)" at the top just under the Record Layer block? I am seeing the same thing when I test and I'm wondering if it is just meant to denote the major version or something. Seems weird to me, given that it shows TLS 1.2 above and below that
Palaniappan RM so the client sends a list of ciphers (encryption algorithms) it supports and server responds with back with the change cipher spec picking the algorithms it supports. I explained that in the TLS video in details
Hi Hussien....Can you please explain how does the certificate exchange and trust is build on 1.3. I can see that in TLS 1.2 the certificate shows server certificate and the intermediate CA ( excluding the root CA). Though in TLS 1.3 , I dont understand how certificate verification chain is built by the client in TLS1.3 as i dont see any certificate are being sent so how does the client built the trust chain ? Can you please advise.
Hmm interesting. Reading the spec it seems that 1.3 omits parent certs if the client already know them tools.ietf.org/html/rfc8446#section-4.4.2 Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.
@@hnasr Thanks for prompt response though it goes beyond my small brain. Not sure what independent method is used for creating trust path. My main problem was find how does the server communicate alternate trust path in cross signed cert (intermediate CA which has signed cert with more than on CA) ie does server send on on trust path to the client or more than one trust path in one go? I am not making to long but if you know that would be great. I have few other question about cross signing I would really like to ask :-)
Thanks for sharing the RFC. . After reading 4.4.2.2 my hypothessis is I was using chrome and chrome uses AIA attribute fromwithin from the server certificate to build chain by querying the internet, so possibly the client is not sending information about chain but alteast the server certificate should be sent in TLS which I am not sure goes in which tag in server hello call by server
Thumbs up for wireshark all things comment lol. You get off track easily (like I tend to do), but you also go deep and I really appreciate that! Thanks man. You've taught me a lot
Good stuff Hussein.
The reason it shows TLS 1.2 when you are using TLS 1.3 is to avoid a problem called "version intolerance" because some servers do not implement it properly. It is discussed in RFC 8446.
pouriya jamshidi Thanks Pouriya! Aha! You are a networking genius!
@@hnasr Haha I wish! You are welcome bro!
I am going to make a video on this . This is due to protocol ossification the same problem preventing us from running HTTP/2 on port 80
en.wikipedia.org/wiki/Protocol_ossification
@@hnasr Cool! I look forward to it
I can't even understand what these things are, I'm just here to support.
I'v been working as a Front End Engineer for 2years now, maybe now Its time to explore the Back End aswell
PS: I am a hardcore Node Js Mongo MySQL backender, apart from these I dont know anything in backend not even php 😅
2:58 The number of packets is displayed on the bottom right: "Packets 12671 Displayed: 23 (0.2%)"
This channel is magic
Great video Hussein! I just discovered your channel today and you are awesome. This is your third video I've checked out today and I have found them all very informative while still managing to crack me up :D
Anyone know why Client Hello packet at 4:32 shows "Version: TLS 1.0 (0x0301)" at the top just under the Record Layer block? I am seeing the same thing when I test and I'm wondering if it is just meant to denote the major version or something. Seems weird to me, given that it shows TLS 1.2 above and below that
excellent content, funny guy.
+1 like, sir :)
I am learning how to use the OpenSSL library and after your explanation I know it better what my C++ server test application does :))
Pretty cool Dani! You are deep into this stuff looks like it 👍
Great :D
Hussein I've seen your video about DoS attacks and it was great. It would be awesome if you did a followup video on DoS mitigation techniques.
Good idea!
instablaster...
Have waited for this for long time. Great video. I didn't get only 1 part. What is "change cipher spec" ?
Palaniappan RM so the client sends a list of ciphers (encryption algorithms) it supports and server responds with back with the change cipher spec picking the algorithms it supports.
I explained that in the TLS video in details
@@hnasr oh yeah I know this part but I don't know that this is called as Change cipher spec. Thank you.
9:31 "is impossible" :: not for me. Those who can't completely decrypt packets cant insp[ect streams. (if one have/is on the end of stream)
And what will you get from that?
It's handshake comparison between tls 1.2 and tls 1.3 version
Hussein , nice one..so nginx only supported TLS 1.2 ??
TANMOY MALLICK thanks! No NginX does support TLS 1.3 (made a video on it) its just the nginx website did not enable it for some reason)
Hi Hussien....Can you please explain how does the certificate exchange and trust is build on 1.3. I can see that in TLS 1.2 the certificate shows server certificate and the intermediate CA ( excluding the root CA). Though in TLS 1.3 , I dont understand how certificate verification chain is built by the client in TLS1.3 as i dont see any certificate are being sent so how does the client built the trust chain ? Can you please advise.
Hmm interesting. Reading the spec it seems that 1.3 omits parent certs if the client already know them
tools.ietf.org/html/rfc8446#section-4.4.2
Because
certificate validation requires that trust anchors be distributed
independently, a certificate that specifies a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.
@@hnasr Thanks for prompt response though it goes beyond my small brain. Not sure what independent method is used for creating trust path. My main problem was find how does the server communicate alternate trust path in cross signed cert (intermediate CA which has signed cert with more than on CA) ie does server send on on trust path to the client or more than one trust path in one go? I am not making to long but if you know that would be great. I have few other question about cross signing I would really like to ask :-)
Thanks for sharing the RFC. . After reading 4.4.2.2 my hypothessis is I was using chrome and chrome uses AIA attribute fromwithin from the server certificate to build chain by querying the internet, so possibly the client is not sending information about chain but alteast the server certificate should be sent in TLS which I am not sure goes in which tag in server hello call by server
working in ESRI seems to be boring :))
6:17 RSA can be easily cracked?!!
While I really like your Demo approach, you could have but same Info in 25% of time :) But never mind.