• 0 Posts
  • 129 Comments
Joined 9 months ago
cake
Cake day: April 13th, 2024

help-circle

  • I mean, if someone tries to “man in the middle”, or maskerade as my website, the trusted stuff will not add any security.

    As long as they can obtain a certificate signed by a trusted signer for your name, you are correct. And you are touching on a real issue here. The number of trusted signers in the browser stores is large, and if only one can be tricked or compromised, then the MitM can generate a certificate your browser would trust just as well as your own original one.

    If someone hacks my site […]

    then it’s over anyway, yes. The signature on the certificate only validates your TLS key as being one that was properly assigned to the holder of your domain name. Once the endpoint is compromised, TLS doesn’t matter anymore.

    if the browsers weren’t locked down

    Actually maybe they aren’t as locked down as you think. To my knowledge you can add your own signing key certificates to your local installation of Firefox, Chrome and the Windows cert storage. In fact there are companies who do this a lot. They Man-in-the-Middle all their employees, with a proxy that does security scanning. For this reason they will deploy their signing keys internally. So the browsers still work. You can use these mechanisms for yourself if you like.

    Example documentation: https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox


  • A certificate fundamentally only does the following, it binds a name and a public key together and attaches a signature to that binding.

    Anyone can make a certificate binding any key to any name and put their own signature on it, they just can’t fake others people’s signatures. This is also what you do if you self sign a certificate. If you then install the public key of your signing key in your webbrowser you can connect to your own services using your TLS key and your browser will check that the server presents the certificate with a matchign signature proving that it is using the right TLS key.

    You can also bind your TLS key to www.wikipedia.org and sign it. However nobody else knows your signing key, and thus nobody would trust the certificate you signed. Which is a good thing, because otherwise it would be easy for you to impersonate Wikipedia’s website.

    The value of trusted certificates lies in the established trust between the signers (CAs) and the software developers who make browsers etc. The signers will only sign certificates to bind names and TLS keys for the people who actually own the name, and not for third parties.

    The validation of ownership is the thing that varies a lot. The simple way is just checking for control of the web server currently reachable under a name, or checking for control of the DNS entries for a name, but the more complicated validations check business records etc.

    So when you’re asking do they protect better, it’s kind of difficult to say.

    • If you can validate the signature yourself, say you have control of the browser and the server, then your own signature is fine, and a trusted one wouldn’t be any better.
    • But if you want third parties, that don’t know you, to be able to verify that their TLS session is established to a person who actually owns the domain, rather than a man in the middle, then the only practical solution today is using that established trust system.
    • If you are asking about the encryption strength of the TLS session itself, then that’s completely independent of the certificate issue, because again the certificate only binds a name to a key with a signature. You can bind an old short key, whose private key has been leaked before to a name, or you can bind a modern long key that is freshly generated to the same name. You can used either key in a good or a bad cryptographic setup. You can use deprecated SSL 3.0 or modern TLS 1.3. Those choices don’t depend on who signs the certificate.

    I hope that helps, sorry for writing so much





  • Packet loss occurs when a router has to drop some packets because the buffer to store them is running out because the link where they are supposed to go is overloaded.

    Bufferbloat is the issue where you make your queues too deep, i.e. you allocate too much RAM to buffering, while the cause of the buffering still exists, so the deeper queue just fills up anyway, so you haven’t improved anything, and have induced extra latency on the packets that do make it trough.

    Deep buffers can help in situations where you have a step down in link speed, but only bursty and not sustained overloading of the slower output link.

    The big bottleneck in router hardware is more about TCAM or HBM memory used to store the FIB of the global routing table. Since the table has grown so much the devices with less high speed memory can’t hold the table anymore, and if they start swapping the FIB to normal memory your routing performance goes to shit.

    So not all of your concerns seem to apply to this class of device, but of course you’re right, The Register should have mentioned the RAM.




  • Depends on which instance you use for your client, I would say. For me only discuss.tchncs.de gets to see my IP address, and Milan Ihl, our admin, as well as his Lemmy server, are in Germany.

    This means two things:

    • You can shop for a location of home instance that you deem Nintendo-safe
    • Nintendo would have to multiply its legal efforts many times over and through different jurisdictions if they wanted to get all users of a community, which might affect their effort-value-considerations.

    But I’ve probably doxxed myself with personal stories. Pretty sure a dedicated person could find my employer, the team I’m in, and my age.










  • On a general note I would say for the individual consumer it doesn’t matter so much if they keep releasing yearly, we just don’t have to buy yearly.

    It’s kind of a waste of resources for the manufacturers supporting more models than necessary. If that leads to shorter support schedules that’s when it impacts us. But as you observed they seem to be lengthening at the moment.

    I’m currently on a Pixel 6 from 2021, that I bought used from someone who was chasing the latest and greatest. I have no reason for changing yet. After October 2026 when support ends I’ll see if I have to migrate to Graphene OS or something. If no secure path forward exists I may have to get newer hardware then.