Replacing a Thinkpad X60 Bootflash Chip | Hacker News Reader

Replacing a Thinkpad X60 Bootflash Chip

blog.patternsinthevoid.net

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.

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.

I get a cert error when trying to access the site.

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

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.

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

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.

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.

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.

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.

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.

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).

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.

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

web of trust

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.

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.

why are you disabling the card bus, firewire and sd card ports?

At least 2 of those interfaces support DMA to host RAM.. https://en.wikipedia.org/wiki/DMA_attack

D'oh. Somehow missed the fact that you were hardening the machine against attack.

Noted this at the bottom of the page:

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

Now you're on a terrorist watchlist.

Aha! That explains why the corporate proxy blocked it as a "Botnet/Malicious outbound"

Thanks.

Damn, I hope I didn't just eat a lot of my data plan. I am on iOS...

Luckily no Flash to speak of there.

Apparently, that's not what they mean:

"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/

That's truly unpleasant. I don't get how anybody thinks that is acceptable behavior.

The name is Flashproxy but it doesn't actually use Flash (it used to). It uses WebSocket.

What the fuck? That is absolutely not cool.

Sure am glad I run NoScript.

Given the content of the page, I found that rather ironic.

The website is wrong, because you are not currently helping people in censored regions with FlashProxy.

The proxy cannot work when the enclosing page uses https. See FlashProxy's FAQ: https://trac.torproject.org/projects/tor/wiki/FlashProxyFAQ

Reply on news.ycombinator.com