Comment on How to selfhost with a VPN

• Laser@feddit.org ⁨20⁩ ⁨hours⁩ ago

  Public key crypto, properly implemented, does prevent MITM attacks.

  It does, but modern public key crypto doesn’t encrypt any client data (RSA key exchange was the only one to my knowledge). It also only verifies the certificates, and the topic was about payload data (i.e. the site you want to view), which asymmetric crypto doesn’t deal with for performance reasons.

  My post was not about “does TLS prevent undetected data manipulation” (it does), but rather if it’s the encryption that is responsible for it (it’s not unless you put AES-GCM into that umbrella term).

  source

  • frezik@lemmy.blahaj.zone ⁨19⁩ ⁨hours⁩ ago

    Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it’s all encrypted.

    Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned). As long as that key was transferred securely and uses a good mode like CBC, an attacker ain’t messing with what’s in there.

    I think you’re confusing the limitations of each building block with how they’re actually implemented together in TLS. The whole suite together is what matters for this thread.

    source

    • Laser@feddit.org ⁨18⁩ ⁨hours⁩ ago

      Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it’s all encrypted.

      I never said it isn’t, but it’s done using symmetric crypto, not public key (asymmetric) crypto.

      Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned).

      Not anymore, this was only true for RSA key exchange, which was deprecated in TLS 1.2 (“Clients MUST NOT offer and servers MUST NOT select RSA cipher suites”). All current suites use ephemeral Diffie-Hellman over elliptic curves for key agreement (also called key exchange, but I find the term somewhat misleading).

      As long as that key was transferred securely and uses a good mode like CBC, an attacker ain’t messing with what’s in there.

      First, CBC isn’t a good mode for multiple reasons, one being performance on the encrypting side, but the other one being the exact reason you’re taking about: it is in fact malleable and as such insecure without authentication (though you can use a CMAC, as long as you use a different key). See pdf-insecurity.org/…/cbc-malleability.html for over example where this exact property is exploited (“Any document format using CBC for encryption is potentially vulnerable to CBC gadgets if a known plaintext is a given, and no integrity protection is applied to the ciphertext.”)

      As I wrote in my comment, I was a bit pedantic, because what was stated was that encryption protects the authenticity, and I explained that, while TLS protects all aspects of data security, it’s encryption doesn’t cover the authenticity.

      Anyhow, the point is rather moot because I’m pretty sure they won’t get a certificate for the IP anyways.

      source