Re: Firefox: security vs flexibility or rtfm?

2017-04-29 Thread Mark Copper
On Fri, Apr 28, 2017 at 9:14 PM, Andy Smith  wrote:
> Hi Mark,
>
> I think Mozilla's position is reasonable since if you allow this
> sort of thing to remain possible, nobody will fix anything. Broken
> software will ship with instructions for the users to "just make an
> exception".
>
> Would it be feasible to put a proxy in front of the HTTP-only
> service, that consumes HTTP on its backend and exposes HTTPS on its
> frontend?
>
> That way, the burden is on the administrator rather than the
> end-user, which is probably a fairer division of labour.

I think this is spot on. Thank you. A quick search shows Apache
modules mod_proxy and mod_ssl as a viable path. And with cheap single
board computers preloaded with Debian and Apache, old gear stays
economically viable. Cool.

Your point about division of labor is well-taken. While I initially
bridled at free software not being free, I understand that a publicly
distributed browser has special responsibilities--especially when
there exist secure solutions to a given problem just a little further
afield.

Mark



Re: Firefox: security vs flexibility or rtfm?

2017-04-29 Thread Fungi4All
 Original Message 
Subject: Re: Firefox: security vs flexibility or rtfm?
From: mcop...@straitcity.com

>We only need one browser to work as these
>tasks are all performed in house. Just seemed like there must be a lot
>of old equipment with embedded HTTP servers out there that clever
>people keep working with OSS and chewing gum. But it's an imperfect
>world and no one can eliminate risk completely--we may just have to be
>vigilant.

Qupzilla works really well and is light on resources as it is pretty uncomplex 
to configure
https://github.com/QupZilla/qupzilla

Re: Firefox: security vs flexibility or rtfm?

2017-04-28 Thread Andy Smith
Hi Mark,

I think Mozilla's position is reasonable since if you allow this
sort of thing to remain possible, nobody will fix anything. Broken
software will ship with instructions for the users to "just make an
exception".

Would it be feasible to put a proxy in front of the HTTP-only
service, that consumes HTTP on its backend and exposes HTTPS on its
frontend?

That way, the burden is on the administrator rather than the
end-user, which is probably a fairer division of labour.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: Firefox: security vs flexibility or rtfm?

2017-04-28 Thread Anders Andersson
On Fri, Apr 28, 2017 at 8:35 PM, Mark Copper  wrote:
>> Would mozilla.support.firefox on news.mozilla.org be more productive as your
>> description suggests an OS independent problem?
>
> I think the issue has been raised and rejected at Firefox. Although OS
> independent, I was thinking a work-around might involve the
> distro--Chromium is gone but maybe there's a browser we didn't
> consider, for instance. We only need one browser to work as these
> tasks are all performed in house.

There are loads of browsers.

https://packages.debian.org/stable/web/

Search for "browser", find a suitable one.



Re: Firefox: security vs flexibility or rtfm?

2017-04-28 Thread Mark Copper
> Would mozilla.support.firefox on news.mozilla.org be more productive as your
> description suggests an OS independent problem?

I think the issue has been raised and rejected at Firefox. Although OS
independent, I was thinking a work-around might involve the
distro--Chromium is gone but maybe there's a browser we didn't
consider, for instance. We only need one browser to work as these
tasks are all performed in house. Just seemed like there must be a lot
of old equipment with embedded HTTP servers out there that clever
people keep working with OSS and chewing gum. But it's an imperfect
world and no one can eliminate risk completely--we may just have to be
vigilant.



Re: Firefox: security vs flexibility or rtfm?

2017-04-28 Thread Richard Owlett

On 04/28/2017 11:33 AM, Mark Copper wrote:

Our web server is off-site, colocated at a typical data center.
On-site are networked items such as a label printer and a weigh scale.

To generate a shipping label from Firefox browser, one requests a page
from the server, then gets the weight from the scale. At first this is
a problem: we had a Beaglebone serving HTTP requests for the weight
and Firefox blocked the request. Solvable by serving weight over HTTPS
with CORS header, using the self-signed cert and whitelisting the
private IP address in Firefox.

But for printing the label, we have no control over the HTTP server
(and Zebra seems to have no plans to update their print servers): it
does not serve HTTPS requests, so default Firefox blocks the XHR.
Firefox does offer a way to unblock mixed content on a website
temporarily, but you can't unblock *before* the request, which
invalidates the label, and as soon as one navigates away from the
site, the block is re-instated. So the only stable solution appears to
be setting the security.mixed_content.block_active_content parameter
to false. But that means allowing mixed active content on any page
served anywhere on the net.

So I'm wondering, first, am I missing something obvious? Or, now that
Debian has thrown its lot in with Firefox, is this an issue for anyone
else? Is there a reason why we can't permanently allow mixed content
just for websites we control? Or allow XHR for private IP's? I think I
saw a Firefox bug thread where these concerns were summarily
dismissed, but there must be a lot of shops like ours out there. How
do they handle this security issue?

Thanks for reading.

Mark


Would mozilla.support.firefox on news.mozilla.org be more productive as 
your description suggests an OS independent problem?







Firefox: security vs flexibility or rtfm?

2017-04-28 Thread Mark Copper
Our web server is off-site, colocated at a typical data center.
On-site are networked items such as a label printer and a weigh scale.

To generate a shipping label from Firefox browser, one requests a page
from the server, then gets the weight from the scale. At first this is
a problem: we had a Beaglebone serving HTTP requests for the weight
and Firefox blocked the request. Solvable by serving weight over HTTPS
with CORS header, using the self-signed cert and whitelisting the
private IP address in Firefox.

But for printing the label, we have no control over the HTTP server
(and Zebra seems to have no plans to update their print servers): it
does not serve HTTPS requests, so default Firefox blocks the XHR.
Firefox does offer a way to unblock mixed content on a website
temporarily, but you can't unblock *before* the request, which
invalidates the label, and as soon as one navigates away from the
site, the block is re-instated. So the only stable solution appears to
be setting the security.mixed_content.block_active_content parameter
to false. But that means allowing mixed active content on any page
served anywhere on the net.

So I'm wondering, first, am I missing something obvious? Or, now that
Debian has thrown its lot in with Firefox, is this an issue for anyone
else? Is there a reason why we can't permanently allow mixed content
just for websites we control? Or allow XHR for private IP's? I think I
saw a Firefox bug thread where these concerns were summarily
dismissed, but there must be a lot of shops like ours out there. How
do they handle this security issue?

Thanks for reading.

Mark