3 ms·

Ah yes, HTTPS, the critical security infrastructure with 168 single points of failure [1], each of which would mean a total, catastrophic system compromise...

by p-e-w 4y ago

Ah yes, HTTPS, the critical security infrastructure with 168 single points of failure [1], each of which would mean a total, catastrophic system compromise... [1] https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport https://ccadb-public.secure.force.com/mozilla/IncludedCACert...

Gigachad 4y ago
It’s not quite that bad. Certificate transparency and things like the EFF observatory extension effectively solve this issue. An org issuing a malicious certificate would very quickly be detected and their keys revoked.
- p-e-w 4y ago
  And in the time it takes to revoke those keys and roll out the revocation to browsers, half the planet can have their email credentials stolen, which means the horse has bolted long before the stable doors even begin to close.
  - Gigachad 4y ago
    Being able to sign a fake certificate doesn’t immediately let you intercept traffic. You also have to control the worlds ISPs to get your server in the middle. Such an incredible feat that it has never happened before.
- brohee 4y ago
  Only if they use it irresponsibly. A certificate tightly controlled by a three letter agency and used for spot interceptions on specific targets is very unlikely to be found. Massive interception are likely to be detected nowadays, but the lone political opponent is still far from safe from them.
  - Gigachad 4y ago
    It should be possible for browsers to flat out reject any certificate that isn’t in the transparency logs. Not too sure if they do that currently but I can’t see why they couldn’t.
    - brohee 4y ago
      For the same reason they don't use the CRL, it very hard and expensive to scale, and in any case what to do if you cannot access the CRL/transparency log? An entity in position to intercept can simulate an outage as well..
      - nickf 4y ago
        That's not quite how CT works. The client doesn't (currently) need to have any access to the CT logs themselves. Generally, a 'pre' certificate is submitted to a number of logs by the CA. The log returns a signed timestamp. These SCTs (signed certificate timestamps) are embedded in the final certificate provided to the subscriber - and the browser can verify those. (The SCTs can also be stapled, and not signed into the certificate itself).
        brohee 4y ago
        Without access to the CT log, the browser can only check the SCT signature, which offers about the same security level as the certificate itself.
        nickf 4y ago
        Again, that's really not how it works.
deleted 4y ago
[deleted]

by p-e-w 4y ago

Gigachad 4y ago

It’s not quite that bad. Certificate transparency and things like the EFF observatory extension effectively solve this issue. An org issuing a malicious certificate would very quickly be detected and their keys revoked.

p-e-w 4y ago
And in the time it takes to revoke those keys and roll out the revocation to browsers, half the planet can have their email credentials stolen, which means the horse has bolted long before the stable doors even begin to close.
- Gigachad 4y ago
  Being able to sign a fake certificate doesn’t immediately let you intercept traffic. You also have to control the worlds ISPs to get your server in the middle. Such an incredible feat that it has never happened before.
brohee 4y ago
Only if they use it irresponsibly. A certificate tightly controlled by a three letter agency and used for spot interceptions on specific targets is very unlikely to be found. Massive interception are likely to be detected nowadays, but the lone political opponent is still far from safe from them.
- Gigachad 4y ago
  It should be possible for browsers to flat out reject any certificate that isn’t in the transparency logs. Not too sure if they do that currently but I can’t see why they couldn’t.
  - brohee 4y ago
    For the same reason they don't use the CRL, it very hard and expensive to scale, and in any case what to do if you cannot access the CRL/transparency log? An entity in position to intercept can simulate an outage as well..
    - nickf 4y ago
      That's not quite how CT works. The client doesn't (currently) need to have any access to the CT logs themselves. Generally, a 'pre' certificate is submitted to a number of logs by the CA. The log returns a signed timestamp. These SCTs (signed certificate timestamps) are embedded in the final certificate provided to the subscriber - and the browser can verify those. (The SCTs can also be stapled, and not signed into the certificate itself).
      - brohee 4y ago
        Without access to the CT log, the browser can only check the SCT signature, which offers about the same security level as the certificate itself.
        nickf 4y ago
        Again, that's really not how it works.

deleted 4y ago

[deleted]