W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: AW: AW: AW: WebSocket API: close and error events

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 25 Oct 2011 14:41:03 -0700
Message-ID: <CAJE5ia8F=z_w6PHRo62Rc+NW+vFxer-23GBZTgf1xeGL2Dn6VA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Ian Hickson <ian@hixie.ch>, Tobias Oberstein <tobias.oberstein@tavendo.de>, Simon Pieters <simonp@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Oct 25, 2011 at 2:34 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson <ian@hixie.ch> wrote:
>> On Tue, 25 Oct 2011, Tobias Oberstein wrote:
>> >
>> > There are situations when self-signed certs are quite common like on
>> > private networks or where self-signed certs might be "necessary", like
>> > with a software appliance that auto-creates a self-signed cert on first
>> > boot (and the user is too lazy / does not have own CA).
>> A self-signed cert essentially provides you with no security. You might as
>> well be not bothering with encryption.
> This is complete nonsense.  Protecting against passive attacks is a major,
> clear-cut win, even without protecting against active (MITM) attacks.

Generally speaking, we don't want to show certificate errors for
subresource loads (including WebSocket connections) because the user
has no context for making a reasonable security decision.  For
example, Chrome doesn't let the user click through certificate errors
for images or iframes.

Protection against passive eavesdroppers isn't worth losing protection
against active network attackers.

Received on Tuesday, 25 October 2011 21:42:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC