4 ms·

For this to work we need free certificates. Many still keep referring to StartSSL, but there you just pay double later on in revocation fees. https://www.starts

For this to work we need free certificates. Many still keep referring to StartSSL, but there you just pay double later on in revocation fees. https://www.startssl.com/?app=43 https://www.startssl.com/?app=43

duaneb 12y ago
No, I don't think we need free certificates, I think we need people who can carefully evaluate an untrusted certificate and make their own decision. The whole idea of a CA is pretty broken at current scale. Meanwhile, self-signed certificates are seen as a red flag. Should they be?
- johnny22 12y ago
  that sounds less possible than free certificates.
- nitrogen 12y ago
  Opportunistic encryption of all sessions doesn't require any certificates. All that's needed is a key exchange algorithm and browser support. The UI would make it clear when a certificate was presented and validated, but no cert is needed for unauthenticated encrypted connections. The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity verification on the level of https.
  - kaoD 12y ago
    > but no cert is needed for unauthenticated encrypted connections That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one. That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.
    - nitrogen 12y ago
      Read my final paragraph. You don't have to care about MITM to benefit from opportunistic encryption.
      - kaoD 12y ago
        > You don't have to care about MITM to benefit from opportunistic encryption. How? An encrypted connection subject to MITM is as secure as an non-encrypted one. Attackers will stop listening for plaintext credentials at WiFi spots and will just launch their favorite HTTPS MITM tool instead. Certificate pinning is flawed because you cannot revoke certificates from your clients. How would you distinguish a MITM attack from a certificate change? And if you can't revoke certificates, what happens after an attacker gains access to the private keys? Definitely flawed model. HTTPS without identity verification is even worse than HTTP. IMHO a false sense of security is more dangerous than no security. Self-signed certificates must not be advertised as secure by browsers (the famous lock icon) because they are not! This would render them invisible for most users. Self-signed certificates are only viable for tech-savvy users, and even then the dangers are too many and the burden too heavy (did the server change certs, or am I being subject to a MITM attack?) for them to be useful.
        nitrogen 12y ago
        MITM isn't the only threat to Internet users. I can see three levels of security, each of which provides more security for users but less convenience for server operators: 1. Opportunistic encryption without certificates or identity pinning -- protects against dragnet surveillance and packet sniffing, but not MITM. 2. Encryption with pinned self-signed certs -- protects against second connection MITM, but not stolen certs without some revocation design. 3. Encryption and identity verification with CA- or WoT-signed certs -- protects against first connection MITM except by powerful adversaries.
    - rurounijones 12y ago
      Which is why the pinning bit comes in. If I connect to server X at home, get their self-signed cert and then connect later at starbucks on a MITM'd connection, I will know something is wrong. Best solution? Not by a long shot, but it is a reasonably simple one to implement and does improve things.
- phaer 12y ago
  How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates? Wouldn't i need some kind of detached information like the certificates hash signed by an already known gpg key? The CA idea is broken but not too easy to replace. http://convergence.io/ http://convergence.io/ could be a few steps forward.
  - 7952 12y ago
    You could have a URL format that includes the signature of the key. Big sites would transparently add the signature and the browser would give a warning if the signature is different. You could add the same signature information to cookies and warn the user if it changes.
    - xorcist 12y ago
      There is a big tradeoff here: The ability to enter URLs manually. This is what we tell users to do today for important sites, and not click in links in mail or elsewhere. It is not obvious that there is a net benefit in security.
  - duaneb 12y ago
    > How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates? Well, you decide whether you want to trust the person on the certificate, and if the security ever changes again that'd be the red flag. Initial trust is always difficult.
AlyssaRowan 12y ago
No: DANE TLSA. https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698 What, your domain doesn't have DNSSEC because your registrar doesn't offer it? It'll have to have the opportunity to next year, if they want to renew their contract with ICANN...
mappu 12y ago
Everyone says that, but revocation doesn't even work anyway. - Any time a certificate could be impersonated by an attacker, the attacker is also able to block a revocation check. - Live revocation checks (A) kill performance, and (B) leak information as a side-channel. - You could solve this by predownloading every single revocation ever. But that is massive (infeasible for mobile), never going to be up to date, and leaks information about private domains. See Adam Langley's blog for more about OCSP vs CRLsets.

