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: Jim Manico <jim.manico@owasp.org>
Date: Tue, 21 Oct 2014 18:25:22 -0500
Message-ID: <-2206045198714464523@unknownmsgid>
To: Chris Palmer <palmer@google.com>
Cc: Ángel González <angel@16bits.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
If you use an ephemeral cipher suite, which most browsers support
•well• today, then the server-side SSL/TLS key will NOT be used to
encrypt data, at all.

Jim Manico
(808) 652-3805

> On Oct 21, 2014, at 6:07 PM, Chris Palmer <palmer@google.com> wrote:
> On Tue, Oct 21, 2014 at 3:57 PM, Ángel González <angel@16bits.net> 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?
> I know. No, I did not check; I was only concerned that the key was not
> hard-coded. Given the many problems with Linux' CRNG, especially but
> not only a device like that, I didn't bother checking any further.
>>> 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.
> Otherwise it's planned unsafety.
> Perhaps vendors could open source their abandonware. Even then,
> though, most fielded devices would still be unsafe.
Received on Tuesday, 21 October 2014 23:25:51 UTC

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