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.
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.
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.
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).
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 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.
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.
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.
"Flash proxy" is a name that should make you think "quick" and "short-lived." Our implementation uses standard web technologies: JavaScript and WebSocket. (In the long-ago past we used Adobe Flash, but do not any longer.)
Of course, I am not a fan of violating firmware standards like UEFI/ACPI and dislike it when x86 Chromebooks did this. Having different firmware for different OSes defeats the point of firmware standards. I think it is possible to run UEFI as a payload in coreboot.
The idea of booting OS from ROM has been around for a long time; in the PC world, there's servers with a hypervisor in the BIOS. Interesting to see this being done as a mod, however.
16MB may not seem like a lot of space compared to gigabyte-sized distros, but if you look at things like TinyCore or even more extreme, the (non-Linux) MenuetOS, you can still put a lot of functionality in there.
45 comments
[ 2.5 ms ] story [ 67.6 ms ] threadThe only reason to not have one are (misguided, IMO) principles, lazyness, ignorance, ... or there really is a MITM. :P
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.
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).
And HTTP/2.0 thankfully. OE is a good improvement, indeed, but it's not worth teaching users bad practices for the authenticated stuff.
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.
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).
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.
You're currently helping people in censored regions with FlashProxy. Thanks! [1]
I just think that users/browsers should be aware of what activity a site may incur.
--
[1] https://crypto.stanford.edu/flashproxy/options.html
Thanks.
"Flash proxy" is a name that should make you think "quick" and "short-lived." Our implementation uses standard web technologies: JavaScript and WebSocket. (In the long-ago past we used Adobe Flash, but do not any longer.)
http://crypto.stanford.edu/flashproxy/
The proxy cannot work when the enclosing page uses https. See FlashProxy's FAQ: https://trac.torproject.org/projects/tor/wiki/FlashProxyFAQ
16MB may not seem like a lot of space compared to gigabyte-sized distros, but if you look at things like TinyCore or even more extreme, the (non-Linux) MenuetOS, you can still put a lot of functionality in there.
With http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-c... and now this, and an (unofficial) schematic available, it seems the X60 is becoming a great platform for hardware hacking. I've noticed the prices for a used one have been going up.