The simplest solution would be to modify the settings.php to start pushing
everything over HTTPS once someone has hit an HTTPS URL. The current
code4lib server has been here at OSU longer than I have (and I've been here
for 8+ years), and it's at MOST running at about 25% CPU capacity. Pushing
everything over HTTPS is probably fine too.

As for additional administrative overhead, if someone else wants to manage
the certificate procurement and renewal, it takes me about 5 minutes every
year to put a new certificate in place and then restart Apache once I have
a certificate file.


On Wed, Nov 6, 2013 at 8:34 PM, Chad Fennell <[log in to unmask]> wrote:

> On Wed, Nov 6, 2013 at 8:49 PM, Ross Singer <[log in to unmask]> wrote:
>
> > I guess I just don't see why http and https can't coexist.
> >
> >
> They can definitely coexist, but there is a corresponding maintenance cost
> and a slightly higher risk profile (e.g. session hijacking is still
> possible in a variety of mixed http/https configurations). I noticed a a
> pretty good, if a bit dated, run-down of the tradeoffs for various secure
> setups in Drupal
>
> http://drupalscout.com/knowledge-base/drupal-and-ssl-multiple-recipes-possible-solutions-https
> .
> Even if the solutions have somewhat changed, it does get at the idea of
> what some of the tradeoffs are between security, usability and maintenance.
>
> Just today, I noticed a security alert (https://drupal.org/node/2129381)
> for the Drupal 6 Secure Pages module where theoretically secured pages and
> forms could be transmitted in the clear. This is the module you'd most
> likely use to achieve a mixed http/https site in Drupal.
>
> I have personally tended to just put everything behind https because of the
> added work/modules/maintenance associated to running it along side of http
> (in Drupal, specifically), but I am a lazy person with access to free certs
> and ferncer servers.
>
> HTH
> --
> Chad Fennell
> Web Developer
> University of Minnesota Libraries
> (612) 626-4186
>