6 ms·
A site with an untrusted root tends to indicate to me that a bad actor is actively engaged in intercepting my data. If I go to gmail I'd like to get a warning
by chris_wot 10y ago
A site with an untrusted root tends to indicate to me that a bad actor is actively engaged in intercepting my data.
If I go to gmail I'd like to get a warning instead of accidentally not noticing there is no lock indicator in my browser.
- mynameisvlad 10y agoI think this is the first time in this thread someone actually sat down and explained why it's worse instead of just waving it off. In fact, until now, I was even on the self cert side of the debate because the arguments seemed more thought out, but this comment alone essentially changed my viewpoint on this issue.
- sp332 10y agoJust for my own sanity, could I get you to confirm that you'd like the browser to freak out equally on a plaintext site as one with an untrusted root? (Even without HSTS, which would make some noise for gmail in particular.)
- chris_wot 10y agoWhy would I want that?
- sp332 10y agoOK could you explain in very small words why a self-signed certificate is more likely to indicate a MITM attack than a plaintext site is?
- pfg 10y agoA self-signed certificate for a site that I expect to be delivered via HTTPS (either because I typed "https://" https://", or clicked a link that starts with "https://" https://", or because I opened a bookmark that I know to be secure) is definitely more likely to indicate a MitM attack, yes. If you're arguing for opportunistic encryption for "http://" http://" links, I'm fine with that, but if I'm expecting HTTPS, I want either a trusted certificate or a big, red warning that's hard (or impossible) to bypass. I'm also not convinced that opportunistic encryption is worth the effort nowadays, given that the price of a certificate is zero in all but the most obscure of use-cases.
- ubernostrum 10y agoI think the argument here is that, say, somebody's random blog or forum for their local group or whatever doesn't really need to worry about well-equipped state actors or the mafia or whoever MITM-ing them (and wouldn't be able to defend that anyway if they really became a target). They do care about someone casually sniffing the password to the blog's admin interface when they post from a coffeeshop, though. But for years -- it's only recently that viable zero-dollar browser-trusted certs became a possibility -- we told those people "screw you, you're so dangerous for wanting that, we have to produce the loudest, nastiest, most terror-inducing popup warnings we can come up with just to slap on your disgustingly evil site and shame you into paying hundreds of dollars to a corrupt cartel". Which confuses the poor schmuck who just wants that little bit of security against that particular, but far more common than MITM, threat model. De-conflating the two concerns -- inability to eavesdrop, and inability to impersonate -- might not be such a bad idea for those people.
- pfg 10y agoRight, but doing this for HTTPS URLs would change the semantics of those URLs. People expect HTTPS to mean you either have a trusted CA certificate or you see a big, red warning. Changing these semantics would be terrible for security. You can argue for opportunistic encryption in HTTP, but I'd argue that it's cheaper and easier for most affected parties if browser vendors just help push the price of publicly-trusted certificates to zero, which is exactly what Mozilla and Chrome (among others) did. Rolling out a new protocol would've taken years as well, so I don't think we've lost much time choosing this approach.
- ubernostrum 10y agoPeople expect HTTPS to mean you either have a trusted CA certificate or you see a big, red warning. Changing these semantics would be terrible for security. No. You and some other folks on HN expect that. The general public does not know or care that HTTPS conflates multiple issues. Some random person who just wants to have a secure way to hit the login page of their blog does not know or care. There's room for a spectrum of things and ways to indicate where on that spectrum a particular site is, but HTTPS has been forced to be the one-size-fits-every-entity-in-the-universe solution and so has bundled in things that just aren't relevant to a lot of use cases and made it a binary "either you implement 100% of this 100% of the time or else" proposition when that makes no sense to do.
- chris_wot 10y agoGmail doesn't use a self-signed certificate. Small enough for you?
- byuu 10y agoWhat if it just showed all HTTP and self-signed HTTPS site address bars with a light red background, instead? It would immediately jump out at you on Gmail that something was wrong. Chrome wants to eventually indicate all HTTP sites are insecure, so this is a good way to achieve their goal, is it not? It doesn't matter whether you believe their actions are altruistic (protect everyone!) or sinister (protect the CAs!) ... by treating self-signed certificates as worse than nothing, they send a pretty clear signal to independents that it's the latter. Treating them both the same would be a great step toward building confidence to those who don't trust their actions currently.
- a3_nm 10y agoWhat about displaying a warning for domains where a successful HTTPS session with a trusted certificate took place before? Or about displaying a warning for websites using HSTS -- which Gmail does.