3 ms·
> The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate autho
by 0xdeadbeefbabe 11y ago
> The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority?
From an attackers point of view, this sounds like a very tiny ray of hope. It sounds like a cool feature/vulnerability that will probably be going away soon because it is so easy to fix.
- riskable 11y agoThe problem with the, "was it signed by a trusted authority?" concept is that you generally can't automated the 3rd party since they're not under your control. Also, they typically charge every time you request a new certificate (even if client-only). The solution to that is to run your own CA but then it won't be 3rd party anymore. It's sort of the catch-22 with SSL/TLS: Either you use a 3rd party or you get to automate things. There doesn't appear to be any middle ground. Why is there no middle ground? Because if the 3rd party CA is doing their job they're investigating every single request for a new certificate. That means you can't just get a new client-side certificate on demand, instantaneously whenever the need arises.
- 0xdeadbeefbabe 11y ago"client developer not properly verifying the server certificate" makes it sound possible, but I think I understand the problem now maybe. The 3rd party CA may have issued a cert to malicious party that issued another cert to their man in the middle. You can't be sure unless you are your own CA, but then you aren't a 3rd party anymore.
- aianus 11y ago> Either you use a 3rd party or you get to automate things. There doesn't appear to be any middle ground. Have you seen Let's Encrypt? https://letsencrypt.org/ https://letsencrypt.org/