6 ms·
The issue with that approach is that it allows man-in-the-middle attacks, because all of the characteristics you are suggesting the browser validate can be fake
by 80x25 10y ago
The issue with that approach is that it allows man-in-the-middle attacks, because all of the characteristics you are suggesting the browser validate can be faked if the root is untrusted.
- bandrami 10y agohead against desk BUT PLAINTEXT ALSO ALLOWS THAT, and in addition allows eavesdropping and alteration by another middleman.
- jcrites 10y agoI think you're considering only a single request, and not the larger context of how people interact with systems over time. Imagine that today I visit https://example.com https://example.com and I see a certificate from a CA that I trust. Everything is good: my browser shows a lock icon. Tomorrow (or a year from now), I visit again, and a malicious state actor intercepts the TCP session and returns a certificate that's self-signed or from a CA I don't trust. What should the user experience be? It definitely shouldn't be exactly the same as the trusted cert from example.com! It shouldn't be trusted at all. The behavior where the untrusted certificate shows up as "bad" protects me from MITM -- the difference between trusted and untrusted is the protection. Even though self-signed certs are in some sense better than plaintext, treating them that way will compromise the security of path-validated certs: any degree of trust creates a risk that they'll be substituted for CA-signed certs and trick a user into continuing. In a world where there are only plaintext and self-signed certs, I'd agree that self-signed are better and should be allowed. But in a world with path-validated certs, accepting and trusting self-signed certs has downsides. HSTS helps with this but isn't a complete solution. Your comment would be better without the "bangs head on desk" and caps expressing your frustration. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- sp332 10y agoThat's why I said: Just show the page, and use the plain icons (no locks or anything). It should not have any signs of "trust" and it should look like a plaintext page. I could go further and say that it should be treated as HTTP for all other purposes as well, like access to cookies and cross-site requests. If you really think sites should never be MITM-able, then you should complain just as loudly on a plaintext site as you do on an untrusted root.
- chris_wot 10y agoA 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.