4 ms·

A compromise that wouldn't hurt innocent websites would be to remove the CA's ability to issue new certificates. CAs knew that the stakes were high when they s

by jewel 12y ago

A compromise that wouldn't hurt innocent websites would be to remove the CA's ability to issue new certificates. CAs knew that the stakes were high when they signed up to be a CA, so I think it'd be fair to remove them permanently. Eventually, only the truly paranoid would be left. It may cost a bit more to run a fully secure CA, and that would be reflected in the cost of a certificate from those that remain, but that'd be a price that everyone should be willing to pay.

deleted 12y ago
[deleted]
gtaylor 12y ago
> It may cost a bit more to run a fully secure CA, and that would be reflected in the cost of a certificate from those that remain, but that'd be a price that everyone should be willing to pay. I don't know, this could really discourage the adoption of HTTPS. We need to be making it easier for sites to adopt it. Ideally we could lessen our dependence on CAs. Sure, a "fully secure/expensive" CA would validate a certificate's authenticity with high confidence, but we'd be excluding tons of hobby projects and small shops who wouldn't want that expense.
- michaelt 12y ago
  Seems to me a CA that can't avoid issuing bad certificates is a bad thing for security, no matter how cheap they are.
- marcosdumay 12y ago
  What good does widespread HTTPS use do if you can not trust it? I'm all for reducing our dependence on CAs, and, reducing the number of CAs we trust for signing a site, like putting the keys in DNSSEC. But until we do that, we must not trust bad apples.
  - AlyssaRowan 12y ago
    It's always better than plaintext HTTP. Nothing is worse than plaintext. TLSv1.2 with good ciphersuites using ECDHE with a named curve like secp256r1 [murky origins I know, but we know of nothing else wrong with it, though Curve25519 is superior in my opinion], and an AEAD like AES-128-GCM or CHACHA20-POLY1305, properly implemented with no TLS compression at least comprehensively prevents Eve from spying on the contents of your connection in most cases, even if you're using self-signed certificates with no pinning and are entirely unprotected from Mallory. A browser shouldn't call it secure or the endpoint trusted, but it should transparently replace all uses of unencrypted HTTP worldwide, including internal ones. That should not be discouraged, and will hopefully be actioned with HTTP/2 - that was the plan, anyway. Even if the encryption is crap (Export ciphers... RC4?) I guess it does take some more work for Eve, which knocks out a few of the lower-capability adversaries.
    - leni536 12y ago
      Couldn't Mallory just replace the certificate with her own one? The browser would just pop up the same warning. The warning should show some form of a public key fingerprint at least before clicking through "I understand the risk".
richardwhiuk 12y ago
I'm not sure it's possible to absolutely determine when a certificate was issued, that doesn't either introduce another third party (i.e. a timestamping service) that the CA can't trivially bypass.
- mrb 12y ago
  A distributed no-trust-required timestamping service is fundamentally what Bitcoin provides. So it would be possible to prove a certificate was issued before a certain time (eg. before a breach at a CA), if CAs were forced to immediately publish, in the Bitcoin block chain, the hash of each newly issued certificate. There would be no need to trust a single (bypassable/hackable) entity doing timestamping, since the block chain itself is distributed. (This is just one of the numerous applications that distributed block chains enable IMHO! And we are just barely scratching the surface of what we can do with such a concept...)
  - pyre 12y ago
    The problem is that distributed block-chains are not a panacea. It requires a certain inertia to increase the difficulty of attacks on the block-chain, and even then attacks are still possible if your pockets are deep enough.
  - michaelt 12y ago
    For some applications, yes. But the bitcoin blockchain is already too big to store and sync on mobile devices with costly data connections - and it would only get bigger if it had to contain every SSL certificate ever issued! You could have SSL clients connect to trusted nodes, like mobile bitcoin clients do [1], but then you've basically taken Certificate Authorities and replaced them with 'trusted nodes' so you're not much better off really. [1] https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security
    - mcherm 12y ago
      The bitcoin blockchain doesn't need to contain every SSL certificate. It just needs to contain a SINGLE transaction conducted each day where the comment field contains the hash of a document published by the root authority. That document would be published elsewhere (on the site of the owner of the root certificate) -- the bitcoin blockchain would be used only to provide proof that the document hadn't been changed since it was published.
