- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 25 Oct 2011 14:41:03 -0700
- 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. Adam
Received on Tuesday, 25 October 2011 21:42:03 UTC