Brian Smith | 8 Jun 02:43 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

Adam Barth wrote:
> > On 5/31/2011 8:24 AM, Brian Smith wrote:
> >>
> >> We have also discussed blocking https+ws:// content completely in
> >> our
> >> WebSockets implementation, so that all WebSockets on a HTTPS page
> >> must be
> >> wss://. That way, we could avoid making mixed content problems any
> >> worse.
> >
> > Do you have a bug on file for that yet?
> 
> If you'd be willing to file a bug at bugs.webkit.org too (and CC me),
> I can help make sure WebKit and Firefox end up with the same behavior
> here.

Bugzilla Bug 662692
Chromium Issue 85271
WebKit Issue 62253

I wasn't sure which email address to use to CC you to the Chromium and WebKit bugs.

Cheers,
Brian
Adam Barth | 8 Jun 02:52 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith <bsmith <at> mozilla.com> wrote:
> Adam Barth wrote:
>> > On 5/31/2011 8:24 AM, Brian Smith wrote:
>> >>
>> >> We have also discussed blocking https+ws:// content completely in
>> >> our
>> >> WebSockets implementation, so that all WebSockets on a HTTPS page
>> >> must be
>> >> wss://. That way, we could avoid making mixed content problems any
>> >> worse.
>> >
>> > Do you have a bug on file for that yet?
>>
>> If you'd be willing to file a bug at bugs.webkit.org too (and CC me),
>> I can help make sure WebKit and Firefox end up with the same behavior
>> here.
>
> Bugzilla Bug 662692
> Chromium Issue 85271
> WebKit Issue 62253
>
> I wasn't sure which email address to use to CC you to the Chromium and WebKit bugs.

Thanks!

Adam
Christopher Blizzard | 8 Jun 17:40 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On 6/7/2011 5:52 PM, Adam Barth wrote:
> On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith<bsmith <at> mozilla.com>  wrote:
>> Adam Barth wrote:
>>>> On 5/31/2011 8:24 AM, Brian Smith wrote:
>>>>> We have also discussed blocking https+ws:// content completely in
>>>>> our
>>>>> WebSockets implementation, so that all WebSockets on a HTTPS page
>>>>> must be
>>>>> wss://. That way, we could avoid making mixed content problems any
>>>>> worse.
>>>> Do you have a bug on file for that yet?
>>> If you'd be willing to file a bug at bugs.webkit.org too (and CC me),
>>> I can help make sure WebKit and Firefox end up with the same behavior
>>> here.
>> Bugzilla Bug 662692
>> Chromium Issue 85271
>> WebKit Issue 62253
>>
>> I wasn't sure which email address to use to CC you to the Chromium and WebKit bugs.
> Thanks!
>
> Adam

Do we have consensus that this is something we want, both internally and 
externally?

--Chris
Adam Barth | 8 Jun 19:10 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On Wed, Jun 8, 2011 at 8:40 AM, Christopher Blizzard
<blizzard <at> mozilla.com> wrote:
> On 6/7/2011 5:52 PM, Adam Barth wrote:
>> On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith<bsmith <at> mozilla.com>  wrote:
>>> Adam Barth wrote:
>>>>> On 5/31/2011 8:24 AM, Brian Smith wrote:
>>>>>>
>>>>>> We have also discussed blocking https+ws:// content completely in
>>>>>> our
>>>>>> WebSockets implementation, so that all WebSockets on a HTTPS page
>>>>>> must be
>>>>>> wss://. That way, we could avoid making mixed content problems any
>>>>>> worse.
>>>>>
>>>>> Do you have a bug on file for that yet?
>>>>
>>>> If you'd be willing to file a bug at bugs.webkit.org too (and CC me),
>>>> I can help make sure WebKit and Firefox end up with the same behavior
>>>> here.
>>>
>>> Bugzilla Bug 662692
>>> Chromium Issue 85271
>>> WebKit Issue 62253
>>>
>>> I wasn't sure which email address to use to CC you to the Chromium and
>>> WebKit bugs.
>
> Do we have consensus that this is something we want, both internally and
> externally?

(Continue reading)

Collin Jackson | 8 Jun 19:45 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

It seems fine to me to block ws:// in https pages as long as there are
available workarounds for people who have a legitimate reason to access
ws:// from an https page. I think you can do that with an iframe to an HTTP
page, using postMessage to pass the web socket data back and forth between
the https and http contexts. This will cause the browser to display a mixed
content warning, which is what you want.

On Wed, Jun 8, 2011 at 10:10 AM, Adam Barth <abarth-mozilla <at> adambarth.com>wrote:

> On Wed, Jun 8, 2011 at 8:40 AM, Christopher Blizzard
> <blizzard <at> mozilla.com> wrote:
> > On 6/7/2011 5:52 PM, Adam Barth wrote:
> >> On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith<bsmith <at> mozilla.com>  wrote:
> >>> Adam Barth wrote:
> >>>>> On 5/31/2011 8:24 AM, Brian Smith wrote:
> >>>>>>
> >>>>>> We have also discussed blocking https+ws:// content completely in
> >>>>>> our
> >>>>>> WebSockets implementation, so that all WebSockets on a HTTPS page
> >>>>>> must be
> >>>>>> wss://. That way, we could avoid making mixed content problems any
> >>>>>> worse.
> >>>>>
> >>>>> Do you have a bug on file for that yet?
> >>>>
> >>>> If you'd be willing to file a bug at bugs.webkit.org too (and CC me),
> >>>> I can help make sure WebKit and Firefox end up with the same behavior
> >>>> here.
> >>>
> >>> Bugzilla Bug 662692
(Continue reading)

