This is a self-signed cert. Pretty normal stuff for pages by hackers for hackers. Do you care who is running that site? Are you going to provide them any personal data? Were your browser hardened by you? If you answered no, no, yes then you are pretty safe.

How kind of them to setup the site in a way which is indistinguishable from a MITM, so that its a common and usual thing and when there actually is a MITM against other sites you use you'll suffer from none of that uncomfortable alarm.

How is that different from a plain HTTP site? It's just that your browser has chosen to interpret it in a misleading way.

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.

Have you asked him if you could donate some money towards him getting a verified certificate?

They're free: https://www.startssl.com/

The only reason to not have one are (misguided, IMO) principles, lazyness, ignorance, ... or there really is a MITM. :P

Wildcard certs (which that page uses) are not free.

Also, they (CA+cert) are broken beyond repair. I understand lulling users into false sense of security because they don't understand what they are doing, and scary message is scary. But CA chain is so insecure today, that I would rather trust cached cert, my 'convergence' setup or luck than happy green lock icon.

Her.

My apologies to the author for my mistake.

It shouldn't be normal stuff. If you don't have a trusted cert, don't even bother. You shouldn't be training people, even people who should know better, to click past a certificate warning page.

Still pretty bizarre when properly signed certs for small sites are free of charge.

readable through printfriendly http://www.printfriendly.com/print/?source=site&url=blog.pat...