• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 23rd, 2024

help-circle
  • Laser@feddit.orgtoSelfhosted@lemmy.worldHow to selfhost with a VPN
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    17 days 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 https://pdf-insecurity.org/encryption/cbc-malleability.html for one 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.


  • Laser@feddit.orgtoSelfhosted@lemmy.worldHow to selfhost with a VPN
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    4
    ·
    18 days 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).



  • Laser@feddit.orgtoSelfhosted@lemmy.worldHow to selfhost with a VPN
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    17 days 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 tampered with. Especially stream ciphers like ChaCha (but also AES in counter mode) are susceptible to malleability attacks, which are super simple yet very dangerous.

    Edit: this post is a bit pedantic because any scheme that is relevant for LE certificates covers authenticity protection. But it’s not the encryption part of those schemes that is responsible.


  • Good luck on the journey! What I meant is that over time, you’ll realize that what you did was probably not the most elegant was to do something, at least that’s my experience with my config. Like, I started with a flake with an explicit config for each machine (basically multiple nixosConfigurations) and then turned it into a lib with functions to turn a set of hosts from json into an attribute set (kind of a simple inventory done). My last efforts that are still ongoing (cough) are splitting my NixOS modules off into a separate flake using flake-parts.

    I do understand you meant having the stuff that your need work, I just wanted to hint that the language is very powerful and as such, most configurations have room for improvement, as in learning to do things more efficient or do things that weren’t possible before.



  • Privileged ports can be used by processes that are running without root permissions.

    I guess you mean unprivileged ports?

    So if the sshd process would crash or stop for some other reason, any malicious user process could pretend to be the real ssh server without privilege escalation.

    Not really, except on the very first connection because you need access to the root-owned and otherwise inaccessible SSH host key, otherwise you’ll get the message a lot of people have probably seen after they reinstalled a system (something like “SOMEONE MIGHT BE DOING SOMETHING VERY NASTY!”).









  • I was also with a provider that didn’t offer API access for the longest time. When they then increased prices, I switched, now paying a third of their asking price per year at a very good provider.

    I guess migrating is difficult if the provider doesn’t offer a mechanism to either dump the DNS to a file or perform a zone transfer (the later being part of the standard).

    Can only recommend INWX for domains, though my personal requirements aren’t the highest.



  • Also wildcard certificates are more difficult to do automated with let’s encrypt.

    They are trivial with a non-garbage domain provider.

    If you want EV certificates (where the cert company actually calls you up and verifies you’re the company you claim to be) you also need to go the paid route

    The process however isn’t as secure as one might think: https://cyberscoop.com/easy-fake-extended-validation-certificates-research-shows/

    In my experience trustworthyness of certs is not an issue with LE. I sometimes check websites certs and of I see they’re LE I’m more like “Good for them”

    Basically, am LE cert says “we were able to verify that the operator of this service you’re attempting to use controls (parts of) the domain it claims to be part of”. Nothing more or less. Which in most cases is enough so that you can secure the connection. It’s possibly even a stronger guarantee than some sketchy cert providers provided in the past which was like “we were able to verify that someone sent us money”.



  • Also game servers because they’re generally very easy to host at home, and due to generally high RAM and storage needs paying for hosting can be quite pricey.

    Really?

    I thought this was more the case with flexible providers like DigitalOcean. My current provider charges 5,36€ per month for 4 cores (though I assume this corresponds rather to 2 SMT-enabled cores), 6 GB of RAM and a 400 GB SSD. It offers better latency for most players (obviously not for myself) and in most cases has been sufficient regarding performance.