[unqueued]

Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate?

You use self signed certificates all the time with SSH. If you haven't seen an SSH key before, you don't fall back to telnet.

If you stop to think about it, is incredible how much effort they put into forcing you to use the latest browser, and not trust self signed certificates. It is far easier to root your device and patch your kernel than it is to use an older browser.

Yes, it is a highly effective but clumsy heuristic to detect abuse. But I am convinced that they may have other incentives as well.

[necovek]

It's been a while since I used self-signed certificates, but experience used to be just about right. You hit the page and browsers throw a big fat warning. You add an exception, basically acknowledging that this is a certificate you trust (exception is for the cert, not any cert on this domain ever), and as long as the certificate doesn't change, your trust is at the same level it was on the initial load of the page.

The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

Which is why LetsEncrypt came to be: it provides at least some chain of trust without any extended validation, which is a bit extra on top of self-signed certs.

[unqueued]

> The UX problem with self-signed certs is that you start expecting to accept them, so when that site asks you again to accept it while you are browsing in a cafe on a public WiFi, your browser would need to know that now you are on untrusted network and that you should better watch out.

But again, should you watch out more than if you were using HTTP? Does your browser make you opt in to connecting to every HTTP site on an open wifi network? What about an HTTP captive portal on an open network?

I have not heard a good argument for the current behavior with self signed certificates that justifies the behavior of completely unencrypted connections.

The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website. Perhaps leave the scary warnings for submitting something over an self signed or unencrypted connection.

[necovek]

It's again a user expectation problem. What if you connect to a web site for the first time while on a rogue public network?

If users expect to be "safe" when on a secure site, without them understanding intricacies of certificates, self-signed is counter productive.

There are certainly improvements to be made to the experience, but none of that can explain all these nuances in a way a temporary visitor will read and grasp.

OTOH, it's easier to teach them "HTTP unsafe, don't type anything private".

[detaro]

> The ideal behavior would be for your browser to make it clear that the connection safe from third party attacks, but that it can't verify the website.

If it can't verify the website, the connection is not "safe from third party attacks".

[oarsinsync]

> Why is it that Google and the tech giants would rather that you use highly insecure HTTP than a possibly insecure self signed certificate?

There are legacy concerns that factor in here, where HTTP was the default, and HTTPS was a costly alternative.

Changing defaults can be expensive.

[jsnell]

Chrome has been marking HTTP URLs as "not secure" in the URL bar for like three years.

[unqueued]

The current implementation is idiosyncratic.

Out of the box, you will get a lot more resistance for using a self signed certificate than bare HTTP. At the very least, self signed certificates should be in the same security context as HTTP.

Our devices should opportunistically use encryption, even if validation is not available.

I had a client that wanted to use an Android tablet to monitor IP cameras on his local network, and it was virtually impossible to use the TLS on zeroconf .local domains.

The official solution is to rely on the underlying network for security. Even though the webservers on devices and our browsers have TLS support.