HTTPS Security | SSL | TLS | Network Protocols | System Design

Поделиться
HTML-код
  • Опубликовано: 16 ноя 2024

Комментарии • 11

  • @universal4334
    @universal4334 14 дней назад

    Pure gold standard content

  • @lovishgoyal2814
    @lovishgoyal2814 5 месяцев назад +1

    Just 1 word........ you are awesome

  • @blacksquadmenswear
    @blacksquadmenswear 3 месяца назад +1

    Awesome explanation ❤

  • @m3hdim3hdi
    @m3hdim3hdi 8 месяцев назад +1

    Thank you great explanation

  • @smritisharan-sfdcamplified
    @smritisharan-sfdcamplified 6 месяцев назад +1

    beyond amazing

  • @M_Novman
    @M_Novman Год назад +1

    Superb!!!! Thanks!!

  • @ravisankarp61
    @ravisankarp61 14 дней назад

    thank you

  • @yrusTube
    @yrusTube Год назад

    Hi nice video and illustrations. What do you use for the illustration and animation?

  • @kumarorlama
    @kumarorlama Год назад +1

    At 13:02, when server sends the CA-private key-signed SSL cert, can middle man just intercept and decrypt using the public key of the signing authority and get access to the public key within SSL ? This CA very verification is still not clear to me

    • @ByteMonk
      @ByteMonk  Год назад +5

      My apologies for the late response. MITM getting access to the public key is not a problem. The name "public" implies it's open to all. The importance of the (public key + SSL cert) is for the client to trust that the Server is the right entity. So if a MITM somehow intercepts the (public key + SSL cert) from the server to client and modifies it. The client will know that, because any modified SSL cert would be invalidated by the client(browser).

    • @ByteMonk
      @ByteMonk  Год назад +6

      Part 2: However if the MITM pretends to be a client and tries to access a secure page, server will have its own authentication setup to tackle that. Which is also known as "client authentication." Its a long answer if you wish to understand, read on.. :)
      During the SSL/TLS handshake, the server can use a feature called client authentication to verify the identity of the client. This is an optional feature that can be enabled by the server, and it is used when the server needs to authenticate the client before allowing access to a protected resource.
      1. Here's how client authentication works:
      2. The server requests the client to provide a client certificate during the SSL/TLS handshake.
      3. The client responds with a certificate containing its public key.
      4. The server verifies the client certificate by checking the digital signature on the certificate using the public key of the Certificate Authority that issued the certificate.
      5. If the client certificate is trusted, the server can authenticate the client and allow access to a protected resource.