Hello, Does anyone have experience with securing (only) the login pages on OPAC/Intranet/both using HTTPS? Any help is appreciated. regards, krishnan India Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/
On Fri, Aug 22, 2008 at 6:31 PM, Time Ly <timepehi@yahoo.in> wrote:
Hello,
Does anyone have experience with securing (only) the login pages on OPAC/Intranet/both using HTTPS? Any help is appreciated.
Hi Time Ly You have a couple of options, the easiest one is to change the templates so that the form action for logging in goes to a https site, that can then redirect to http site after login. The other option is to have the page with form on it served as https, this is harder, because the login form can appear on any page, so you cant just do a redirect on certain urls. I dont have a good idea how to accomplish the second one for the opac, but for the intranet side, you could check if someone is logged in (by checking the cookie) if not, redirect them to the login on the https site. For the opac, you dont have to be logged in, so you would probably want to remove the login forms from everywhere and have a login page, then serve that page as https Hope this helps Chris
If you are using Apache to serve your Koha pages, then you can configure individual pages to force SSL. Check the Apache documentation for Location and SSL.
Hi Jason Yep that would work fine, if the login pages were separate urls, instead they can be the same url as a page you might not want to server ssl. Eg opac-main.pl :) So you would have to rejig some timeplates too. Chris On Sat, Aug 23, 2008 at 1:01 AM, Jason Stephenson <jstephenson@mvlc.org> wrote:
If you are using Apache to serve your Koha pages, then you can configure individual pages to force SSL.
Check the Apache documentation for Location and SSL.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Chris -- I think Jason means just serve the whole site as HTTPS, which is what we do and it works fine. No template modifications are required. The Apache config looks like: <VirtualHost *:443> ServerName whoever.kohalibrary.com SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/whoever.kohalibrary.com.crt SSLCertificateKeyFile /etc/apache2/ssl.key/whoever.kohalibrary.com.plainkey .... SSL protects against the exposure of data in transit, like say, during update of a borrower's password on the staff interface. Nothing special gets done to that data, so it is just POSTed like any other form. But SSL keeps it from being readily sniffable. It can also be used for more advanced forms of authentication like client side certs (but if you're not a government contractor, it's unlikely your library needs to be *that* locked down). --Joe Atzberger, LibLime, Systems Administrator On Fri, Aug 22, 2008 at 9:42 AM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
Hi Jason
Yep that would work fine, if the login pages were separate urls, instead they can be the same url as a page you might not want to server ssl. Eg opac-main.pl :)
So you would have to rejig some timeplates too.
Chris
On Sat, Aug 23, 2008 at 1:01 AM, Jason Stephenson <jstephenson@mvlc.org> wrote:
If you are using Apache to serve your Koha pages, then you can configure individual pages to force SSL.
Check the Apache documentation for Location and SSL.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Quoting "Joe Atzberger" <ohiocore@gmail.com>:
Chris --
I think Jason means just serve the whole site as HTTPS, which is what we do and it works fine. No template modifications are required. The Apache config looks like:
Actually, no, I don't, but for what I mean to work, you will need to serve the whole site as SSL. What we do on our mail server is force everyone using the Horde email client to use a SSL session. One way to do it is to use a rewrite rule in your *:80 virtual host: <VirtualHost *:80> ServerName host.domain.tld Options +Includes RewriteEngine On RewriteRule ^/?(horde|dspam)/?(.*)$ https://host.domain.tld/$1/$2 DirectoryIndex index.html index.php </VirtualHost> The above could be modified to work with a single page as well. RewriteRule ^/?(login.pl)$ https://host.domain.tld/$1 That assumes, of course, that your page is in the document root for your site. The above essentially rewrites the URL to force SSL on. You can also set certain locations so that they Require SSL. When I sent my short message before, I neglected to mention that it is easiest to set up with a RewriteRule. Note that I have not tried any of this with Koha, yet, so I don't know exactly what magic sauce you'd need in httpd.conf to make the login pages force SSL connections, but the above is 1 way that it is generally done. Settings can get more complicated, and more useful, as I mention below.
<VirtualHost *:443> ServerName whoever.kohalibrary.com SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/whoever.kohalibrary.com.crt SSLCertificateKeyFile /etc/apache2/ssl.key/whoever.kohalibrary.com.plainkey ....
SSL protects against the exposure of data in transit, like say, during update of a borrower's password on the staff interface. Nothing special gets done to that data, so it is just POSTed like any other form. But SSL keeps it from being readily sniffable. It can also be used for more advanced forms of authentication like client side certs (but if you're not a government contractor, it's unlikely your library needs to be *that* locked down).
SSL does 3 things: 1. It encrypts data in transit to prevent eavesdropping. 2. It can verify that the site you are connecting to is the site that it claims to be, but only if you trust the certifying authority. 3. It can verify that the person visiting the site is the person that they claim to be, again, only if you trust the certifying authority. I have a server set up where a private location on the main site requires that anyone connecting to it use SSL and that they present a certificate that has been signed by my personal certificate authority. If you don't have it, you don't get in. This not only stops eavesdropping and assures that the users are connecting to the proper site, it also guarantees that only "authorized" people are using the site. It is also a very simple thing to revoke someone's certificate to block future access if their certificate has been abused. I have long thought that SSL has been way underutilized for authentication scenarios such as I describe above. Many sites still rely on passwords and account names. Properly configured, a web site can even determine a particular user from information in the certificate, thus eliminating the need for a username/password combination when a certificate is used for authentication. Of course, the user can (and should) use a password when importing their certificate into their certificate store if they fear their computer being stolen or used by someone else. Sorry for the digression, but SSL has been one of my pet issues lately. Cheers, Jason
--Joe Atzberger, LibLime, Systems Administrator
On Fri, Aug 22, 2008 at 9:42 AM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
Hi Jason
Yep that would work fine, if the login pages were separate urls, instead they can be the same url as a page you might not want to server ssl. Eg opac-main.pl :)
So you would have to rejig some timeplates too.
Chris
On Sat, Aug 23, 2008 at 1:01 AM, Jason Stephenson <jstephenson@mvlc.org> wrote:
If you are using Apache to serve your Koha pages, then you can configure individual pages to force SSL.
Check the Apache documentation for Location and SSL.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
A very basic question: Why would one want to secure the login pages? What threats are you trying to mitigate? Cab Vinton, Director Sanbornton Public Library Sanbornton, NH
I am reviving an old post...can this be easily done with the current latest version of koha, or do we still have to use SSL for the whole site? Assuming I have created virtual hosts for :80/:443 and :8080/:8443, where do I put the Rewrite statements in the VirtualHost segment? If I also need to modify the template files, which file(s) do I need to amend? Thanks. -- View this message in context: http://koha.1045719.n5.nabble.com/Securing-login-pages-tp3054969p5763327.htm... Sent from the Koha-general mailing list archive at Nabble.com.
On 5 August 2013 17:32, Victor Pang <victorp@netmedia.com.sg> wrote:
I am reviving an old post...can this be easily done with the current latest version of koha, or do we still have to use SSL for the whole site?
Assuming I have created virtual hosts for :80/:443 and :8080/:8443, where do I put the Rewrite statements in the VirtualHost segment? If I also need to modify the template files, which file(s) do I need to amend?
Really there is no reason not to serve the entire site in ssl. It should be the default for any site that contains any user information ever :) Chris
I do not wish to encrypt unnecessarily and waste resources. :) Anyway, I am using Koha mainly for the Catalogue / OPAC / z39.50 server features plus the Patron module for the user credentials, and there is no need to encrypt the catalogue data stream. -- View this message in context: http://koha.1045719.n5.nabble.com/Securing-login-pages-tp3054969p5763329.htm... Sent from the Koha-general mailing list archive at Nabble.com.
participants (6)
-
Cab Vinton -
Chris Cormack -
Jason Stephenson -
Joe Atzberger -
Time Ly -
Victor Pang