Comment on How to selfhost with a VPN

• humanoidchaos@lemmy.cif.su ⁨3⁩ ⁨weeks⁩ ago

  Thanks. This is new to me and I’m going to be looking into it.

  source

  • turmoil@feddit.org ⁨3⁩ ⁨weeks⁩ ago

    As I use docker for most of my deploys (as you should for websites exposed to the Internet anyway), I can wholeheartedly recommend traefik for this. Basically it has the functionality of nginx, but supports easy Let’s Encrypt certificates.

    source
• Laser@feddit.org ⁨3⁩ ⁨weeks⁩ ago

  Let’s Encrypt are rolling out IP-based certs, you may wanna follow its development. I’m not sure if it could be used for your forwarded VPN port, but it’d be nice anyhow

  It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.

  I believe encryption helps prevent tampering the data between the server and user too. It should prevent for example, someone MITM the connection and injecting malicious content that tells the user to download malware

  No, encryption only protects the confidentiality of data. You need message authentication codes or authenticated encryption to make sure the message hasn’t been transported with. Especially stream ciphers like ChaCha (but also AES in counter mode) are susceptible to malleability attacks, which are super simple yet very dangerous.

  source

  • frezik@lemmy.blahaj.zone ⁨3⁩ ⁨weeks⁩ ago

    Public key crypto, properly implemented, does prevent MITM attacks. TLS does do this, and that’s all that matters here

    source

    • Laser@feddit.org ⁨3⁩ ⁨weeks⁩ 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 ⁨3⁩ ⁨weeks⁩ 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

        • -> View More Comments
  • SteveTech@programming.dev ⁨3⁩ ⁨weeks⁩ ago

    It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.

    They’re ‘shortlived’ 7 day certs, verified using a HTTP challenge. It doesn’t matter who owns the IP, it’s just a matter of who holds the IP.

    source

    • Laser@feddit.org ⁨3⁩ ⁨weeks⁩ ago

      Right, and for the challenge, you need to have access to a privileged port (which usually implies ownership), which you won’t get assigned.

      source

      • stratself@lemdro.id ⁨3⁩ ⁨weeks⁩ ago

        Ah right, completely forgot about that (80 for HTTP-01, 443 for TLS-ALPN-01)

        source