Bug 5576

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.

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>

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>

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.

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.

Anyone been working on this lately?

(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?

(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.

Any reason to keep this bug open?

(In reply to Magnus Enger from comment #9)
> Any reason to keep this bug open?

Not in my opinion.

(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.