Bug 5576 - Access Koha via SSL
Summary: Access Koha via SSL
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement with 1 vote (vote)
Assignee: Bugs List
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-05 17:39 UTC by Nicole C. Engard
Modified: 2015-06-04 23:23 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2011-01-05 17:39:18 UTC
Some libraries want to access Koha over SSL.
Comment 1 Ian Walls 2011-01-05 18:08:37 UTC
To specify:

Running Koha over SSL is an Apache configuration.  For the staff client, it's easy, since all of the staff client should be secured.  For the OPAC, however, it's more complicated.  There are (often) parts of the OPAC you want to be free and public, without the need for https, and parts like borrower account information, that you want encrypted.

The enhancement I'm working on depends on having parallel OPACs set up; one http, the other https.  There is then a toggle system preference to determine whether to use the https site for patron login.  It automatically changes the necessary links from http to https.
Comment 2 Ian Walls 2011-01-05 19:48:56 UTC
From IRC:

<gmcharlt> sekjal: you may want to take a look at how Evergreen handles using SSL for patron login and display in the OPAC and regular HTTP for everything else
<sekjal> gmcharlt:  thanks, I'll take a peek
<chris> id like that once you are logged in, its ssl, before you are logged in its http
 once you are placing holds etc, that may as well be encrypted too
 make the fbi earn their money
<gmcharlt> or move some of the scripts about (to make URL rewriting easier) and have /opac/ and /opac/secure/
<pastebot> "gmcharlt" at 68.101.78.67 pasted "sekjal: the relevant bit from EG's Apache config" (6 lines) at http://paste.koha-community.org/118
<gmcharlt> one thing to note that SSLRequireSSL implies use of mod_ssl; mod_gnutls doesn't have a direct equivalent

The value in pastebin:

# --------------------------------------------------------------------------------
# Force SSL on the OPAC's "My Account" page
# --------------------------------------------------------------------------------
<LocationMatch .*/myopac.xml>
    SSLRequireSSL
</LocationMatch>
Comment 3 Ian Walls 2011-01-05 20:01:14 UTC
hints from http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html

in httpd.conf, with mod_ssl:

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
Comment 4 Galen Charlton 2011-01-06 15:22:35 UTC
I don't think SSLVerifyClient is quite right - that setting controls whether the server requires that the *browser* submit a valid client certificate before it grants access; which is not the same thing as requiring the use of SSL, which what SSLRequireSSL.

That's not to say that one couldn't envision scenarios where a library would want to use client certificates, but unless the library is a spooky three-letter-agency, a public-facing OPAC is not a likely use case for that.
Comment 5 Robin Sheat 2011-06-13 08:10:05 UTC
We need to do the client cert side of thing for a not-quite-so-spooky three letter agency. See Bug 6296 for our status on this.
Comment 6 Indranil Das Gupta 2014-08-28 16:07:24 UTC
Anyone been working on this lately?
Comment 7 Magnus Enger 2014-08-28 18:32:00 UTC
(In reply to Indranil Das Gupta from comment #6)
> Anyone been working on this lately?

Probably not...

And I'd like to take this opportunity to reveal my complete and utter ignorance: Why not have everything on HTTPS?
Comment 8 Robin Sheat 2014-08-28 22:59:35 UTC
(In reply to Magnus Enger from comment #7)
> And I'd like to take this opportunity to reveal my complete and utter
> ignorance: Why not have everything on HTTPS?

We do, it works fine. It's a best practice approach, too. There are a couple of points where Koha assumes http which should be fixed, but if you put a redirect in, it's not too bad to the user (these are potential cookie stealing points however.)

Additionally, this is purely an apache configuration and is pretty much transparent to Koha so no actual dev work is needed.
Comment 9 Magnus Enger 2014-08-29 07:13:29 UTC
Any reason to keep this bug open?
Comment 10 Robin Sheat 2014-08-29 11:31:11 UTC
(In reply to Magnus Enger from comment #9)
> Any reason to keep this bug open?

Not in my opinion.
Comment 11 Magnus Enger 2014-08-29 11:32:31 UTC
(In reply to Robin Sheat from comment #10)
> (In reply to Magnus Enger from comment #9)
> > Any reason to keep this bug open?
> 
> Not in my opinion.

Marking as resolved wontfix, then. If anyone disagrees, please feel free to reopen.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5576
bugs.koha-community.org
crawl=CC-MAIN-2021-21
36849
application/http; msgtype=response
sha1:526N52KJ4QZMUVWRI4D2A6UUI7BUOPGU
<urn:uuid:e7c6fd3f-ec11-44a5-b89e-8d55f7a471cb>
2021-05-12T02:57:10Z
72.14.190.217
text/html
sha1:PX6FSYUG4MIXD72JXEQ542QNXP3RF2TO
<urn:uuid:d0d0ced7-c319-4c24-a454-bf93de74eaa5>
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5576
response
<urn:uuid:67dd94f9-d7a1-4f7b-a472-78d9b11dfdd3>
isPartOf: CC-MAIN-2021-21
publisher: Common Crawl
description: Wide crawl of the web for May 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-34.ec2.internal
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/