Re: Firefox: security vs flexibility or rtfm?
On Fri, Apr 28, 2017 at 9:14 PM, Andy Smithwrote: > 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?
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?
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?
On Fri, Apr 28, 2017 at 8:35 PM, Mark Copperwrote: >> 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?
> 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?
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?
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