benmmurphy 12y ago
i assume this would be done by looking at the issuing date of the cert and rejecting certs with issuing date > date CA was 'executed'. however, a CA could just issue certificates with the issuing date in the past. they probably wouldn't do this for real customers because it would be detected easily. however, they could do it for fraudulent customers and it would be a massive temptation for CAs who have no other source of revenue to do this.

by jewel 12y ago

deleted 12y ago

[deleted]

gtaylor 12y ago

> It may cost a bit more to run a fully secure CA, and that would be reflected in the cost of a certificate from those that remain, but that'd be a price that everyone should be willing to pay. I don't know, this could really discourage the adoption of HTTPS. We need to be making it easier for sites to adopt it. Ideally we could lessen our dependence on CAs. Sure, a "fully secure/expensive" CA would validate a certificate's authenticity with high confidence, but we'd be excluding tons of hobby projects and small shops who wouldn't want that expense.

michaelt 12y ago
Seems to me a CA that can't avoid issuing bad certificates is a bad thing for security, no matter how cheap they are.
marcosdumay 12y ago
What good does widespread HTTPS use do if you can not trust it? I'm all for reducing our dependence on CAs, and, reducing the number of CAs we trust for signing a site, like putting the keys in DNSSEC. But until we do that, we must not trust bad apples.
- AlyssaRowan 12y ago
  It's always better than plaintext HTTP. Nothing is worse than plaintext. TLSv1.2 with good ciphersuites using ECDHE with a named curve like secp256r1 [murky origins I know, but we know of nothing else wrong with it, though Curve25519 is superior in my opinion], and an AEAD like AES-128-GCM or CHACHA20-POLY1305, properly implemented with no TLS compression at least comprehensively prevents Eve from spying on the contents of your connection in most cases, even if you're using self-signed certificates with no pinning and are entirely unprotected from Mallory. A browser shouldn't call it secure or the endpoint trusted, but it should transparently replace all uses of unencrypted HTTP worldwide, including internal ones. That should not be discouraged, and will hopefully be actioned with HTTP/2 - that was the plan, anyway. Even if the encryption is crap (Export ciphers... RC4?) I guess it does take some more work for Eve, which knocks out a few of the lower-capability adversaries.
  - leni536 12y ago
    Couldn't Mallory just replace the certificate with her own one? The browser would just pop up the same warning. The warning should show some form of a public key fingerprint at least before clicking through "I understand the risk".

richardwhiuk 12y ago

I'm not sure it's possible to absolutely determine when a certificate was issued, that doesn't either introduce another third party (i.e. a timestamping service) that the CA can't trivially bypass.

mrb 12y ago
A distributed no-trust-required timestamping service is fundamentally what Bitcoin provides. So it would be possible to prove a certificate was issued before a certain time (eg. before a breach at a CA), if CAs were forced to immediately publish, in the Bitcoin block chain, the hash of each newly issued certificate. There would be no need to trust a single (bypassable/hackable) entity doing timestamping, since the block chain itself is distributed. (This is just one of the numerous applications that distributed block chains enable IMHO! And we are just barely scratching the surface of what we can do with such a concept...)
- pyre 12y ago
  The problem is that distributed block-chains are not a panacea. It requires a certain inertia to increase the difficulty of attacks on the block-chain, and even then attacks are still possible if your pockets are deep enough.
- michaelt 12y ago
  For some applications, yes. But the bitcoin blockchain is already too big to store and sync on mobile devices with costly data connections - and it would only get bigger if it had to contain every SSL certificate ever issued! You could have SSL clients connect to trusted nodes, like mobile bitcoin clients do [1], but then you've basically taken Certificate Authorities and replaced them with 'trusted nodes' so you're not much better off really. [1] https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security
  - mcherm 12y ago
    The bitcoin blockchain doesn't need to contain every SSL certificate. It just needs to contain a SINGLE transaction conducted each day where the comment field contains the hash of a document published by the root authority. That document would be published elsewhere (on the site of the owner of the root certificate) -- the bitcoin blockchain would be used only to provide proof that the document hadn't been changed since it was published.

benmmurphy 12y ago

i assume this would be done by looking at the issuing date of the cert and rejecting certs with issuing date > date CA was 'executed'. however, a CA could just issue certificates with the issuing date in the past. they probably wouldn't do this for real customers because it would be detected easily. however, they could do it for fraudulent customers and it would be a massive temptation for CAs who have no other source of revenue to do this.