The difference is that authentication was expected here. If you don't get authentication when it was expected and asked for that should be a red flag that something is amiss.

Effectively this creates a chicken little situation where attacks are indistinguishable from common configurations. This lowers the costs of attacking because it reduces the risk of detection, it also makes attacks more successful because it trains users to click through the warnings.

This is not a misconfiguration, it is actually better to use a self signed certificate if you want to ensure authenticity even in the face of world power adversaries.

I don't buy that argument: The same ability to manually inspect the fingerprint (against what?) exist in both cases.

Existing browsers do not facilitate trust on first use because there is no interface difference between "I've never seen this sites unsigned cert before" and "The unsigned cert I was expecting changed". In particular, you can't distinguish the "self-signed cert I was expecting is still there" from "it's now giving me a world-power forged CA signed cert" (both cases show no notice).

Besides, inhibiting people from rotating an always online key is pretty poor key management. If you were to improve TOFU in browsers, it could work just as well for CA authenticated. So having it signed is purely additive, and while maybe there is some false sense of security there thats not a good tradeoff for completely dismantling the users instincts in reporting suspicious stuff.

If one wants an opportunistic encryption, there're tcpcrypt or IPsec for that.

If one wants to encourage others to blindly accept untrusted certificates from whatever server decides "to hell with authorities" - that's not a good idea. When those World Power Adversaries will consider messing with the site, visitors will already be trained to accept the certificate (hah!)

If one really insists on self-signed certificate, there should be at least an HTTP (i.e. accessible without accepting anything!) page describing the reasoning behind the whole situation and providing means to validate the certificate. Like, say, a PGP signature of certificate in question, signed with a key that could be traced to site owner with reasonable level of trust. Or at least TLSA DNS records (dig says there're none).

> If one wants an opportunistic encryption, there're tcpcrypt or IPsec for that.

And HTTP/2.0 thankfully. OE is a good improvement, indeed, but it's not worth teaching users bad practices for the authenticated stuff.

If it's plain HTTP, serve it as such. The browser message is not misleading in any way. The site uses an untrusted certificate, and there's danger in that. Just don't put self-signed certs on internet-facing pages. It offers literally no benefit, but causes a reasonable amount of harm.

The site's audience is going to be technical.

She explains how to check the SSL certificate fingerprint here:

https://blog.patternsinthevoid.net/isis.txt

Once you've whitelisted her self-signed cert, you know from then on that you're not being MITMed (for what that's worth in a blog).

If you are doing a MITM attack, you might as well change the content of isis.txt on the fly.

web of trust

Except you can't get there unless you go past the warning.

There is an awkward period (after clicking past the warning and before verifying the signed SSL certificate fingerprint) which is no more or less safe than HTTP, but which is more cumbersome and might encourage often-bad behavior in some users. After verifying that the certificate is signed by her (which requires trusting her public key--more hoops), you get some benefit.

It's difficult to weigh the cost/benefit, and nobody is denying that PKI can be awkward.

/thread?

ed: ok, i guess we might still debate the cost/benefit of getting a free cert--i don't really know.