4 ms·

It isn't HTTPS that's the issue so much as centralisation under CAs. Self signed certificates should not throw up a warning on sites that don't deal with sensit

It isn't HTTPS that's the issue so much as centralisation under CAs. Self signed certificates should not throw up a warning on sites that don't deal with sensitive data.

dimal123 3y ago
[flagged]
josephcsible 3y ago
> Self signed certificates should not throw up a warning on sites that don't deal with sensitive data. I would have went with a slightly different suggestion: Self signed certificates should not throw up any warnings that wouldn't appear for the same site visited over insecure HTTP, since the latter is strictly more dangerous.
- ComputerGuru 3y ago
  Absolutely. Submitted: https://news.ycombinator.com/item?id=36589269 https://news.ycombinator.com/item?id=36589269
- woodruffw 3y ago
  > Self signed certificates should not throw up any warnings that wouldn't appear for the same site visited over insecure HTTP, since the latter is strictly more dangerous. For an unknown server, they're strictly equivalent: trusting a self-signed certificate is the canonical "private chat with the devil" example. You could argue that it prevents some other unknown adversary from reading your traffic on the line, but that's a weird threat model (why would an adversary even bother, when you'll accept any certificate they give you?). More fundamentally: a policy among browsers to trust self-signed certs if the only other option is HTTP is way easier for an adversary to MiTM: instead of attacking TLS itself, they can redirect your entire connection to an inauthentic server with a self-signed certificate. Not throwing up any warnings for that case would mean that browsers would automatically trust the inauthentic server.
  - josephcsible 3y ago
    > a policy among browsers to trust self-signed certs if the only other option is HTTP I'm not arguing to remove warnings when going to a site with a self-signed cert. I'm arguing to add warnings to insecure HTTP until it's at least as scary as going to a site with a self-signed cert is today.
jeroenhd 3y ago
DANE shortly offered an alternative, but then it turns out very few DNS hosts are competent enough to enable DNSSEC so that died an early grave. Self signed certificates are completely pointless and they should never be trusted without manual confirmation. You have no way to verify who's generating these self signed certificates, you may as well use HTTP if you're going to accept self signed stuff.
- deleted 3y ago
  [deleted]
- josephcsible 3y ago
  Self-signed certificates aren't quite as bad as insecure HTTP, since you at least have the ability to manually verify them out-of-band, and even if you don't do that, you're still at least safe from passive taps.
- tptacek 3y ago
  There are a bunch of different reasons DANE was unworkable, not just that DNSSEC is an untenable operations problem.

It isn't HTTPS that's the issue so much as centralisation under CAs. Self signed certificates should not throw up a warning on sites that don't deal with sensitive data.

dimal123 3y ago

[flagged]

josephcsible 3y ago

> Self signed certificates should not throw up a warning on sites that don't deal with sensitive data. I would have went with a slightly different suggestion: Self signed certificates should not throw up any warnings that wouldn't appear for the same site visited over insecure HTTP, since the latter is strictly more dangerous.

ComputerGuru 3y ago
Absolutely. Submitted: https://news.ycombinator.com/item?id=36589269 https://news.ycombinator.com/item?id=36589269
woodruffw 3y ago
> Self signed certificates should not throw up any warnings that wouldn't appear for the same site visited over insecure HTTP, since the latter is strictly more dangerous. For an unknown server, they're strictly equivalent: trusting a self-signed certificate is the canonical "private chat with the devil" example. You could argue that it prevents some other unknown adversary from reading your traffic on the line, but that's a weird threat model (why would an adversary even bother, when you'll accept any certificate they give you?). More fundamentally: a policy among browsers to trust self-signed certs if the only other option is HTTP is way easier for an adversary to MiTM: instead of attacking TLS itself, they can redirect your entire connection to an inauthentic server with a self-signed certificate. Not throwing up any warnings for that case would mean that browsers would automatically trust the inauthentic server.
- josephcsible 3y ago
  > a policy among browsers to trust self-signed certs if the only other option is HTTP I'm not arguing to remove warnings when going to a site with a self-signed cert. I'm arguing to add warnings to insecure HTTP until it's at least as scary as going to a site with a self-signed cert is today.

jeroenhd 3y ago

DANE shortly offered an alternative, but then it turns out very few DNS hosts are competent enough to enable DNSSEC so that died an early grave. Self signed certificates are completely pointless and they should never be trusted without manual confirmation. You have no way to verify who's generating these self signed certificates, you may as well use HTTP if you're going to accept self signed stuff.

deleted 3y ago
[deleted]
josephcsible 3y ago
Self-signed certificates aren't quite as bad as insecure HTTP, since you at least have the ability to manually verify them out-of-band, and even if you don't do that, you're still at least safe from passive taps.
tptacek 3y ago
There are a bunch of different reasons DANE was unworkable, not just that DNSSEC is an untenable operations problem.