Let's Encrypt's Root Certificate is About To Expire, and It Might Break Your Dev...

›

• Re:

  No, the problem is not encrypting everything. That's actually a good idea. The problem is encrypting with a certificate that "expires". That's just fucking retarded.

  • Re:

    At least for expiration the theory that an abandoned or unknown compromise is at least eventually stop being a potential problem.

    Now the 'not valid until' bullshit...

  • Re:

    The problem is the highly centralized certificate "authority". Very convenient kill switch, don't you think? Pretty sure this is the intent behind the whole thing.

    • Re:

      No one is forcing people to use a "centralized" authority. Setting up your own Certificate Signing Authority is surprisingly easy using something like OpenSSL [openssl.org]. The widely-recognized CSAs are more convenient to use, however, since their certificates are already trusted by software like Chome, Firefox, Edge, etc.

    • Re:

      Aren't CA's are just a work-around to the identity verification problem? Encryption and secure key exchange seem to be solved, at least for our level of technology. 'Web of trust" as an alternative seems impractical. But what I wonder if we need them?

      Now, I'm not a cryptography expert by any means, so keep that in mind. Why isn't just Diffie–Hellman and AES good enough for most normal use, and why things requiring more security can't just use some out-of-band key. I'm imagining something like a Q

      • by bws111 ( 1216812 ) on Wednesday September 22, 2021 @06:46PM (#61822405)

        Certificates do not provide encryption. What they do is provide a method of saying that the server you just connected to has a private key which someone you supposedly trust (the CA) says belongs to that server. If you don't verify that connection, it doesn't matter how strong encryption you use, because whatever you connected to can decrypt the traffic.

        Yes, you could use something like a QR code to enter that information into your device. But how do you know the QR code itself is authentic? Even if you do use something like a QR code, that would probably at most be providing the 'root' certificate of your bank's own CA. Your bank isn't going to be giving you QR codes for every one of the dozens or hundreds of servers you might connect to when you go to 'yourbank.com'. All you've done is replaced a few trusted CAs with potentially very many CAs, depending on how many sites you connect to. And, to top it off, you get to manage all that instead of your browser provider.

        Somewhere along the line you have to trust something. Sure, you may trust a QR code you get from your bank, but what about all the other places you want to securely connect to? How do you manage all that stuff (on every device you have)? How do you make sure you (and everyone else) delete something that is no longer valid (maybe your banks private key was compromised somehow)?

        CAs are a tradeoff. No, they don't provide perfect verification. But they are easy to use, and the average person doesn't have to do anything to benefit from the verification they provide.

        • Re:

          Okay, it's clear that you didn't understand my question. I'm not sure you even read it. I'm almost insulted by your reply, as I can't see how you could have composed what you did in response to what I've written.

          I never said they did. I was very clear about the role that certificates play. It's the very first thing I wrote.

          Because I got it from my bank? As you said: "Somewhere along the line you have to trust something". This seems a lot more trustworthy than anything done online. I'll also note that

          • Re:

            MITM attacks are certainly not difficult to do. Did you ever use a hotel (or other public) wifi, and the first page you try to go to comes up with a big 'connection not secure'? That is because they are returning their own T&C web page instead of the site you wanted to go to, and the certificate does not match the expected server. Instead of returning their own page, they could just capture everything in your request, then forward the request to the real site. The certificates prevent this.

            As for you

  • Re:

    Expiring roots is just a necessary ill. If you explicitly trust every organization of whom you deal directly, you don't need to trust any roots, but the downside to that is manual configuration and all entities need to understand how certificates work.

    Failing that, the root CA needs to remain secure against a large attack surface for the entire duration. Even strong crypto methods and secure personnel at those entities can only ensure this for a limited time window, after which the best assumption is to c

    • Re:

      I imagine one of way of explaining it is blind trust vs renewed trust. Today you trust your politician, but who knows if they have been compromised tomorrow, so you need to update your trust relationship instead of just accepting blindly. At the same time there is a notion that the common authority your browser trusts is also legit, so there is a weakness, but I am not sure trust is ever 100% even in human relationships.

      The above scenario has happened when a number of CAs went bad.

• Re:

  The problem here is crappy devices made by crappy vendors with no right to repair, and no continued update support for their junk. Encrypt everything is good, and expiring certificates is a necessity.

• Re:

  No. This is yet another downside to using an insecure, unencrypted protocol, HTTP, for everything.

• Re:

  You got a moderation of "funny", but this is actually a very real problem. Encryption increases system complexity and increases maintenance needs. In many cases, it may be better to _not_ encrypt.