5 ms·

No. Self-signed certificates are much worse because they bring a false sense of security. A self-signed certificate is trivially MITMed unless you have a way t

by kaoD 12y ago

No. Self-signed certificates are much worse because they bring a false sense of security. A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766 https://news.ycombinator.com/item?id=8616766). EDIT: You can downvote all you want but I'm still right. Each time anyone repeats the "self-signed certificates are still better than HTTP plain text" lie is hurting everyone in the long run. They're much worse, both for the users and from a security perspective. Self-signed certificates are evil unless you know exactly what you're doing and are in full control of both ends of the communication (in which case just trust it yourself and ignore the warnings).

schoen 12y ago
The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats. An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt: http://www.tcpcrypt.org/ http://www.tcpcrypt.org/ So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.
- kaoD 12y ago
  > With some browser behavior self-signed certs could make some users safer against some threats How exactly? Did you read my linked comment? As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart. The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself. In the age of WiFi, you can't dismiss active attacks. EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views. Even parent's Tcpcrypt link says it is vulnerable. > By default Tcpcrypt is vulnerable to active attacks > Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. How are you going to perform authentication via insecure channels without CAs?
  - schoen 12y ago
    Well, the best example I know of is proposals to do opportunistic upgrades from HTTP to HTTPS, for example via a browser header in the HTTP reply. If the browser performs the opportunistic upgrade, and negotiates an HTTPS connection behind the scenes, and doesn't tell the user that the connection was served over HTTPS, then accepting a self-signed cert invisibly in this context makes the user no worse off than not performing the upgrade (and better off against an adversary who's not currently performing an active attack). I forgot what the current status of drafts proposing this is. Amazingly, I found that Rohit Khare described a form of this mechanism way back in 1998 (so it's not a super-new concept).
    - kaoD 12y ago
      Although such scheme is indeed safer than HTTP (protects against passive attacks), what you're describing is not self-signed certificates, but merely encryption (with new random _unathenticated_ keys per session). Keys would be exchanged via Diffie-Hellman as usual, but a certificate wouldn't be involved since it's useless anyways (you can't certify anything in such a scheme, why bother at all?) and thus would be vulnerable to active attacks. Certificates imply long-term authentication. It's an important nuance since they are long-lived by definition, so they have to be trusted and revoked as needed, in which case we're still facing the problem I mentioned earlier.
      - schoen 12y ago
        I agree that the certificates don't serve any useful function in this scenario; they might be required pro forma, but they aren't actually doing anything helpful.
lmm 12y ago
> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. Trivial? Yes. As trivial as intercepting plain HTTP? No. The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect), it's about increasing the cost to attackers.
- kaoD 12y ago
  https://news.ycombinator.com/item?id=8625420 https://news.ycombinator.com/item?id=8625420
  - lmm 12y ago
    HTTPS with self-signed certificates remains better than plain HTTP. The fact that you can propose an unimplemented, unstandardized, theoretical scheme that would offer the same advantages as HTTPS with self-signed certificates does not make HTTPS with self-signed certificates worse than plain HTTP.

by kaoD 12y ago

schoen 12y ago

The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats. An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt: http://www.tcpcrypt.org/ http://www.tcpcrypt.org/ So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.

kaoD 12y ago
> With some browser behavior self-signed certs could make some users safer against some threats How exactly? Did you read my linked comment? As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart. The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself. In the age of WiFi, you can't dismiss active attacks. EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views. Even parent's Tcpcrypt link says it is vulnerable. > By default Tcpcrypt is vulnerable to active attacks > Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. How are you going to perform authentication via insecure channels without CAs?
- schoen 12y ago
  Well, the best example I know of is proposals to do opportunistic upgrades from HTTP to HTTPS, for example via a browser header in the HTTP reply. If the browser performs the opportunistic upgrade, and negotiates an HTTPS connection behind the scenes, and doesn't tell the user that the connection was served over HTTPS, then accepting a self-signed cert invisibly in this context makes the user no worse off than not performing the upgrade (and better off against an adversary who's not currently performing an active attack). I forgot what the current status of drafts proposing this is. Amazingly, I found that Rohit Khare described a form of this mechanism way back in 1998 (so it's not a super-new concept).
  - kaoD 12y ago
    Although such scheme is indeed safer than HTTP (protects against passive attacks), what you're describing is not self-signed certificates, but merely encryption (with new random _unathenticated_ keys per session). Keys would be exchanged via Diffie-Hellman as usual, but a certificate wouldn't be involved since it's useless anyways (you can't certify anything in such a scheme, why bother at all?) and thus would be vulnerable to active attacks. Certificates imply long-term authentication. It's an important nuance since they are long-lived by definition, so they have to be trusted and revoked as needed, in which case we're still facing the problem I mentioned earlier.
    - schoen 12y ago
      I agree that the certificates don't serve any useful function in this scenario; they might be required pro forma, but they aren't actually doing anything helpful.

lmm 12y ago

> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. Trivial? Yes. As trivial as intercepting plain HTTP? No. The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect), it's about increasing the cost to attackers.

kaoD 12y ago
https://news.ycombinator.com/item?id=8625420 https://news.ycombinator.com/item?id=8625420
- lmm 12y ago
  HTTPS with self-signed certificates remains better than plain HTTP. The fact that you can propose an unimplemented, unstandardized, theoretical scheme that would offer the same advantages as HTTPS with self-signed certificates does not make HTTPS with self-signed certificates worse than plain HTTP.