4 ms·

What would it say? “You’re connecting to an IoT device that has a worthless certificate. Would you like me to open up a completely pointless AES256 session wit

What would it say? “You’re connecting to an IoT device that has a worthless certificate. Would you like me to open up a completely pointless AES256 session with it and pretend that you have a secure connection?” Just use HTTP.

filmor 6y ago
HTTP traffic would be unencrypted, so everyone (esp. on Wifi) could record passwords etc. flying around. With HTTPS, you at least need to MITM the connection to do that. If you establish trust in some other way (cert ID printed on the device?), the connection is secure.
- riskable 6y ago
  Not just intercept: Using HTTPS prevents messing with the connection in-flight. So an attacker won't be able to inject their own payload into that web page you just requested.
  - CountSessine 6y ago
    Except you’re using garbage certificates so anyone could MITM you and inject whatever they like.
    - bavell 6y ago
      In what way are self-signed certs garbage? They're essentially the same as ssh certs.
      - deleted 6y ago
        [deleted]
    - samus 6y ago
      That's a separate kind of attack, not intrinsic to the protocol. If the keypair got leaked or a CA misbehaves and issues multiple certificates that can be used for a host, then yes, it can happen.
drdaeman 6y ago
(Disclaimer: I'm not a security expert). Ideally, I think, something like this: "You're trying to connect to a new device on your local network. To ensure the security please check that the device has a display or a printed label that says 'HTTPS certificate ID: correct horse battery staple couple more random words'?" (mobile devices may suggest to scan a QR code instead). I'm pretty sure if at least one major browser vendor would implement something like this (denoted by a special OID on the certificate), IoT vendors would be happy to follow. Verifying a phrase or scanning a code is not a big burden, and it resolves trust issues. The fingerprint could be either from a private key generated on device (for devices that have a display and can display dynamic content) or from vendor's self-signed "CA" with special critical restrictions (no trust for any signatures unless individually verified + signed certs are only valid on what clients consider to be a local network) which private keys are not on the device itself (for devices with printed labels, to avoid having the same private key on all devices).
- elcritch 6y ago
  I like this idea, as we already add a device serial ID to the ap hosted mode, partly for this reason. Chromecast’s show a random code and users seem to be able to handle this fine.
- ithkuil 6y ago
  That works fine with a brand new device you just unboxed. But what should happen 3 years later? Should the IoT device have a certificate that is valid forever?
  - paledot 6y ago
    I would say yes, as long as certificates are unique per-device. The harm of my light bulb's cert being compromised is less than the harm of my light bulb no longer working if the manufacturer's CA goes offline and it can't renew its cert.
- CountSessine 6y ago
  It certainly sounds a lot better than simply asking browser vendors to give .local a pass on cert validity. I’m still wary of any flow that would have browser users “accepting” a device as secure - could I impersonate that device on the local network? Could I convince someone to accept a site on the wider internet as their IoT device? Someone smarter than me needs to think hard about these questions. Maybe another approach would be to build infrastructure (like protocols and client software) to make building a home cert chain easy? A windows client that would let you create a root cert, install it in your cert store, and then give you server certs to hand out to devices? Give it a consumer friendly brand name or something and get IoT vendors to add a front-and-centre option to adopt a new server cert. Authentication isn’t a tricky problem; it’s the trickiest.
elcritch 6y ago
The identity isn’t trustworthy, but as mentioned below their are ways to handle that with device id’s. Also it’s not pointless to encrypt communication with a device you’ve verified the identity of in the past. It prevents hijackers from later hijacking the device, without The user knowing it. Just the same as the nastygram you get when your ssh server changes its private key. You’re effectively claiming SSH is pointless and/or useless encryption as it doesn’t use certificate chains to verify url/domain. Your argument is the same as saying that any devops ssh’ing into a new local server is pointless and they should just use telenet.
Ayesh 6y ago
It's like calling someone you don't know, but over a secure line.

filmor 6y ago

HTTP traffic would be unencrypted, so everyone (esp. on Wifi) could record passwords etc. flying around. With HTTPS, you at least need to MITM the connection to do that. If you establish trust in some other way (cert ID printed on the device?), the connection is secure.

riskable 6y ago
Not just intercept: Using HTTPS prevents messing with the connection in-flight. So an attacker won't be able to inject their own payload into that web page you just requested.
- CountSessine 6y ago
  Except you’re using garbage certificates so anyone could MITM you and inject whatever they like.
  - bavell 6y ago
    In what way are self-signed certs garbage? They're essentially the same as ssh certs.
    - deleted 6y ago
      [deleted]
  - samus 6y ago
    That's a separate kind of attack, not intrinsic to the protocol. If the keypair got leaked or a CA misbehaves and issues multiple certificates that can be used for a host, then yes, it can happen.

drdaeman 6y ago

(Disclaimer: I'm not a security expert). Ideally, I think, something like this: "You're trying to connect to a new device on your local network. To ensure the security please check that the device has a display or a printed label that says 'HTTPS certificate ID: correct horse battery staple couple more random words'?" (mobile devices may suggest to scan a QR code instead). I'm pretty sure if at least one major browser vendor would implement something like this (denoted by a special OID on the certificate), IoT vendors would be happy to follow. Verifying a phrase or scanning a code is not a big burden, and it resolves trust issues. The fingerprint could be either from a private key generated on device (for devices that have a display and can display dynamic content) or from vendor's self-signed "CA" with special critical restrictions (no trust for any signatures unless individually verified + signed certs are only valid on what clients consider to be a local network) which private keys are not on the device itself (for devices with printed labels, to avoid having the same private key on all devices).

elcritch 6y ago
I like this idea, as we already add a device serial ID to the ap hosted mode, partly for this reason. Chromecast’s show a random code and users seem to be able to handle this fine.
ithkuil 6y ago
That works fine with a brand new device you just unboxed. But what should happen 3 years later? Should the IoT device have a certificate that is valid forever?
- paledot 6y ago
  I would say yes, as long as certificates are unique per-device. The harm of my light bulb's cert being compromised is less than the harm of my light bulb no longer working if the manufacturer's CA goes offline and it can't renew its cert.
CountSessine 6y ago
It certainly sounds a lot better than simply asking browser vendors to give .local a pass on cert validity. I’m still wary of any flow that would have browser users “accepting” a device as secure - could I impersonate that device on the local network? Could I convince someone to accept a site on the wider internet as their IoT device? Someone smarter than me needs to think hard about these questions. Maybe another approach would be to build infrastructure (like protocols and client software) to make building a home cert chain easy? A windows client that would let you create a root cert, install it in your cert store, and then give you server certs to hand out to devices? Give it a consumer friendly brand name or something and get IoT vendors to add a front-and-centre option to adopt a new server cert. Authentication isn’t a tricky problem; it’s the trickiest.

elcritch 6y ago

The identity isn’t trustworthy, but as mentioned below their are ways to handle that with device id’s. Also it’s not pointless to encrypt communication with a device you’ve verified the identity of in the past. It prevents hijackers from later hijacking the device, without The user knowing it. Just the same as the nastygram you get when your ssh server changes its private key. You’re effectively claiming SSH is pointless and/or useless encryption as it doesn’t use certificate chains to verify url/domain. Your argument is the same as saying that any devops ssh’ing into a new local server is pointless and they should just use telenet.

Ayesh 6y ago

It's like calling someone you don't know, but over a secure line.