- From: Ángel González <angel@16bits.net>
- Date: Wed, 22 Oct 2014 00:57:55 +0200
- 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 preferable. Vendors SHOULD be adding good random seeds onto device memory at factory. > 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 > -1 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. +1 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