W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: "Secure Introduction of Internet-Connected Things" (was Re: [webappsec] Agenda for MONDAY Teleconference 2014-10-20, 12:00 PDT)

From: Ángel González <angel@16bits.net>
Date: Wed, 22 Oct 2014 00:57:55 +0200
Message-ID: <1413932275.1371.2.camel@16bits.net>
To: public-webappsec@w3.org
Chris Palmer wrote:
> On the bright side, it’s very good that the machine generates a fresh
> key every time you re-enable HTTPS: That means that the key is not
> static, or identical on all the routers of the same make or model.
That still doesn't mean there won't be duplicate keys. It is hard for a
device to have good entropy after a reset. [1] Did you try resetting it
a few times and comparing the generated keys? 

And obviously things like WiFi keys MUST NOT be produced by jumbling
around the SSID and a couple of public bytes. Even "1234" would be

Vendors SHOULD be adding good random seeds onto device memory at

> CSRF problems

Although it's a task to be solved by router vendors, browsers can help
mitigate this [2] [3]

> if a device is only marketable if its price point is so low that it
> cannot be secure, perhaps it should disable itself after some
> reasonable life-time

Users will perceive it as planned obsolescence for business reasons, and
I wouldn't be surprised if producers treated it like that, too.

> On Mon, Oct 20, 2014 at 10:24 AM, Mike West <mkwst@google.com> wrote:
> >> I think it is a bad idea to have users go through the ordinary
> >> "untrusted certificate" or "unknown authority" flows in the browser to
> >> use these devices, because it trains users to ignore these warnings
> >> and puts back pressure on UA authors who want to make these
> >> experiences increasingly strict.
> I call that the Dual-Mode Client solution in my post. I agree that we
> can't, even for 1 more minute, torture users with the Public Internet
> Mode for private networks. It's awful, and Adrienne and I end up
> closing comments on the bug reports due to the swearing: :|

> >> The idea I was tossing around would be to have some different kind of
> >> secure introduction ceremony to replace the untrusted certificate
> >> dialog *for hosts on the local network only*.  Perhaps something like
> >> Bluetooth / WPS pairing, where the user could get a page that tells
> >> them this is a locally connected device and they have to enter a
> >> pairing code to trust it, with other-than-standard HTTPS UX treatment
> >> following, but less strict rules about mixed content blocking, etc.
> >> than an untrusted or HTTP connection would receive.
> Yes.


I feel it may be possible to combine this "secure introduction at local
network" to also help with the https error because you don't have an
internet exit (maybe it's showing a wifi paywall, or simply "I'm still
establishing ppp connection"). Although that would require a .

Since many of those routers are also the DHCP and DNS server (and
sometimes intercept dns queries). There could be a procedure similar to
DANE, such as DHCP providing an anchor for *.local

If we assume that the rightful owner will have connected to the route
before an attacker could tamper it, there would be the issue of an
attacker-induced disconnection, so the anchor could be stored with the
connection settings (easy for WiFi, match with the SSID. Not so much for
ethernet, but it is much harder to win a race condition with the router
DHCP server, if you are wired to it).

1- https://factorable.net/weakkeys12.conference.pdf
2- https://bugzilla.mozilla.org/show_bug.cgi?id=354493 (2006 bug)
3- https://code.google.com/p/chromium/issues/detail?id=378566
Received on Tuesday, 21 October 2014 22:58:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC