In August 2016, the University of Michigan Library made a commitment to move most of our web interfaces to exclusive HTTPS. Over the fall, thanks to a great deal of work from many dedicated developers in LIT, we successfully met our goal and implemented HTTPS on our services. Now, user interactions with most of the library’s web sites are secure from snooping between our servers and the user’s web browser.
Along the way, we learned a few things. One of the biggest was the unintended consequences of technical decisions made long ago. More than a decade ago, we made a well-intentioned and reasonable (at the time) decision to use a secure transmission protocol to be equivalent to logging in. So, if a user visited one of our sites via HTTP, they were not and could not be authenticated; if they visited a site via HTTPS, they were not and could not be anonymous.
This approach made sense for our technical infrastructure at the time, and came long before the risks of unsecured web transactions became clear to us all. That early decision simplified some things for us, but created a layer of technical challenge that we have been fighting against in small ways. For example, we had to modify the way Drupal handles authentication to work with our method, rather than doing it the standard way.
Lesson learned: do the simple thing the simple way, even if it isn’t so simple at first.
In the course of moving our systems to HTTPS, we also realized that web-based APIs that we consumed in our own internal systems were problematic. Much as has turned out to be the case with PubMed’s recent switch to exclusive HTTPS, we also learned that applications we wrote and had more or less forgotten about were written without secure protocols in mind. We had to roll back Mirlyn, our library catalog, from exclusive HTTPS to HTTP until we could update other internal applications that used catalog data to access it via HTTPS.
Lesson learned: where possible, write protocol-agnostic code.
Finally, we ran into other unexpected side-effects. By moving to exclusive HTTPS, we broke our link-checking software; the older version of the venerable LinkScan product that we had been happily running for years could handle transactions of HTTPS, but could not handle multiple certificates for a single domain. Fortunately, an upgrade (long overdue itself) solved the problem. While this wasn’t mission critical, the link checking tool is an important part of our content management processes.
Lesson learned: expect unexpected side effects and plan for time and staff to address them.