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
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
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!
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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-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!
