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

2011-10-26 Thread Adam Barth
On Wed, Oct 26, 2011 at 2:09 AM, Tobias Oberstein wrote: >> 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

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

2011-10-26 Thread Tobias Oberstein
> 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.

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

2011-10-25 Thread Glenn Maynard
On Tue, Oct 25, 2011 at 6:32 PM, Ian Hickson wrote: > Sure, there are specific cases where one is easier than the other. There > are also specific cases where it's easier to just send malware to the user > than attempt a passive attack. That doesn't mean that we should just > protect against malw

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

2011-10-25 Thread Ian Hickson
On Tue, 25 Oct 2011, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson wrote: > > > > That only makes sense if passive attack is significantly easier than > > active attack, which it is not. > > Passive attacks are significantly easier to do without any risk of > discovery, es

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

2011-10-25 Thread Glenn Maynard
On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson wrote: > That only makes sense if passive attack is significantly easier than > active attack, which it is not. > Passive attacks are significantly easier to do without any risk of discovery, especially on a large scale. -- Glenn Maynard

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

2011-10-25 Thread Ian Hickson
On Tue, 25 Oct 2011, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson 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",

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

2011-10-25 Thread Adam Barth
On Tue, Oct 25, 2011 at 2:34 PM, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson 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 "

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

2011-10-25 Thread Glenn Maynard
On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson 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-create

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

2011-10-25 Thread Ian Hickson
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 la

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

2011-10-25 Thread Tobias Oberstein
> > Does that mean Opera might just _silently_ reject untrusted certs > > without giving the user a dialog to accept the cert? > > Right. > > > That would be unfortunate IMHO. Since then there is no way to get an > > acceptable user experience any longer. > > > > I can't present a JS created noti

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

2011-10-25 Thread Simon Pieters
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein wrote: > Would the following then be appropriate behavior for browsers? > > User loads https://somehost.com:9000/index.html > > UA presents "cert for somehost:9000 not trusted .. accept .. continue?" > dialog. > => That dialog is builtin

AW: AW: WebSocket API: close and error events

2011-10-25 Thread Tobias Oberstein
> > Would the following then be appropriate behavior for browsers? > > > > User loads https://somehost.com:9000/index.html > > > > UA presents "cert for somehost:9000 not trusted .. accept .. continue?" > > dialog. > > => That dialog is builtin, no JS involved. As today. > > > > If user continues,

Re: AW: WebSocket API: close and error events

2011-10-25 Thread Simon Pieters
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein wrote: > Is executing step 2 above (fire "error") meant to cancel execution of step 3 (fire "close")? No, it would say "...and abort these steps" if it did. Just to be sure I get that right: If step 2 is executed, that is "error" is f

AW: WebSocket API: close and error events

2011-10-25 Thread Tobias Oberstein
> > Is executing step 2 above (fire "error") meant to cancel execution of step 3 > (fire "close")? > > No, it would say "...and abort these steps" if it did. Just to be sure I get that right: If step 2 is executed, that is "error" is fired, then abort and do not continue with step 3, that is do