duaneb 12y ago

No, I don't think we need free certificates, I think we need people who can carefully evaluate an untrusted certificate and make their own decision. The whole idea of a CA is pretty broken at current scale. Meanwhile, self-signed certificates are seen as a red flag. Should they be?

johnny22 12y ago
that sounds less possible than free certificates.
nitrogen 12y ago
Opportunistic encryption of all sessions doesn't require any certificates. All that's needed is a key exchange algorithm and browser support. The UI would make it clear when a certificate was presented and validated, but no cert is needed for unauthenticated encrypted connections. The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity verification on the level of https.
- kaoD 12y ago
  > but no cert is needed for unauthenticated encrypted connections That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one. That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.
  - nitrogen 12y ago
    Read my final paragraph. You don't have to care about MITM to benefit from opportunistic encryption.
    - kaoD 12y ago
      > You don't have to care about MITM to benefit from opportunistic encryption. How? An encrypted connection subject to MITM is as secure as an non-encrypted one. Attackers will stop listening for plaintext credentials at WiFi spots and will just launch their favorite HTTPS MITM tool instead. Certificate pinning is flawed because you cannot revoke certificates from your clients. How would you distinguish a MITM attack from a certificate change? And if you can't revoke certificates, what happens after an attacker gains access to the private keys? Definitely flawed model. HTTPS without identity verification is even worse than HTTP. IMHO a false sense of security is more dangerous than no security. Self-signed certificates must not be advertised as secure by browsers (the famous lock icon) because they are not! This would render them invisible for most users. Self-signed certificates are only viable for tech-savvy users, and even then the dangers are too many and the burden too heavy (did the server change certs, or am I being subject to a MITM attack?) for them to be useful.
      - nitrogen 12y ago
        MITM isn't the only threat to Internet users. I can see three levels of security, each of which provides more security for users but less convenience for server operators: 1. Opportunistic encryption without certificates or identity pinning -- protects against dragnet surveillance and packet sniffing, but not MITM. 2. Encryption with pinned self-signed certs -- protects against second connection MITM, but not stolen certs without some revocation design. 3. Encryption and identity verification with CA- or WoT-signed certs -- protects against first connection MITM except by powerful adversaries.
  - rurounijones 12y ago
    Which is why the pinning bit comes in. If I connect to server X at home, get their self-signed cert and then connect later at starbucks on a MITM'd connection, I will know something is wrong. Best solution? Not by a long shot, but it is a reasonably simple one to implement and does improve things.
phaer 12y ago
How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates? Wouldn't i need some kind of detached information like the certificates hash signed by an already known gpg key? The CA idea is broken but not too easy to replace. http://convergence.io/ http://convergence.io/ could be a few steps forward.
- 7952 12y ago
  You could have a URL format that includes the signature of the key. Big sites would transparently add the signature and the browser would give a warning if the signature is different. You could add the same signature information to cookies and warn the user if it changes.
  - xorcist 12y ago
    There is a big tradeoff here: The ability to enter URLs manually. This is what we tell users to do today for important sites, and not click in links in mail or elsewhere. It is not obvious that there is a net benefit in security.
- duaneb 12y ago
  > How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates? Well, you decide whether you want to trust the person on the certificate, and if the security ever changes again that'd be the red flag. Initial trust is always difficult.

AlyssaRowan 12y ago

No: DANE TLSA. https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698 What, your domain doesn't have DNSSEC because your registrar doesn't offer it? It'll have to have the opportunity to next year, if they want to renew their contract with ICANN...

mappu 12y ago

Everyone says that, but revocation doesn't even work anyway. - Any time a certificate could be impersonated by an attacker, the attacker is also able to block a revocation check. - Live revocation checks (A) kill performance, and (B) leak information as a side-channel. - You could solve this by predownloading every single revocation ever. But that is massive (infeasible for mobile), never going to be up to date, and leaks information about private domains. See Adam Langley's blog for more about OCSP vs CRLsets.