disclaimer: I’m just asking to get understanding of the theory behind network traffic encryption, I know this doesn’t happen irl most likely.

Let’s take https connection for example. I like watching revolutionary things on youtube and do not wish for authorities to know what I am watching, we accept here for the sake of showcase that google won’t sell my watch history if asked (LMAO what am I even saying?).
So if I’m not mistaken since youtube has https implemented, our communication is encrypted, the keys are shared only between me and youtube. But when Youtube shares the key with me/my client the first time, is that also encrypted? Wouldn’t the same question keep getting answered until there is something unencrypted? I know this is a bit too much unlikely, but if ISP automated the process of gathering keys and decrypting web traffic for a certain site with them for all users, would that work for them?
I’m taking https here as an example, while I have the same question for like VPN.

EDIT: Thank you everybody. I am not a member of this community, but every comment was a golden experience to read!

  • Melllvar@startrek.websiteEnglish
    43·
    11 months ago

    SSL/TLS, the “S” in HTTPS, and other network encryption protocols such as SSH, use a technique called a Diffie-Hellman key exchange. This is a mode of cryptography where each side generates two keys: a public half and a private half. Anything encrypted with the public half is only decryptable by the associated private half (and vice versa).

    You and Youtube only ever exchange the public halves of your respective key pairs. If someone snoops on the key exchange all they can do is insert spoofed messages, not decrypt real ones.

    Moreover, the keypairs are generated on the fly for each new session rather than reused. This means that even a future compromise of youtube won’t unlock old sessions. This is a concept called forward secrecy.

    Message spoofing is prevented by digital signatures. These also use the Diffie-Hellman principle of pairs of public/private keys, but use separate longer-term key pairs than those used with encryption. The public half of youtube’s signing key, as presented by the server when you connect to it, has to be digitally signed by a well-known public authority whose public signing key was shipped with your web browser.

    • zaknenou@lemmy.dbzer0.comOPEnglish
      7·
      11 months ago

      this is very detailed answer thank you. however I face an ambiguity regarding this:

      This is a mode of cryptography where each side generates two keys: a public half and a private half. Anything encrypted with the public half is only decryptable by the associated private half (and vice versa).

      How can this private half be something that I know, Youtube knows but impossible for the snooper to our communication to know??

      • matthewc@lemmy.world
        15·
        11 months ago

        Your computer generates two keys. One to encrypt a message. One to decrypt the message. The encrypt key is public. The decrypt key is private. Your computer shares the public key with YouTube. The private key is never shared.

        YouTube does the same thing for your computer.

        Your computer will have YouTube’s public key and your computer’s private key…

        Your computer will be able to encrypt messages to send to YouTube that only YouTube will be able to decrypt. Even your computer will not be able to decrypt these messages after it has encrypted them using YouTube’s public key.

        Since the decryption keys are never shared they can’t be snooped. That is why it is only possible for an attacker to encrypt new messages but not read any messages from either sender.

  • Cralder@lemmy.worldEnglish
    40·
    11 months ago

    You are describing symmetric encryption where both parties have the same key. There is something called asymmetric encryption that solves this. Basically you have a public key and a private key. You can give your public key to youtube, they can use that key to encrypt the symmetric key that will be used for the actual communication. The only way to decrypt the symmetric key is by using your private key, which is only known to you. So youtube can safely send it to you so you can decrypt it. Now you both have the same key and nothing was sent unencrypted.

    Well your public key was sent unencrypted but that’s fine because of how asymmetric encryption works.

  • 7heo@lemmy.ml
    4·
    11 months ago

    Seeing as other answers are either links, or wall of texts, I’ll try to keep it short and approachable:

    • Encryption, asymmetrical or symmetrical, relies on private keys being private. Once those keys are compromised, the encryption also is (read on).

    • By default, in the most simplistic form, it doesn’t matter when the content was encrypted, the private key can decrypt it. There are solutions to this problem, making encryption time (or iteration) sensitive.

    • For an attacker with enough means, the private keys can always be exfiltrated, and content can be intercepted, but usually there are much simpler solutions for snooping on encrypted content: the devil is in the (implementation) details (this link is an illustration, and by no means an exhaustive list).

    • Cryptography is always simpler to go around than to break. So never be satisfied with a cryptography only (or protocol only) audit. There are near infinite of ways to neutralize encryption with a single line of code in a client.

    • The architecture is also essential. Client-Server encryption has entirely different use cases than Client-Client encryption (EE2E).

    • And finally, Schneier’s law:

    Any person can invent a security system so clever that she or he can’t think of how to break it.

    • Deckweiss@lemmy.world
      3·
      11 months ago

      However, many clients and servers supporting TLS (including browsers and web servers) are not configured to implement such restrictions. In practice, unless a web service uses Diffie–Hellman key exchange to implement forward secrecy, all of the encrypted web traffic to and from that service can be decrypted by a third party if it obtains the server’s master (private) key; e.g., by means of a court order.

      Same page, security.

      So in the context of OPs example of watching revolutionary content, where it is in the governments interest to protect itself against, one could consider some parts of the TLS protected web compromised.

      • Display Name@lemmy.ml
        1·
        11 months ago

        Yes, if the government has the key, they can read it. Otherwise spying of the NSA would be a little tricky. I’m no pro in this regard but doesn’t the gov/ NSA has a special API to access data of the big companies?

  • banazir@lemmy.ml
    2·
    11 months ago

    Okey, it’s like this: You and youtube both generate two keys, public and private. Public keys are public, anyone can see them. Doesn’t matter. When you send a message to youtube, you encrypt it with their public key. Now, the trick is, the encryption is asymmetric, which means that the message can only be decoded if you also know the private key, which you never send anyone but keep hidden. Right? This way, as long as your private key is secure, you can not realistically decode the encryption from outside just knowing the public key. Thus setting up a secure connection is just an exchange of public keys.

    This is more or less how I understand it.

  • JackGreenEarth@lemm.eeEnglish
    2·
    11 months ago

    Bh sharing, unencrypted, on Lemmy that you like watching revolutionary videos on YouTube, the government now has that data, even if Google wasn’t going to give it to them. I thought I would just add that, as everyone else has explained asymmetric encryption well.

    Also, usually it’s just the content of the website, not the URL itself that is encrypted, so anyone, not just the government, can know what YouTube videos you watch (as the video ID is in the URL) as well as the URL of any other websites you visit.

    • CaptainSpaceman@lemmy.world
      2·
      11 months ago

      The other 2 commenters are wrong. URLs as they appear in your web browser are NOT encrypted when sent over https protocols.

      The only data that is encrypted is POST data, and ONLY if it is sent over HTTPS.

      So for example, a website login page crafts a URL like https://some.example.com/login?sessionID=12345678 and when you log in to the site extra parameters like Username and Password are sent via POST data, then anyone listening to your web traffic (like the NSA or your neighbor with wireshark) will br able to see the website and the sessionID, but not the login details as they will only show up encrypted.

      However, if the site is ran by idiots who pass the data in the URL like this https://some.example.com/login?sessionID=12345678&username=Homer&password=Simpson, then ANYONE listeneing would have your credentials.