Adam Barth | 16 Jun 22:42 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev

On Wed, May 18, 2011 at 1:00 PM, Christopher Blizzard
<blizzard <at> mozilla.com> wrote:
> On 5/18/2011 12:27 PM, Adam Barth wrote:
>> Indeed, which is why we experimented with a hard block.  Our plan is
>> to move in smaller steps, hopefully in coordination with other browser
>> vendors.
>
> Pick a date/release.  We haven't talked about it, but we might game for that
> kind of action.  (It's hard to break things on your own. :P)

To update this thread, here's a blog post describing what we're
planning on doing:

http://googleonlinesecurity.blogspot.com/2011/06/trying-to-end-mixed-scripting.html

We backed away from a hard block because too many sites broke.  The
current plan is block + infobar + evangelism for active content
(script, plug-ins, CSS).  If the evangelism goes well, we hope to move
to harder blocks in the future.

If Firefox does something similar, we'll probably have a greater
chance of moving to a more secure default in the future.

Thanks,
Adam
Nelson B | 23 Jun 01:37 2011

Re: NSS/PSM improvements - short term action plan

On 2011/04/08 15:49 PDT, Sid Stamm wrote:
> Hi everybody.

Everybody?

Why isn't this discussion at least cross posted to dev.tech.crypto
where the NSS people hang out?

> After the few meetings and a couple of hours of discussion in the last
> two days, we've made a short list of desired upgrades for NSS/PSM for
> the near term.  This message should hopefully serve as a summary of the
> technical bits that -- based on the discussions -- seemed most urgent.

Who "we", white man?  Seriously, we are the "we" who had these meetings?

I can tell you there are NSS developers who never heard about this until now.
Gervase Markham | 23 Jun 12:09 2011
Picon

Re: NSS/PSM improvements - short term action plan

Here's an imcomplete status update; further information from anyone
would be welcome:

On 08/04/11 23:49, Sid Stamm wrote:
> Bucket A:
> - Move to libpkix for all cert validation (bug 479393)

The code is now checked in; bug 651246 tracks flipping the necessary
pref. Brian Smith is working on the dependencies of this bug.

> - Complete active distrust in NSS (bug 470994)

I thought Bob was working on this, including some preliminary cleanup of
NSS flag names, but I haven't seen anything more recently. Bob?

> - Implement callbacks to augment validation checking (bug 644640)

It has been decided not to work further on this at the present time,
because it is too hard to design an API which meets sufficient numbers
of use cases. Those wanting to do trust experiments will need to ship
their own custom builds for now.

> - Implement subscription-based blocklisting of certs via update ping
> (remove need to ship patch)

Is there a bug for this?

> Bucket B:
> - Implement OCSP Stapling (bug 360420)

(Continue reading)

Gervase Markham | 23 Jun 12:09 2011
Picon

Re: NSS/PSM improvements - short term action plan

On 23/06/11 00:37, Nelson B wrote:
> Everybody?
> 
> Why isn't this discussion at least cross posted to dev.tech.crypto
> where the NSS people hang out?

My apologies. It was posted both in mozilla.dev.security and
mozilla.dev.security.policy, which is where discussion has been going on
regarding the recent CA security breaches.

There was at least one NSS developer (Bob Relyea) at the meeting, and
Kai was there too.

The meeting was also trailled at the open meeting we had the previous
day, which was widely publicised, and which had representation from
several companies and CAs. We tried to get dial-in available bit it
didn't work in the chosen room; however, no-one reported not being able
to attend for this reason.

>> After the few meetings and a couple of hours of discussion in the last
>> two days, we've made a short list of desired upgrades for NSS/PSM for
>> the near term.  This message should hopefully serve as a summary of the
>> technical bits that -- based on the discussions -- seemed most urgent.
> 
> Who "we", white man?  Seriously, we are the "we" who had these meetings?

Meeting attendees I can remember were:

Sid Stamm
Brian Smith
(Continue reading)

Brian Smith | 24 Jun 08:37 2011

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev

Here is Microsoft's blog post on the same subject:
http://blogs.msdn.com/b/ie/archive/2011/06/23/internet-explorer-9-security-part-4-protecting-consumers-from-malicious-mixed-content.aspx

----- Original Message -----
> From: "Adam Barth" <abarth-mozilla <at> adambarth.com>
> To: "Christopher Blizzard" <blizzard <at> mozilla.com>
> Cc: "Chris Evans" <cevans <at> google.com>, mozilla-dev-security <at> lists.mozilla.org
> Sent: Thursday, June 16, 2011 1:42:08 PM
> Subject: Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev
> On Wed, May 18, 2011 at 1:00 PM, Christopher Blizzard
> <blizzard <at> mozilla.com> wrote:
> > On 5/18/2011 12:27 PM, Adam Barth wrote:
> >> Indeed, which is why we experimented with a hard block. Our plan is
> >> to move in smaller steps, hopefully in coordination with other
> >> browser
> >> vendors.
> >
> > Pick a date/release. We haven't talked about it, but we might game
> > for that
> > kind of action. (It's hard to break things on your own. :P)
> 
> To update this thread, here's a blog post describing what we're
> planning on doing:
> 
> http://googleonlinesecurity.blogspot.com/2011/06/trying-to-end-mixed-scripting.html
> 
> We backed away from a hard block because too many sites broke. The
> current plan is block + infobar + evangelism for active content
> (script, plug-ins, CSS). If the evangelism goes well, we hope to move
> to harder blocks in the future.
(Continue reading)


Gmane