Mention eavesdropping and MiTM in security section

[michielbdejong]

Hi!

I just read https://github.com/flyweb/spec#security-and-privacy-considerations and had some questions about how eavesdropping and MiTM attacks are prevented in the FlyWeb protocol:

• The first point seems to me to make it easier for a user to selects the right end-point from the list, because the list to select from will be shorter. But it's not clear to me how it's related to security - which type of attack does it prevent?
• The second point seems to me to protect the passive end-point like a TV against e.g. someone who was never physically in the same room switching the channels, but it does not protect the active end-point against MiTM attacks.
• The QR code used for pairing should not be a sticker that never changes, because then its contents are likely to not stay secret for long (e.g. renting different rooms in the same hotel, or someone leaking the QR code of some high-profile device onto a public forum).
• It's unclear to me whether the http server would run directly on top of tcp/ip (making it vulnerable to FireSheep-like attacks), or whether traffic will be encrypted.
• Assuming all FlyWeb traffic will be encrypted, I think the pairing should exchange at least:
  • something related to the public key of the passive end-point, to avoid MiTM.
  • a secret that's different for each session, to avoid these secrets from traveling too far.
• Sessions should probably expire, otherwise an attacker can stay connected to a device e.g. after they check out of a hotel room.
• It may make sense for well-known manufacturers to add signed certs to passive end-points, so the user knows they're dealing with e.g. a Sony device.

I guess there's more to explore here, just writing down some questions and ideas, and IANASE! :)

[kannanvijayan-zz]

Hi Michiel,

The first point seems to me to make it easier for a user to selects the right end-point from the list, because the list to select from will be shorter. But it's not clear to me how it's related to security - which type of attack does it prevent?

Well, this was written in the context of there being a web API to discover fly web services (as opposed to just advertising them). The security consideration being that it prevents a web page from discovering arbitrary services in your vicinity - a page would only discover FlyWeb services using this API, and no others.

The second point seems to me to protect the passive end-point like a TV against e.g. someone who was never physically in the same room switching the channels, but it does not protect the active end-point against MiTM attacks.

This is a valid observation. MiTM is a separate issue. The pairing is for security from the device perspective: the device wants to ensure some protocol for the client proving itself by some criteria. I don't think the MiTM issue can be solved without looking into a modified signed-certificate system similar to that used by HTTPS. It's a more complex issue.

The QR code used for pairing should not be a sticker that never changes, because then its contents are likely to not stay secret for long (e.g. renting different rooms in the same hotel, or someone leaking the QR code of some high-profile device onto a public forum).

Absolutely. I was trying to describe a QR code generated and displayed on screen at the time of pairing.

It's unclear to me whether the http server would run directly on top of tcp/ip (making it vulnerable to FireSheep-like attacks), or whether traffic will be encrypted.

This has not been decided it. In fact it's not even clear that http is the best protocol for this application. We may want a different, http-like protocol that one could serve resources over, but doesn't carry all the semantics of http. The spec is a draft I whipped up quickly and has been modified by Jonas since then. None of this stuff is set in stone. I'll necessarily evolve as we proceed with implementation and address these issues first-hand in draft implementations.

Sessions should probably expire, otherwise an attacker can stay connected to a device e.g. after they check out of a hotel room.

Most likely yes - sessions should time out. In some circumstances, some devices may end up supporting at most one session at a time (e.g. only one controller for a given device). The expiration policy is something that needs more thought.

It may make sense for well-known manufacturers to add signed certs to passive end-points, so the user knows they're dealing with e.g. a Sony device.

Yeah, a TLS-like approach. This certainly deserves thought down the line. Right now we're pre-occupied with the basic non-secure core implementation, but this is something I'd like to give more thought to when appropriate. I'd also like to consult some domain experts on this as FlyWeb evolves.

[michielbdejong]

The security consideration being that it prevents a web page from discovering arbitrary services in your vicinity

ok, got it.

Right now we're pre-occupied with the basic non-secure core implementation, but this is something I'd like to give more thought to when appropriate.

Shouldn't we make it secure from the get-go? Using WebRTC DataChannels (or at least DTLS) could be a good fit here, Encryption is mandatory for all WebRTC components and I think users and developers will not expect anything less from FlyWeb, so publishing the non-secure version without a big "Not ready for production" disclaimer may lead to confusion, and to people shipping vulnerable applications.

[michielbdejong]

See also http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf

[michielbdejong]

Any new thoughts on how traffic between the FlyWeb server and the FlyWeb client can be encrypted?

I agree that standard https is unfortunately not usable when dealing with local IP addresses, but what about for instance setting up a WebRTC DataChannel immediately after the discovery dance?