Comment by danielweber

11 years ago

Browsers shouldn't silently accept self-signed, but there is a class of servers where self-signed is the best we've got: connecting to embedded devices. If I want to talk to the new printer or fridge I got over the web, they have no way of establishing trust besides Tacking my first request to them.

I bought a camera the other day with the nifty feature of having an NFC tag embedded in it to guide your phone to launching (and installing, if necessary) the companion mobile app.

It occurred to me that this is a really good way of establishing a trust path: while they're only using it to guide you to the right app, they could embed a little public key in there. Then you could authenticate the new printer or fridge by physically being near it.

We'd have to extend our UIs a bit to cover these use cases (it should basically act like a trusted self-signed cert), and probably you only want to trust NFC certs for *.local.

Technically, there's no reason why a fridge couldn't have a signed cert tied to some dynamic DNS (e.g. <fridge-serial-number>.<manufacturer>.<tld>).

  • True, but on many small networks, you aren't addressing the embedded device by a FQDN.

    All these appliances should let you change the cert on them, but you still need that initial connection, and at smaller organizations (or households) the certs will never ever be changed.

    I used to work on embedded security projects so I care about this; I also realize that's a small portion of the market. I'm okay with making the people connecting to their new printer jump through a hoop in order to reduce the chances of someone hijacking www.paypal.comm but you still have to allow some way in.

  • But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.