Breaking Down the TLS Handshake

Поділитися
Вставка
  • Опубліковано 2 жов 2024

КОМЕНТАРІ • 279

  • @kallikantzaros
    @kallikantzaros 3 роки тому +20

    CLIENT:
    - Browser wants to establish connection to a server.
    - Client sends Hello’ message
    - TLS protocol number (1.2,1.3)
    - Cipher suite client supports
    SERVER:
    - Server sends ‘Hello’ message
    - Server sends certificate file
    - Includes server’s public key
    - Server sends ‘Hello done’ message
    CLIENT:
    - Client checks that certificate file
    - Checks if it has been revoked
    - Checks if it is still valid
    - Client generates ‘Pre-Master Secret Key’ (PMSK)
    - Client pulls some characters from server’s public key, encrypts that with server’s public key, and creates Pre-Master Secret Key
    - Based on PMSK, it will generate SYMMETRIC KEY from that PMSK that will be used for bulk encryption.
    - Client sends ‘Client finished’ message
    SERVER:
    - Server decrypts PMSK with his private key
    - Server creates SYMMETRIC KEY by decrypting PMSK. This symmetric key will be same as client’s symmetric key because it was encrypted with PMSK.
    - Server sends ‘Change Cipher Spec’ message. This tells client to change from asymmetric to symmetric key exchange
    - Server sends ‘Finished’ message
    END:
    Both of them have symmetric key used.

    • @MrReklez
      @MrReklez Рік тому +1

      Great summary . Thanks

    • @barnabyvonrudal1
      @barnabyvonrudal1 14 днів тому

      Is the server public key linked to the certificate? Or independent of it?

  • @zajec11
    @zajec11 4 роки тому +79

    Video is mirror image flipped, and the tshirt he's wearing has the text printed also mirror image flipped. That's how he's able on the glass so well.
    Now start learning some TLS!

    • @arduinoguru7233
      @arduinoguru7233 4 роки тому

      first wait until I change from 240p to 1080p maybe he wroth it flipped ,

    • @thisiswill
      @thisiswill 4 роки тому +1

      Thanks. Thought that was going on but I was so distracted considering what if he was just so good writing backwards, that I had to rewatch halfway to pay attention.

    • @PortuguesePirate99
      @PortuguesePirate99 4 роки тому +1

      See thats the first thing i was thinking and then scrolled through the comments to find out and you are top comment so thanks bro

    • @prat-man
      @prat-man 4 роки тому +1

      My mind is flipped. My eyes take in light flipped too. Double flip.

  • @usersn0000
    @usersn0000 3 роки тому +2

    Great explanation. Breaking something down that takes microseconds to complete into a 12min video.

  • @mferreira1231
    @mferreira1231 4 роки тому +17

    That was an amazing explanation, perfectly understood having the basics. Thank you

  • @mahendranr4245
    @mahendranr4245 4 роки тому +1

    In registry of one machine, If we enable client tls 1.0 and server tls 1.2 enabled, rest all disabled. Will it still allow communication?

    • @devcentral
      @devcentral  4 роки тому

      Great question Mahendra! It all depends on how you configure, in this case, the server. If the client is using TLS 1.0 and the server is set to use TLS 1.2, then you can configure the server to abort the TLS handshake when it realizes the client can't use TLS 1.2. Or, you can configure the server to allow a downgrade to TLS 1.0 when it realizes that the client can only use TLS 1.0. So, it depends on how you configure the client cipher suite. I hope this helps!

    • @mahendranr4245
      @mahendranr4245 4 роки тому

      @@devcentral Thanks John for your reply. Glad to hear from you. Much appreciated, if you can explain along with sample client/server communication example.

  • @chillyvanilly6352
    @chillyvanilly6352 4 роки тому +2

    So the client does not have to provide it's own certificate? Or is that optional?

    • @devcentral
      @devcentral  4 роки тому +1

      Hi Chilly Vanilly...great question! The client is not required to provide its certificate unless the server is configured to require client authentication. Then, the client would need to present a valid certificate to prove who they are in order for the handshake to complete. Thanks!

    • @chillyvanilly6352
      @chillyvanilly6352 4 роки тому +1

      @@devcentral Ah, okay, thank you kindly for the quick reply! Great vid btw!

    • @HughJass-jv2lt
      @HughJass-jv2lt 3 роки тому +2

      @@chillyvanilly6352 Cliennt's usually provide a username/password to CONFIRM who they are.
      Thats the reason you are able to "LOG IN" in order to read your email.
      :]

  • @adedejiemmanuel1
    @adedejiemmanuel1 3 роки тому +1

    In what sequence will TCP handshake and TLS handshake happen? Which one happens first in a connection?

    • @devcentral
      @devcentral  3 роки тому

      Hi Azza...great question! The TCP handshake will happen first and then the TLS handshake. Thanks!

  • @stenly311
    @stenly311 3 роки тому +1

    Would be great to know the reason why the client does not send the calculated primary key right away to the server instead of the pre-master secret/key? Only the server can decrypt that message anyway ...

    • @devcentral
      @devcentral  3 роки тому

      Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

  • @gursimrantiwana2319
    @gursimrantiwana2319 2 роки тому +3

    what technology is he using to present? Is this a camera trick or a special screen?

    • @devcentral
      @devcentral  2 роки тому

      Behind the Scenes: ua-cam.com/video/U7E_L4wCPTc/v-deo.html

  • @shreddder999
    @shreddder999 4 роки тому +2

    Is this allowed? Doesn't it have to be an elbow bump?

  • @hnasr
    @hnasr 5 років тому +5

    Thank you 😊 is this tls 1.2 or 1.3?

    • @devcentral
      @devcentral  5 років тому +2

      This is TLS 1.2 and prior. I did a TLS 1.3 handshake video here: ua-cam.com/video/yPdJVvSyMqk/v-deo.html

    • @theartist8835
      @theartist8835 4 роки тому

      you here Hussein ?

  • @lukecaruana7062
    @lukecaruana7062 2 роки тому +1

    super fkng awesome explaination

    • @devcentral
      @devcentral  2 роки тому

      Thank you so much and thanks for the comment!

  • @ayanSaha13291
    @ayanSaha13291 2 роки тому +1

    Nice explanation! Thank you.

    • @devcentral
      @devcentral  2 роки тому

      Glad you liked it and we really appreciate the comment!

  • @omkarsawant6602
    @omkarsawant6602 3 роки тому +1

    Very Informative, thanks

  • @neuroboost2585
    @neuroboost2585 2 роки тому +1

    I don't understand when Difie Hellaman is used here. And why is it actually needed? Why a signed certificate with public key is not enough?

    • @devcentral
      @devcentral  2 роки тому +1

      Thanks for the great question! In this particular example, the key exchange is RSA. So, you wouldn't see Diffie Hellman in this specific example. Here's a video of how Diffie Hellman would be used: ua-cam.com/video/pa4osob1XOk/v-deo.html

    • @neuroboost2585
      @neuroboost2585 2 роки тому

      @@devcentral Thanks man :)

  • @adam_hd
    @adam_hd 2 роки тому +1

    Thank youuu

  • @juliantoon4502
    @juliantoon4502 2 роки тому +1

    another good explanation need to watch a few times

    • @devcentral
      @devcentral  2 роки тому

      Glad you liked it and we appreciate the comment!

  • @Zen-lz1hc
    @Zen-lz1hc 2 роки тому +1

    That was entertaining to watch :)
    Thanks.

  • @omparikh4426
    @omparikh4426 4 роки тому +3

    Great Content! can you please discuss tls upgrade for smtp server?

  • @jasonb3200
    @jasonb3200 4 роки тому +1

    beginner question here... why not just the client generate the symmetric key, encrypt it with the public key, send it to the server. The server decrypts the message with its private key to obtain the shared symmetric key?

    • @JakeGPictures
      @JakeGPictures 4 роки тому

      Jason, the client needs to verify that the server is who they say they are before sending it’s own key, hence it first negotiates with the server to get the servers public certificate. Once the client has the certificate and public key it checks with a certificate authority (third party check which is briefly mentioned, but not drawn in the video) to verify the server is who the client expects it to be, only then will the client start negotiating symmetric keys.

    • @jasonb3200
      @jasonb3200 4 роки тому

      @Jeggle Publishing Thank you for taking the time. I understand the initial authentication handshake but I appreciate you not making that assumption. My question pertains to what happens after, the necessity of the simultaneous calculation on both sides with the premaster as input to arrive at the symmetric encryption key. Could the client just have come up with this symmetric key, encrypt with the server's public key, send it. both sides acknowledge to use the symmetric key from then on?

    • @HughJass-jv2lt
      @HughJass-jv2lt 3 роки тому +1

      @@jasonb3200 LOL
      Honestly... what you proposed... is basically what happens anyway.
      LOL
      You're saying that, after the client CONFIRMS that the server is REALLY who it claims to be....
      "WHy doesn't the client just SEND the symmetric key directly?"
      But.. it doesn't.
      instead, it sends the *Pre-shared master key.*
      Okay... so.... what exactly is that about?
      Well... its basically the *recipe* "for" the symmetric key.
      It's the equivalent to "ME" needing to send "YOU" my grandma *special* German Chocolate cake.
      i have the ingredients... i have the Oven... and i have the recipe....
      so i could put in the *TIME & EFFORT* to "bake the cake" and then send it to you.
      Or,
      at the end of the day... i know that:
      You already have the Ingredients,
      You already have an Oven....
      So... it's actually easier if i just *SEND you my grandma's RECIPE...* and then you can BAKE the cake yourself.
      At the end of the day.... think about it this way:
      which is EASIER to send to someone:
      a) a German Chocolate Cake,
      or
      b) the *recipe* for a German Chocolate cake.
      ?
      The key exchange probably follows the *same* reasoning.
      :]

  • @skitz241
    @skitz241 2 роки тому +1

    amazing vid thanks so much

    • @devcentral
      @devcentral  2 роки тому +1

      Glad you liked it and thanks for the comment!!

  • @satksd
    @satksd 2 роки тому +1

    Thanks and that was great video. Have one question in the actual data transfer , the data is encrypted with symmetric encryption and the symmetric key is encrypted with asymmetric encryption for each session?

    • @devcentral
      @devcentral  2 роки тому +1

      Thanks for the comment satksd! The whole point of the asymmetric encryption is to share the encryption keys for the symmetric encryption. So, for a given session, the client and server will begin by using asymmetric encryption to share the keys that they will both use for the symmetric encryption. The symmetric encryption is used for encrypting all the data that is sent between the client and server during that session. So, once the symmetric encryption keys are exchanged (via the asymmetric encryption), then the asymmetric encryption is not needed any more until a new session is established and new keys need to be exchanged.

  • @srimalnishantha6700
    @srimalnishantha6700 Рік тому +1

    Well explained. thanks a lot 👍

    • @devcentral
      @devcentral  Рік тому

      Glad you liked it and we appreciate the comment!

  • @puwanatth
    @puwanatth 2 роки тому +1

    amazing and easy to understand

    • @devcentral
      @devcentral  2 роки тому

      We appreciate the comment and glad you enjoyed it!

  • @houseofdiego
    @houseofdiego 4 роки тому +1

    How is the symmetric key generated, exactly? And how can the server generate it in a way that matches what the client generates?

    • @akashnautiyal8207
      @akashnautiyal8207 3 роки тому

      they use diffie hellman key exchange

    • @HughJass-jv2lt
      @HughJass-jv2lt 3 роки тому

      No, Akash... Diffie Hellam does NOT have to be used.
      Remember,
      the client sends over the *Pre-shared master key.*
      Okay... so what's that exactly?
      Well... its basically the *recipe* for the "symmetric key."
      However, the client does NOT send the "recipe" in *clear text.*
      Instead, the client ENCRYPTS the recipe using the Server's Public Key (aka, the certificate)...
      and THEN its sends it to the server.
      :]

  • @GusRuss89
    @GusRuss89 5 років тому +30

    I'm left with one burning question.
    How did you learn to write backwards so well?

    • @madinakydyralieva3123
      @madinakydyralieva3123 5 років тому

      I wanted to ask the same question

    • @SaitoNakamura
      @SaitoNakamura 5 років тому +16

      I'm pretty sure they've just flipped the video horizontally

    • @AamirSuhailDar
      @AamirSuhailDar 5 років тому +2

      They just flip while recording. He is not lefty by the way. Recording does the job here.

    • @rafaelveggi
      @rafaelveggi 5 років тому +1

      ​@@egregis21 I can read NEON on his pen at 7:09, looks like he is skillfully writing backwards.

    • @BalynOmavel
      @BalynOmavel 4 роки тому

      @Narendra Solanki But title on his shirt???

  • @ankurrajput7506
    @ankurrajput7506 3 роки тому +1

    Awesome explanation.
    But I didn't get the difference between Pre-master secret and symmetric key. As per my understanding they are different names to the same key. Could someone please correct me?

    • @devcentral
      @devcentral  3 роки тому +1

      Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

    • @ankurrajput7506
      @ankurrajput7506 3 роки тому +1

      @@devcentral Thanks a lot 😀

  • @benb2492
    @benb2492 3 роки тому +2

    Man this is TECH NF

  • @zizifn9142
    @zizifn9142 3 роки тому +1

    this guy know things...

    • @devcentral
      @devcentral  3 роки тому

      glad you enjoyed the video!

  • @mikexue5104
    @mikexue5104 3 роки тому +1

    why both sides can't use 'pre-master key' directly, while instead of using another calculated 'symmetric key' which derived from 'pre-master key'? nonsense

    • @devcentral
      @devcentral  3 роки тому

      Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

  • @Joallyson
    @Joallyson 3 роки тому +2

    Amazing!

  • @antonfernando8409
    @antonfernando8409 2 роки тому +1

    cool presentation. Questions: is the pre-master key actually exchanged, if so, what if man in the middle learned it, can it be used to create the eventual asymmetric key? Meaning during the TLS handshake is there vulnerability? 2nd question, is the final symmetric key ever exchanged? thanks.

    • @Flixus98
      @Flixus98 2 роки тому

      The pre master secret is shared but encrypted with the public key of the server (found in the server certificate). That way even if someone can tap into the message they cannot decrypt it unless they know the servers private key.

  • @zes3813
    @zes3813 3 роки тому

    no such thing as hellox or handshakex etc about it, ts just machinex, no nerx, cepitxuxyuax, any say any nmw

  • @paritoshd9776
    @paritoshd9776 2 роки тому

    Does it protect TCP header and payload both? Or just the payload?

  • @christopherjholland
    @christopherjholland 3 роки тому +1

    Does symmetric key encryption used on top of the asymmetrical encryption, or do both nodes switch over to symmetric encryption? If so, why not asymmetrical to host and symmetric back to client?

    • @devcentral
      @devcentral  3 роки тому +1

      Hi Christopher...great questions! The asymmetric encryption is used at the beginning of the handshake and the primary purpose of this is to share/create the keys that will be used in the symmetric encryption. Both sides start with asymmetric and then (once the symmetric keys have been created and verified), they both move to symmetric encryption for the duration of the session. I hope this helps!

    • @christopherjholland
      @christopherjholland 3 роки тому +1

      @@devcentral I figured that had to happen somewhere. Thank you

  • @lathamanickavasagam5529
    @lathamanickavasagam5529 Рік тому

    each client generates a unique symmetric key, how does the server stores all these symmetric keys ? if million unique users hit a website does that mean that the server stores million symmetric keys?

  • @zakb.7108
    @zakb.7108 Рік тому +1

    Perfect explanation. I thought every time we encrypt with server certificate public key the whole time but it's not.

    • @devcentral
      @devcentral  Рік тому

      Thanks for the comment and glad you enjoyed the video!!

  • @sulekha3771
    @sulekha3771 3 роки тому +1

    im a little confused... wouldn't it suffice if only one side generated a symmetric key? why is it necessary that even though it's the same symmetric key in a way another one would be generated by the web server?

    • @devcentral
      @devcentral  3 роки тому

      Great question! In order for the cryptography to work, one side must encrypt the data and then the other side must be able to decrypt the data so they can read it. The way symmetric cryptography works is that the same key (same value) does both the encrypting and decrypting. So, if only one side had the key, then they would be able to encrypt the data, but the other side wouldn't be able to decrypt it. So, both sides need to compute the exact same symmetric key so that they can each use that key to encrypt/decrypt. I hope this helps!

    • @sulekha3771
      @sulekha3771 3 роки тому

      @@devcentral That makes sense!. This computing of the same symmetric key applies to all symmetric encryption right and not only in this case scenario?

    • @devcentral
      @devcentral  3 роки тому

      @@sulekha3771 yes, all symmetric encryption requires that the sender and receiver both have the same key.

    • @sulekha3771
      @sulekha3771 3 роки тому +1

      @@devcentral I know but rather than both the sender and receiver having 1 key as I thought before they will both compute the same key (individually) to use to encrypt & decrypt data

    • @devcentral
      @devcentral  3 роки тому

      @@sulekha3771 yes...that's right!

  • @mannylenis9312
    @mannylenis9312 Рік тому

    Great Video. One question, how often does that process kick off?

  • @techevangelist8373
    @techevangelist8373 4 роки тому +1

    Half truth. Encrypting with public key and decrypting with the corresponding private key is old RSA days. Now we use things like dh or edh for deriving the symmetrical key on both ends. I don't know why most people hide these in their explanation.

    • @devcentral
      @devcentral  4 роки тому

      Hi tech evangelist...thanks for the comment! You are correct that the RSA key exchange is highlighted here. But, the overall concept of TLS handshake still stands. For more on Diffie-Hellman, we did another video here: ua-cam.com/video/pa4osob1XOk/v-deo.html

  • @angelic123ish
    @angelic123ish 5 років тому +1

    So, we can get 1 symmetric key (ONLY) out of Pre Master Secret ? The reason I ask, if both server and client are able to generate 1 symmetric key out of 1 PMS, I would think the answer is 1.

    • @devcentral
      @devcentral  5 років тому +1

      Hi...great question! The purpose of the Pre Master Secret is to ultimately create a shared symmetric key that the client and server can both use for the duration of that particular session. When the session is over (or renegotiated, etc), then the client and server will generate a new symmetric key for the new session. There would only need to be one pre master secret used to generate the shared symmetric key for a given session. But, like I mentioned, this entire process would happen again for any new sessions between the client and server (or a different client and the server). I hope this helps!

    • @angelic123ish
      @angelic123ish 5 років тому +1

      @@devcentral Thank you for the explanation.

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому

      F5 DevCentral Wrong. The master secret can be used to generate any number of session keys within the session.

  • @sagarvyas3776
    @sagarvyas3776 2 роки тому +1

    Its really amazing explanation on TLS handshake Thank you ... Just for my curiosity which application you used to record video with screen whiteboard option.

    • @devcentral
      @devcentral  2 роки тому

      Thanks for the comment! This is how we create these: ua-cam.com/video/U7E_L4wCPTc/v-deo.html

  • @gauravchimanji6920
    @gauravchimanji6920 3 роки тому +1

    Great Video..!! One quick question.. How does the client verify that the (certificate and the public key) is coming from Big-IP not from an anonymous attacker?

    • @user-cd6vy2jg6f
      @user-cd6vy2jg6f 3 роки тому

      I believe this is what Cert authorities are for / root cert on the client.
      But would love a detailed answer

    • @devcentral
      @devcentral  3 роки тому

      Great question! The certificate is signed by the Certificate Authority (CA) so the client can use that signature as the validation that the certificate is from the proper sender. The server typically sends a Certificate Signing Request (CSR) to the CA to get a signed certificate for the server. Then, the server can send that signed certificate to the client so that the client knows it has been signed by the CA.

  • @JamesEtc3417
    @JamesEtc3417 2 роки тому +2

    Wow this is great. It takes months to truly get your head around this but vids like this make it so easy to refresh my memory

  • @claudedjale3864
    @claudedjale3864 2 роки тому +1

    Wow, it is amazing to know what happens behind the scenes. I would like to meet the people who create/invent these things.

  • @caroledecouto1032
    @caroledecouto1032 4 роки тому +1

    what does TLS stand for?

    • @devcentral
      @devcentral  4 роки тому

      Transport Layer Security. It's the successor to Secure Sockets Layer (SSL). Here's more info on it: en.wikipedia.org/wiki/Transport_Layer_Security

    • @HughJass-jv2lt
      @HughJass-jv2lt 3 роки тому +1

      T.otally
      L.ame
      S.ecurity
      ;)

  • @Mike-mp6cd
    @Mike-mp6cd 4 роки тому +1

    whats the role of "client random number" and :"server random number" in generating the final symmetric key ?

    • @devcentral
      @devcentral  4 роки тому

      Great question, Mike! The random numbers are used to calculate the symmetric key used for the bulk encryption algorithm. I did a video on how the RSA algorithm works here: ua-cam.com/video/rVQpK6NcYIE/v-deo.html and I also did one on how the Diffie-Hellman algorithm works here: ua-cam.com/video/pa4osob1XOk/v-deo.html
      I hope this helps!

  • @buffaloofm7119
    @buffaloofm7119 2 роки тому +1

    nice 🔥🔥

  • @itihas9958
    @itihas9958 5 років тому +1

    What's stopping a hacker from using the symmetric key on the client side to communicate with server after it's generated? Does that question even make sense?

    • @devcentral
      @devcentral  5 років тому +1

      Great question!! If an attacker were to get the symmetric key from the client, he could definitely decrypt all communication between client and server. This is why it is so important to secure the symmetric key. This is also one of the reasons many clients and servers are moving to "Perfect Forward Secret" ciphers so that the symmetric key changes with every new session. Here's more info on Perfect Forward Secrecy in case you are interested: ua-cam.com/video/IkM3R-KDu44/v-deo.html
      Hope this helps!

  • @tushar8133a
    @tushar8133a 3 роки тому +1

    Superb!

  • @ahhu.
    @ahhu. 3 роки тому +1

    Thanks

  • @saileshb6758
    @saileshb6758 3 роки тому +2

    Thanks! Pretty good explanation of how the TSL handshake works. Got a question around how the symmetric key is generated. So based on the video looks like, we create that pre-master secret from contents from the certificate that the server shared plus a key that client generates using some tools/security suite on the fly. Client then encrypts it using the public key that server shared in the certificate. Then client send it to the server. Server then decrypts it with the private key. The resultant decrypted content would then content the shared encryption key. Is my understanding right? Is there a security suite that needs to be present in the client to create such shared key? So shared encryption key generation is the responsibility of the client, correct?

    • @devcentral
      @devcentral  3 роки тому +4

      Hi Sailesh...great question! When the client initially contacts the server to initiate the secure connection (CLIENT HELLO for TLS), the client sends a list of cipher suites that are available for use on the client browser. In that cipher suite is a list of possible symmetric encryption algorithms that could be used (most of the time, the symmetric encryption type is AES). When the server gets the list of cipher suites from the client, the server checks to see if any of the cipher suites match what the server is willing to use (the server has a pre-loaded list of cipher suites that are configured for that specific server). The server picks the cipher suite that best matches its list of cipher suites (at least one has to match or else the connection gets terminated). Then, when the cipher suite is established, it tells the client and server exactly what kind of encryption methods will be used for that session. For example, Diffie Hellman could be used for key exchange while AES is used for symmetric encryption. So really, both the client and the server are involved in the creation of the symmetric encryption key, but the server is the one that gets to drive the choices (with picking the cipher suite and also sending its public key for initial encryption). I hope this helps!

    • @devcentral
      @devcentral  3 роки тому +2

      And, for more on cipher suites, you can watch this lightboard lesson. Thanks!
      ua-cam.com/video/ZM3tXhPV8v0/v-deo.html

    • @saileshb6758
      @saileshb6758 3 роки тому +1

      @@devcentral I feel that things are lot clearer now about the symmetric key mechanism now that I have gone through few of the videos and the comment from you guys here. Agree that both server and clients are involved. But, someone still has to create the shared key that both the party agree to use. Are they generated on the fly? Am I missing something?

    • @saileshb6758
      @saileshb6758 3 роки тому +1

      @@devcentral Thanks for sharing. I had already seen that video which gave much better understanding about shared encryption. But, even going through them things were not clear how shared encryption key gets generated.

  • @postman12
    @postman12 Рік тому

    Where is the CA (Certificate Authority)?

  • @joshuaeuceda4635
    @joshuaeuceda4635 3 роки тому +2

    The waterfall analogy was outstanding, provided an excellent framework for further study.

  • @pankajchaturvedi3176
    @pankajchaturvedi3176 2 роки тому +2

    The most thorough explanation of TLS Handshake. Thank you!

  • @jaidahmed2955
    @jaidahmed2955 2 роки тому

    Hi all
    Is anyone can help me here if i disable TLS 1.0 and enable TLS 1.1 and 1.2 then my crystal reports is not working

    • @devcentral
      @devcentral  2 роки тому

      Hi and thanks for the comment. There are a number of articles and forums about this. try: answers.sap.com/questions/162610/2269180---disabling-tls-10-may-cause-crystal-repor.html
      and
      userapps.support.sap.com/sap/support/knowledge/en/2269180
      hope that helps!!

  • @olliveraira6122
    @olliveraira6122 Рік тому

    What I dont understand is how this makes the data secure by any means, cant a cleverly designed software follow all this communication and end up with the same symmetric key at the end (assuming the attacker is able to sniff every single package sent back & forth)?

    • @perburr
      @perburr Місяць тому

      After receiving the server's certificate, the client generates a Pre-Master-Secret. They then encrypt this with the server's public key (extracted from the server's certificate). The client then sends the encrypted Pre-Master-Secret to the server. This is the crucial bit: only the server will be able to decrypt the encrypted Pre-Master-Secret. This is because only they (the server) possess the private key required to decrypt anything that is encrypted with their own public key.
      So even if an attacker could sniff all the packets sent between client/server, they wouldn't be able to decrypt the encrypted Pre-Master-Secret (since they don't possess the server's private key).

  • @gagangupta1255
    @gagangupta1255 4 роки тому +1

    Awesome video

  • @Zohdiak
    @Zohdiak 2 роки тому +2

    Thank you for explaining things perfectly!

    • @devcentral
      @devcentral  2 роки тому

      And thank you for the comment!!

  • @ramkumark8901
    @ramkumark8901 3 роки тому +1

    after went through so many other videos. Finally got clear picture only from your explanation. Very good explanation, thanks !

  • @Drakelett
    @Drakelett 4 роки тому

    Why bother with a pre-master secret? If they both use the pre-master secret to generate a symmetric key, why doesn't the client just generate the symmetric key and send that?

  • @ravisattigeri_1
    @ravisattigeri_1 5 років тому

    SGVP4641000|4Sep19
    Notes
    Client
    1. Client Hello
    5. Key Exchange(Change Cipher Spec)
    6. Client Finished
    Server(BIG IP)
    2. Server Hello
    3. Certificate- Public Key
    4. Server Hello Done
    7.Change Cipher Spec
    8.Server Finished.
    9. Bulk Encrypted Data Transfer(Symmetric Encryption Key)

  • @siddharthmanumusic
    @siddharthmanumusic 5 років тому +1

    How does it complete the transaction and tell the other side not to use that private key anymore?

    • @devcentral
      @devcentral  5 років тому +1

      Great question! The "change cipher spec" message essentially alerts the other side that it's time to move to symmetric encryption. Plus, all future messages after that are encrypted using the symmetric key instead of the public/private key pair. Thanks!

    • @siddharthmanumusic
      @siddharthmanumusic 5 років тому +1

      Thanks for the quick reply! How is the data transfer process terminated and the symmetric key discarded?

    • @devcentral
      @devcentral  5 років тому +1

      @@siddharthmanumusic once the client and server establish the shared symmetric key, they use that key for encryption/decryption for the duration of that specific user session. Sessions typically last for as long as the client has the browser open to that specific page (or pages) or until there is no more client activity (like, when you visit a banking page and then don't take any action, they will sometimes ask if you are still there or want to extend the session). Thanks!

    • @siddharthmanumusic
      @siddharthmanumusic 5 років тому

      F5 DevCentral Thank you! So when the TCP session ends, at the protocol level...

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому

      Siddharth Manu The session key can be changed within the session, via an abbreviated handshake.

  • @bajobozic4869
    @bajobozic4869 6 років тому +1

    Great stuff,thanks for sharing!!!

  • @imashish86
    @imashish86 4 роки тому +1

    This is CooL. Better explanation than Google's IT certification video! Thanks a lot!!!

  • @godnonamesleft
    @godnonamesleft 5 років тому +2

    Very good. Thank you. I would like to learn how the symmetric key is first generated by the client.

    • @devcentral
      @devcentral  5 років тому

      Great question! The math behind these calculations can get pretty tricky, but here's a link to some good info on the key generation topic: stackoverflow.com/questions/3936071/how-does-browser-generate-symmetric-key-during-ssl-handshake

  • @mikexue5104
    @mikexue5104 3 роки тому

    why both sides can't use 'pre-master key' directly, while instead of using another calculated 'symmetric key' which derived from 'pre-master key'? nonsense

  • @swayamraina4564
    @swayamraina4564 5 років тому

    I have a doubt,
    Since you said Pre-master secret is generated from the public key that means the logic to derive the secret is embedded into the client which makes MITM possible at this very point.
    As per this post, security.stackexchange.com/questions/63971/how-is-the-premaster-secret-used-in-tls-generated
    it has no relation with the public key of the server.
    Also, is the Server HELLO, certificate sharing done in separate calls (as depicted by you) ? if yes, isn't this bandwidth wastage?
    could you please clear out these doubts?

  • @viky789
    @viky789 5 років тому +2

    Just what i was looking for. Appreciated

  • @perburr
    @perburr Місяць тому

    Excellent break-down of the TLS handshake. John's explanations are clear and easy to understand. Thank you!

  • @sailendrapavan3475
    @sailendrapavan3475 3 роки тому +1

    Excellent explanation. Thank you.

  • @mikexue5104
    @mikexue5104 4 роки тому

    nice video. but use of pre-master-secret anf symantric key is NOT for efficiency, it should be for client unique identification in upcoming communications.
    public key can be used by client to encrypt everything, but any other faker can also use it to send fake messages to the server, while server can't distinguish between them at this time. a pre-master-secret/symmetric key will gurranty server only talks to the intended client and drop any other packets from nowhere.

  • @simonlenz7057
    @simonlenz7057 4 роки тому

    why does the client send the Pre Master secret and not immediately the symmetric key?

    • @devcentral
      @devcentral  4 роки тому

      Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

  • @rheumaticharm9551
    @rheumaticharm9551 2 роки тому

    I got everything but I have a single doubt. Pre master secret is derived from public key. And then it is encrypted and shared with the server. And then server has the same pre master key. And now both client and server makes a symmetric key. How? What kinds of algo do they use? And how do they ensure that they make the same symmetric key?

    • @rheumaticharm9551
      @rheumaticharm9551 2 роки тому

      And where is this symmetric key stored in the server?

    • @rheumaticharm9551
      @rheumaticharm9551 2 роки тому

      And how are these public keys and private keys decided by the server before sending to client? During the deployed of the application? Do the developer provide public and private keys?

  • @errorboom8888
    @errorboom8888 3 роки тому +1

    But what is the pre master secret? ;/

    • @devcentral
      @devcentral  3 роки тому

      Great question! The pre-master secret and the symmetric key are two different things. The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

  • @YouTubist666
    @YouTubist666 4 роки тому +1

    Excellent discussion. Thanks!!

  • @kanetla8692
    @kanetla8692 3 роки тому

    As far as i know there's nonce in the handshake process. I know it's used to prevent some replay attack but I wonder if nonce is used to create pre master secret.
    Or Is pms only genereated from server's public key?

  • @emmanuelsolano6833
    @emmanuelsolano6833 2 роки тому +1

    Very well explained, pretty useful.

    • @devcentral
      @devcentral  2 роки тому

      Glad it helped and thanks for the comment!

  • @thecandel5479
    @thecandel5479 5 років тому +1

    very, very, very nice. Thank you very much. Small question: what means by (bulk data)?

    • @devcentral
      @devcentral  5 років тому

      glad you enjoyed it! bulk encryption (and thereby, bulk data) is the data transmitted between client and server after the key exchange takes place. This is, by far, the most data transmitted between client and server. The key exchange is simply there to exchange the keys that will be used in the symmetric (bulk) encryption.

  • @terrancepinkney777
    @terrancepinkney777 4 роки тому +2

    Thank you for helping me better understand this. I'm studying for my cert and I kinda understood reading it but this makes more sense! Awesome video and explanation.

    • @devcentral
      @devcentral  4 роки тому

      Thanks Terrance...glad you enjoyed the video!

  • @isthereanyname
    @isthereanyname 4 роки тому +1

    Very good. Well done.

  • @mortalbm
    @mortalbm 2 роки тому +1

    Best explain I'd ever seen.

    • @devcentral
      @devcentral  2 роки тому

      We appreciate the comment! Glad you liked it!!

  • @diegoramos27
    @diegoramos27 4 роки тому +1

    very good video thanks for sharing, one question, what is the encryption algorithm used to exchange communication between client and server ? is it AES ? thanks

    • @devcentral
      @devcentral  4 роки тому +1

      Hi Diego...great question! The encryption algorithm used to exchange communication between client and server is negotiated in the initial part of the TLS handshake. That said, AES is almost always used in modern web applications today. I hope this helps!

    • @diegoramos27
      @diegoramos27 4 роки тому

      @@devcentral Thanks for the reply ! another question... if you proceed to a site which is not using a valid certificate and then you get the warning and click on "proceed to unsafe" does the ssl handshake still happen ? if so, does encryption happen even if the certificate could not be validated ? Thanks

    • @devcentral
      @devcentral  4 роки тому

      @@diegoramos27 great question! yes, even if the certificate is not valid, the TLS handshake should still complete (although it's possible to configure to drop the connection if the certificate is invalid). In this case, the client and server would still have an encrypted connection, but the client just wouldn't know for sure that the web server is the correct one.

  • @eoikiqwerty6148
    @eoikiqwerty6148 7 років тому +3

    nice videos. like your explanation on these topics. keep em coming.
    maybe next video about in depth certificate's?

    • @devcentral
      @devcentral  7 років тому

      thanks!

    • @devcentral
      @devcentral  7 років тому +4

      Also, here's another one I did on "what's in a digital certificate?"
      ua-cam.com/video/XmIlynkR8J8/v-deo.html
      Enjoy!

  • @TheodorSirmanoff
    @TheodorSirmanoff 3 роки тому +2

    Thank you, but in my feeling is that it's not enough organized as presentation. Cuts, got back several times, to add this and that. BIG/IP or Server: chose one of them and keep it. Of course I'm speaking for myself, but I would prefer you to follow much more your paper you are looking at in your presentation. Anyway, thank you

  • @ABDULKARIMHOMAIDI
    @ABDULKARIMHOMAIDI 8 місяців тому

    THANKS MAN

  • @md.bidyuth6441
    @md.bidyuth6441 5 місяців тому

    Thanks Xians for making this concept so easy.

  • @skannank92
    @skannank92 5 років тому +2

    Does the Master- Secret key keeps changing?

    • @devcentral
      @devcentral  5 років тому +3

      Hi kannan, great question! The secret key for the bulk encryption (i.e. AES) can change with every new session between the client and server. But, it doesn't always have to do this. It depends on how the server is configured to handle the encryption. For newer versions of TLS (1.3), the secret key will be required to change with every session between client and server. But for older TLS versions (1.2 and older), the key doesn't have to change with every new session. Thanks!

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому

      F5 DevCentral That's not what he asked, and it isn't correct. The Master Secret doesn't change until the session is invalidated, and can be used to generate numerous session keys within that session.

    • @devcentral
      @devcentral  4 роки тому +1

      @@EJP286CRSKW, the point of the initial response was to say that the type of key exchange can affect the frequency of key changing. In RSA, the Pre-Master secret is computed in the browser. This Pre-Master secret is encrypted with the server's public key and shared with the server so that the client and server can later create the Master secret. In Diffie-Hellman, the client and server generate a new key pair for each session. The private keys of both client and server are deleted immediately once the Pre-Master secret is computed. Still, the Pre-Master secret is used later to create the Master secret. The point here is that, using Diffie-Hellman (or DHE), the keys can (and will) change with each new session. That said, it is also true that, when the Master secret is generated, there are a variety of "session" keys that are created. The RFC lists these as "client write MAC key, server write MAC key, client write encryption key, server write encryption key, client write initialization vector (IV), and server write IV. Not all of these will be used (the IV keys are not always needed) but it is true that more than one set of "session" keys will come out of a given Master secret. Thanks for contributing to the conversation on this.

  • @rainfallen1064
    @rainfallen1064 3 роки тому +1

    Very good explanation!

  • @atercat
    @atercat 7 років тому +2

    Why doesn't the client just send a symmetric key to the big IP? What is the reason of the additional step with a pre-master secret?

    • @devcentral
      @devcentral  7 років тому +2

      Great question! The main point of a pre-master secret is to provide greater consistency between TLS cipher suites. Here's a thread with a little more info: crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls

    • @atercat
      @atercat 7 років тому

      I see now. Thank you for your videos. You're doing a great job!

    • @johnparker2007
      @johnparker2007 6 років тому

      Bro, Symmetric is based on PMK which is generated via public key of server ,so we need to have these steps

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому

      F5 DevCentral Not really. The basic idea is never to transmit the session key, so it can never be intercepted.

  • @Vikash0125
    @Vikash0125 4 роки тому

    As far as I can understand, the first 4 steps(until hello done from big ip) are not encrypted . Or the first hello from client also includes its public key. I am confused. Please explain.

    • @mikexue5104
      @mikexue5104 4 роки тому +2

      client never send its public key to server, client only use server's public key to encrypt message, while server can decrypt the message coming from client with its private key.
      after decryption, server knows the suggested pre-master-secret from client, then use its private key to encrypt pre-master-secret to create a symmetric key, send it back to client, client can decrypt this symmetric key by servers public key, if client get the original pre-master-secret, then it proves client is talking to the intented server, because by now no 3rd party knows this newly created symmetric key, for later communications client can use this symmetric key to encrypt, and server can use the same symmetric key for decryption.

  • @Varuntux
    @Varuntux 5 років тому +1

    very nice explanation, thank you very much.

  • @harshitshrivastava781
    @harshitshrivastava781 6 років тому +1

    Thanks for the video. One question I have.
    You mentioned that when server sends its certificate to the client, it also sends its public key. In this case, any MITM attacker can replace this certificate with its self-generated certificate signed using his private key and send to the client with his public key.
    So, client will have no way to identify if the cert+public key it received is from the actual server or from the attacker. Is my understanding correct?

    • @devcentral
      @devcentral  6 років тому +2

      Hi Harshit...great question! You are exactly right that a MITM could step in and send a self-generated certificate signed by his own private key. The issue, though, is that the MITM will have to get someone/something to sign the certificate. The easy answer is for the attacker to sign the certificate himself, but all modern browsers will notice that a certificate has been "self-signed" and will prompt a warning page to the user saying that the page you are attempting to view has a certificate that has been self-signed. The idea is that the Certificate Authority has to sign the certificate in order to avoid the browser warning page. And, a Certificate Authority is not going to issue/sign a certificate for a secure website that already has a valid certificate. The Certificate Authority is supposed to check these things before they ever issue a certificate and public/private key for a given website.
      Here's a quick article that I found that goes into a bit more detail: www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/
      I hope this helps!

    • @harshitshrivastava781
      @harshitshrivastava781 6 років тому +1

      @@devcentral Thanks for the detailed explanation. Now I got the answer.

    • @bonbonpony
      @bonbonpony 5 років тому

      @@devcentral But this in turn requires the Certificate Authorities to exists, so we're back to square one, because this requires trusting the Authorities :P And they can be the biggest Men In The Middle here, because of the scale of their power and lack of suspicion from the clients :q Imagine someone hacks the CA and swaps the keys to their own (happened already). Why do we need CAs anyway? Can't we do a two-sided key exchange without them? :q I see this entire CA thing as another huge pyramid scheme to squeeze money from people for selling certificates to them :q

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому +1

      Bon Bon The answer is not correct. What he's omitted is that the CertificateVerify message which is sent after the Certificate message contains a digital signature signed by the private key, and that can be verified by its public key. So only the owner of that public key can create a valid CertificateVerify message.

    • @bala2k2
      @bala2k2 3 роки тому +1

      EJP is correct .. Every browsers have CA root bundles installed which has the public key of trusted CA's who able to verfiry the sigature in certifcate which signed using their(CA) own private key at the time of CSR.. So any MITM hacked and replaced the certificate ,signature cannot be verified by browser and I think you will see warning message or connection may be dropped..

  • @matmaximiliano
    @matmaximiliano 4 роки тому +2

    Amazing explanation! Thank you for sharing!

  • @mrhex5187
    @mrhex5187 7 років тому +1

    So, the communication starts with asymmetric cryptography and finishes with symmetric cryptography, so we have a hybrid cryptography. Very very good!

    • @christorok1906
      @christorok1906 5 років тому

      The asymmetric part is used for key distribution. The symmetric is used to reduce overhead and retain good performance.

    • @EJP286CRSKW
      @EJP286CRSKW 4 роки тому

      Chris Torok The PKI part is used for authentication. Asymmetric encryption isn't used at all except in the now deprecated DH cipher suites.

  • @praiasteam
    @praiasteam 7 років тому +1

    Great video and explanation! Thank you very much!

  • @kumaravelrajan
    @kumaravelrajan 4 роки тому +1

    Thanks for the video!

  • @vijayshinde8356
    @vijayshinde8356 2 роки тому +1

    Wow ...

  • @lightninginmyhands4878
    @lightninginmyhands4878 5 років тому +1

    Great vid! Now that you have a video about certificates it'd be helpful to have a link to that in this video's description. Thanks

    • @devcentral
      @devcentral  5 років тому

      Great feedback! I just updated it. Thanks!

  • @magnus8664
    @magnus8664 7 років тому

    Could you do an video what describe ChaCha20 and Poly1305 that Chrome/Google uses ?