Please don't force HTTPS in the software.  I'll explain why I'm making that request here.

First, it's easy to force HTTPS in the apache config for the vhosts, I've done this.  It's a simple matter of a redirect on the port 80 vhost pointed at the https vhost.  This is where certificates would likely be configured anyway, so I think this is a reasonable way to do it.

I've been playing with setting up a web server farm, with a fail-over pair of reverse-proxy servers as the front.  As a performance measure communication between the proxies and the worker nodes is done over plain http (because I trust my LAN enough for that).  I ran into a problem with my tests though where a web app forced https in the software, it produced a redirect loop, because the worker would respond with a http meta redirect to the https port but the web browser was already using that port.  Luckly I would turn off that feature in the software.

I understand that forcing https in the software is a good security measure.  I'm just asking that it be controlled by a system preference, or be made an optional section in the apache config file in consideration of those who would like to avoid the overhead added by https.

Thanks for your consideration.


On Thu, May 30, 2013 at 12:18 PM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,

On Wed, May 29, 2013 at 3:58 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
> Standard session cookies combined with running over HTTPS is really the
> only way. It comes down to threat modelling really: is session hijacking
> something that you feel you care about? (It's perfectly reasonable to
> say either yes, no, or only on the staff client, depending on your
> circumstances.)

I'd personally be happy with requiring SSL for the staff interface and
the OPAC throughout on the basis that patron information is sensitive
enough to demand that level of care.

However, because of the general support issues that would arise around
SSL certs, I suspect that Koha jumping on the HTTPS Everywhere
bandwagon will likely have to remain a recommended practice rather
than a requirement or installation default.

> To make it a bit more secure we could use a different session for the
> staff client vs. the OPAC. At the moment we use the same for both, so
> someone capturing a session cookie from a staff member logged into the
> OPAC can use that to access the staff client.

I think this is a good idea.

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/