I wish we were that talented! For details on our build and process, you can check out this article: devcentral.f5.com/articles/lightboard-lessons-behind-the-scenes
When using tlsv1.3 or an older version that is configured to exclusively use PFS ciphers; is there a need to import the private key file that gets generated when we create the CSR? It seems that PFS ciphers generate their own private key, therefore importing a private key is not necessary. Is this assumption correct?
great question! PFS ciphers are used for the key exchange portion of the TLS handshake, and new bulk encryption session keys are generated for each session. but, for server authentication purposes, many implementations still use RSA, so importing a private key for that purpose might still be needed (although you don't have to use RSA for authentication). hope this helps!
Thank you, content and presentation is excellent. I do not understand reply attack - even though the intruder gets access to an existing session, he does not have secret key, symmetric key to encrypt and decrypt information. Can you please help me understand? Thank you.
Great question Lokesh! Here's a link to a discussion on Stack Exchange that does a good job of explaining the replay attack: security.stackexchange.com/questions/166156/understanding-a-tls-1-3-0-rtt-replay-attack
I feel like the title is misleading. This is rather explaining why you should use TLS 1.3, a high level overview of what it adds on top of TLS 1.2, but not really explaining TLS 1.3.
Thanks...as you mentioned, it's more of a high-level view of what TLS 1.3 brings. I gave a talk on this at a recent conference and filled up every bit of an hour talking about the details of TLS 1.3, so it's hard to squeeze it all into a shorter video. Thanks for the comment, though!
You were wrong with explaining PFS, you never share your private key it simply a method to assure you that even if the server you are talking with was compromise i.e. an attacker somehow get hold of his private key he than this attacker still need to decrypt each session you do with that server separately as the session key will change (new random roll) for each session. so it is going to be a bit harder.
Hi Neil. Thanks for the comment. When I mentioned "share your private key" I was not referring to sharing it with everyone. In some implementations using RSA for key exchange, companies will want to add inline security inspection devices like Data Loss Prevention (DLP) or Intrusion Prevention Systems (IPS), etc. When a user connects to the web server and establishes an encrypted session with the server, no other device can read the contents of the data exchanged between client and server. But, when RSA is used for key exchange, the private key of the server can be shared with these trusted security devices (DLP, IPS, etc) so that they can ultimately decrypt the data and inspect it. This brings up the fundamental problem in TLS 1.3 when PFS key exchange ciphers are used. There's no web server private key to share with these security devices (because the key changes with every new session)...so you have to figure out some other way to let them inspect the traffic. This has created a big headache for many organizations. Thanks again for the comment!
Thanks for clarifying that for me. I guess any man in the middle that has a private key of one of the side will be able to decrypt as it will see the handshake negotiate and will get the new symmetric key each session. Basically government does not allow you to really hide the symmetric data key in order for them to continue reading all information . Tls 1.3 will just prevent tempering to the data so if one government modify the data before second goverment read it they will know :-)
It’s hard for our little mobile phones to do these complicated computational stuff My iPhone: Laughs in A13 bionic which could very well compete with Intel’s core i5
Hi Jason...it's totally true! :) The TLS 1.3 RFC says "Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication." - Appendix E.5
I watched your videos and got a question please- How reply attack is possible? Checked the handshake mechanism in your video and see the key handshake mechanism is truly secure. Even if the intruder (man in the middle) intercepts the pre-master secret, he cannot decipher symmetric key out of it, because it is encrypted with Server's public key which can only be decrypted by server's private key- Reference: ruclips.net/video/cuR05y_2Gxc/видео.html
Great question! It's important to note that the replay attack can only happen on the Zero Round Trip Time session resumption feature in TLS 1.3; and even then, it's only possible for the first HTTP request during the resumption. So, the symmetric key is still safe, but the replay attack (if the server allows certain HTTP methods) can still be harmful to the end user or the application. Here's a quick diagram of how the replay attack could work: blog.cloudflare.com/content/images/2017/03/image00.jpg For many applications, the Zero Round Trip Time session resumption is only allowed for HTTP methods that will not change the state of the server and/or application. This effectively means that if a replay attack is launched, the application is not adversely affected. I hope this helps!
I just think it's awesome that you guy got a polo with the logo backwards. Good work!
Thanks for the comment and noticing that! We also got this for Behind the Scenes: ruclips.net/video/U7E_L4wCPTc/видео.html
Your mirrored hand writing is around 1000x nicer than my regular left to right :)
I think the video is mirrored.
amazing...
This is amazing! Good you covered both benefits and drawbacks so that those who implement have a very good picture of roadblocks as well.
glad you enjoyed it!
Every session of yours is indespensable!!!
glad you enjoy them!
great overview, thanks!
John you are the best man keep on ROCKING!!!
Thanks Abraham!
Are you writing backwards? Sorry for the off topic but it is blowing my mind.
I wish we were that talented! For details on our build and process, you can check out this article: devcentral.f5.com/articles/lightboard-lessons-behind-the-scenes
Glad someone else feels the same way.
I'm wondering the exact same thing!
Mirroring
That was the very first thing I started wondering as soon as I saw him writing... :)
Very clear explanation.Thank you sir.
Thanks for the comment!!
Amazing lecture delivery (Y)
glad you enjoyed it!
Thanks John, as always a very nice video !!
glad you enjoyed it!
Great, Good summary and explanation
glad you enjoyed it!
Hello, do you think Websockets are susceptible to 0rtt replay attacks? I mean if tou can trigger a sensitive operation via a websocket message.
thanks!!
When using tlsv1.3 or an older version that is configured to exclusively use PFS ciphers; is there a need to import the private key file that gets generated when we create the CSR? It seems that PFS ciphers generate their own private key, therefore importing a private key is not necessary. Is this assumption correct?
great question! PFS ciphers are used for the key exchange portion of the TLS handshake, and new bulk encryption session keys are generated for each session. but, for server authentication purposes, many implementations still use RSA, so importing a private key for that purpose might still be needed (although you don't have to use RSA for authentication). hope this helps!
Thank you, content and presentation is excellent.
I do not understand reply attack - even though the intruder gets access to an existing session, he does not have secret key, symmetric key to encrypt and decrypt information. Can you please help me understand? Thank you.
Great question Lokesh! Here's a link to a discussion on Stack Exchange that does a good job of explaining the replay attack: security.stackexchange.com/questions/166156/understanding-a-tls-1-3-0-rtt-replay-attack
Since when does Matthew McConaughey give lightboard sessions on RUclips
alright, alright, alright!
I feel like the title is misleading. This is rather explaining why you should use TLS 1.3, a high level overview of what it adds on top of TLS 1.2, but not really explaining TLS 1.3.
Thanks...as you mentioned, it's more of a high-level view of what TLS 1.3 brings. I gave a talk on this at a recent conference and filled up every bit of an hour talking about the details of TLS 1.3, so it's hard to squeeze it all into a shorter video. Thanks for the comment, though!
can anyone share me a link for what was the SSL certificate and what is TSL certificate how to work on both
You were wrong with explaining PFS, you never share your private key it simply a method to assure you that even if the server you are talking with was compromise i.e. an attacker somehow get hold of his private key he than this attacker still need to decrypt each session you do with that server separately as the session key will change (new random roll) for each session. so it is going to be a bit harder.
Hi Neil. Thanks for the comment. When I mentioned "share your private key" I was not referring to sharing it with everyone. In some implementations using RSA for key exchange, companies will want to add inline security inspection devices like Data Loss Prevention (DLP) or Intrusion Prevention Systems (IPS), etc. When a user connects to the web server and establishes an encrypted session with the server, no other device can read the contents of the data exchanged between client and server. But, when RSA is used for key exchange, the private key of the server can be shared with these trusted security devices (DLP, IPS, etc) so that they can ultimately decrypt the data and inspect it.
This brings up the fundamental problem in TLS 1.3 when PFS key exchange ciphers are used. There's no web server private key to share with these security devices (because the key changes with every new session)...so you have to figure out some other way to let them inspect the traffic. This has created a big headache for many organizations.
Thanks again for the comment!
Thanks for clarifying that for me.
I guess any man in the middle that has a private key of one of the side will be able to decrypt as it will see the handshake negotiate and will get the new symmetric key each session. Basically government does not allow you to really hide the symmetric data key in order for them to continue reading all information . Tls 1.3 will just prevent tempering to the data so if one government modify the data before second goverment read it they will know :-)
@@neilreonen75 thanks!
Technology explained as if nutritional guide
It’s hard for our little mobile phones to do these complicated computational stuff
My iPhone: Laughs in A13 bionic which could very well compete with Intel’s core i5
touche! iPhones have certainly come a long way.
Is lighting on? The worlds look dim.
side effect of fancy lightboards
LOL ok "server, you're responsible for making sure no replay attacks can occur. please configure properly..."
Hi Jason...it's totally true! :) The TLS 1.3 RFC says "Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication." - Appendix E.5
@@devcentral i am sure it is. we'll be seeing LOTS of vulnerabilities with TLS 1.3 on the horizon.....
I watched your videos and got a question please- How reply attack is possible? Checked the handshake mechanism in your video and see the key handshake mechanism is truly secure. Even if the intruder (man in the middle) intercepts the pre-master secret, he cannot decipher symmetric key out of it, because it is encrypted with Server's public key which can only be decrypted by server's private key- Reference: ruclips.net/video/cuR05y_2Gxc/видео.html
Great question! It's important to note that the replay attack can only happen on the Zero Round Trip Time session resumption feature in TLS 1.3; and even then, it's only possible for the first HTTP request during the resumption. So, the symmetric key is still safe, but the replay attack (if the server allows certain HTTP methods) can still be harmful to the end user or the application. Here's a quick diagram of how the replay attack could work: blog.cloudflare.com/content/images/2017/03/image00.jpg
For many applications, the Zero Round Trip Time session resumption is only allowed for HTTP methods that will not change the state of the server and/or application. This effectively means that if a replay attack is launched, the application is not adversely affected. I hope this helps!
TLS 1dot3
Hamam