This week’s Thursday Threads looks at a big hole in the security model of most internet sites that require you to log into them with a username and password plus a pair of stories about “big media” battles. If you find these interesting and useful, you might want to add the Thursday Threads RSS Feed to your feed reader or subscribe to e-mail delivery using the form to the right. If you would like a more raw and immediate version of these types of stories, watch my FriendFeed stream (or subscribe to its feed in your feed reader). Comments, as always, are welcome.

Users of Non-SSL Sites are Prone to Hijacking

When logging into a website you usually start by submitting your username and password. The server then checks to see if an account matching this information exists and if so, replies back to you with a “cookie” which is used by your browser for all subsequent requests.

It’s extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called “sidejacking”) is when an attacker gets a hold of a user’s cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.

Screenshot of Firesheep in action, from codebutler.com

This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL. Facebook is constantly rolling out new “privacy” features in an endless attempt to quell the screams of unhappy users, but what’s the point when someone can just take over an account entirely? Twitter forced all third party developers to use OAuth then immediately released (and promoted) a new version of their insecure website. When it comes to user privacy, SSL is the elephant in the room.

Today at Toorcon 12 I announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.

Most of the coverage of Firesheep this week focused on the fact that using Facebook on an open wi-fi network in a coffee shop makes you prone to having your account broken into. That is true, and perhaps most the most common scenario, but the problem goes deeper than that. This can occur at any point where a third-party can intercept the communication between your browser and the web server: your home wireless router, your internet service provider, or even some types of local area networks. The real answer is to have the entire session — from the point when you log in to when you log out — encrypted. Google recently made this the default for GMail sessions, and some of the engineers involved in the effort published findings about how the SSL encryption overhead isn’t that bad. In the meantime, Network World has some options to consider to protect yourself a little bit from this kind of attack. (Hat tip to Dan Scott on Code4Lib IRC.)

Cory Doctorow on the Role of “Free”

The topic I leave my family and my desk to talk to people all over the world about is the risks to freedom arising from the failure of copyright giants to adapt to a world where it’s impossible to prevent copying. Because it is impossible. Despite 15 long years of the copyright wars, despite draconian laws and savage penalties, despite secret treaties and widespread censorship, despite millions spent on ill-advised copy-prevention tools, more copying takes place today than ever before.

As I’ve written here before, copying isn’t going to get harder, ever. Hard drives won’t magically get bulkier but hold fewer bits and cost more.

Networks won’t be harder to use. PCs won’t be slower. People won’t stop learning to type “Toy Story 3 bittorrent” into Google. Anyone who claims otherwise is selling something – generally some kind of unworkable magic anti-copying beans that they swear, this time, will really work.

Cory writes this piece in the U.K. Guardian in response to a column from a fellow Guardian writer on how creative people can control their own intellectual property and some media companies’ demands for digital rights management are actually stifling creativity. It starts as a rant and moves quickly into a powerful summary of what is at stake in the “copyright wars.” (Hat tip to OCLC’s Above the Fold.)

What Network Neutrality Really Means

In its continuing contract showdown with Cablevision, the News Corporation tried to extend its blackout of the Fox Broadcasting network to Fox.com and to Hulu, the popular Web site for free TV viewing, on Saturday. Angry Cablevision customers reported being unable to watch episodes of “Glee” and “House” on Hulu.

The blackout caused shock waves because it had not been done before by a programmer. Though the shutdown was brief, the message was unmistakable: do not expect to be able to watch Fox online unless you are paying for Fox on TV.

The attempted Web blockade was leverage for Fox in its contract negotiations, but more important, it was the latest evidence that entrenched media companies hope to replicate their walled gardens in a new medium, the Internet.

Broadcast and cable companies in the New York City area are locked in a dispute over what the latter needs to pay the former for the right to retransmit the content on cable TV. The dispute spilled over into the internet when the cable company started blocking internet subscribers from reaching the broadcast company’s shows on its website and on Hulu. This could be seen as a litmus test for net neutrality: should an internet service provider be able to decide what content it sends to end-users — either by giving preferential treatment to some content or by blocking other content? The dispute, by the way, continues…even impacting those who want to watch baseball’s World Series.

Week #2 of this new project to highlight interesting tidbits from the previous seven days. Well, things that were interesting to me that I hope will be interesting to DLTJ readers. Time will tell.

Technical Debt: A Perspective for Managers

What is Technical Debt? It’s all “those internal things that you choose not to do now, but which will impede future development if left undone” [Ward Cunningham]. On the surface the application looks to be of high quality and in good condition, but these problems are hidden underneath. QA may even tell you that the application has quality and few defects, but there is still debt. If this debt isn’t managed and reduced, the cost of writing/maintaining the code will eventually outweigh its value to customers.

Technical Debt is like a credit card that charges a high interest rate, just leaving the team with an outstanding balance cost. In this case, the costs are represented by time and effort needed to work around the problems. The longer the team takes to pay off the debt, the more interest is accumulated (in the form of additional workarounds) and the higher the costs for the business.

This definition of the amorphous stuff that gets in the way of moving faster really resonates with me.

A Case of Taking QR Codes to the Park

[Fort Smith Park Superintendent Bill Black] sat through a few conference sessions held by the Arkansas Parks and Tourism Department about information technology, where he heard about QR (or Quick Response) codes—which are two-dimensional bar codes that can be used in a variety of ways. A company can choose from any number of sites that will generate a QR code for free and put that code almost anywhere—on a website, a postcard, or even a T-shirt. Then smartphone users use the camera on their phones to scan the bar code—some phones have the scanning technology built in, but older iPhones and the like will have to download a free app—and are instantly taken to whatever content is linked to the bar code.

“On the drive home I got thinking about how it might work for interpretation purposes,” Black says, and he began to consider how this technology might be deployed to provide information to park visitors.

Econtent Magazine has this brief use case for QR Codes as a way to link to more information in a national park. Usage of QR Codes seem to be creeping up, helped in no small part by efforts at Google in its Favorite Places and URL Shortner services. They aren’t exactly common yet, but this is a place where libraries might get ahead of the game. There have been several experiments with QR Codes in OPACs and other services, for instance, and some great thinking about how they could be used. Is there an education role for libraries in helping patrons use this new technique for connecting to information?

WebP, a new image format for the Web

Most of the common image formats on the web today were established over a decade ago and are based on technology from around that time. Some engineers at Google decided to figure out if there was a way to further compress lossy images like JPEG to make them load faster, while still preserving quality and resolution. As part of this effort, we are releasing a developer preview of a new image format, WebP, that promises to significantly reduce the byte size of photos on the web, allowing web sites to load faster than before.

On the heels of the mention here last week of the bounty to add JPEG2000 support to Firefox comes this announcement from Google of a new image format for websites that is supposedly better than JPEG2000. Lots of buzz around this, but not much in the way of commitment to support it yet. I suppose the real test will be whether WebP will be supported in Firefox before JPEG2000…

General Counsel’s Role in Shoring Up Authentication Practices Used in Secure Communications

The major Internet browsers all currently use the Certificate Authority Trust Model to verify the identity of websites on behalf of end-users. (The Model involves third parties known as certificate authorities or “CAs” issuing digital certificates to browswers and website operators that enable the end-user’s computer to cryptographically prove that the same CA that issued a certificate to the browser also issued a certificate to the website). The CA Trust Model has recently come under fire by the information security community because of technical and institutional defects. Steve Schultze and Ed Felten, in previous posts here, have outlined the Model’s shortcomings and examined potential fixes. The vulernabilities are a big deal because of the potential for man-in-the-middle wiretap exploits as well as imposter website scams.

Is ‘https’ and ‘SSL’ as secure as you believe it is? These researchers point out that it is only as good as your trust in the Certificate Authorities to issue SSL certificates to the appropriate web site owners and to keep safe the secrets necessary to make ‘https’ work. Read this so that you have an informed sense of how secure your communications on the web actually are.

M.I.T. Weighs Charges for Online Lectures

The Massachusetts Institute of Technology has announced that it is considering charging for access to online lectures and class notes, which are currently available free on the Web. Speaking at the Organization for Economic Cooperation and Development’s Institutional Management in Higher Education conference in Paris this month, Lori Breslow, director of M.I.T.’s Teaching and Learning Laboratory, said that free access “may not be the best economic model, so we are now looking seriously at new e-learning opportunities.”

I only saw this brief mention of this in the New York Times. Were MIT seriously considering reversing its ground-breaking course to open up access to its lectures, I think there would be more talk. Maybe I missed other discussion, but if this turns out to be the case then the open courseware movement has been dealt a serious blow.

The WordPress Codex has documentation for running the login, registration, and administration interfaces on an SSL server. There is even a plug-in that will do much of the heavy lifting for you. I have found both of these methods, by themselves, to be rather unsatisfactory, though, in that admin services that rely on AJAX calls back to WordPress break (such as the periodic saving of drafts). What happens is this:

1. Plugins will use the ‘siteurl’ and/or ‘home’ values in the Options → General admin page, and that value is typically set to the “http://” rather than “https://” address of the blog.
2. The URL that plugins construct to talk back to the WordPress installation will go to an “http” address instead of the SSL-encrypted “https” address.
3. The admin page, loaded in the browser from the “https” address, attempts to talk back to the WordPress installation on a “http” address and triggers a exception. In Firefox, the error looks like this: Error: [Exception... "'Permission denied to call method XMLHttpRequest.open' when calling method: [nsIDOMEventListener::handleEvent]"...]

The security model in the browser prevents scripts on a page from using XMLHttpRequest¹ back to any host on the internet except for the host where the script came from. In this case, the difference between “http://…” and “https://…” is enough to trigger the problem.

So I fixed it with plug-in that uses an undocumented hook in WordPress 2.3. If a plugin requests the value of ‘siteurl’ or ‘home’, a filter is called to check if the requested page is on the SSL server. If it is, the filter changes the URL from ‘http’ to ‘https’. In that way, plug-ins will use the proper form of the URL.

< ?php
/*
Plugin Name: Fix Admin SSL
Plugin Script: fix_admin_ssl.php
Plugin URI: http://dltj.org/tag/fix_admin_ssl
Description: Fix the 'siteurl' and 'home' option values to make the protocol 'https' rather than 'http' when the page was requested with SSL.
Version: 1.0
License: GPL
Author: Peter Murray
Author URI: http://dltj.org/about
 
=== RELEASE NOTES ===
2008-02-18 - v1.0 - first version
*/
 
function fix_admin_ssl($url) {
  if ($_SERVER['HTTPS'] == 'on') {
    $url=preg_replace('/^http:\/\//','https://',$url);
  }
  return $url;
}
 
add_action ('option_siteurl', 'fix_admin_ssl', 1);
add_action ('option_home', 'fix_admin_ssl', 1);
 
?>

One downside to this plug-in, though, is that it will appear to change the values of ‘siteurl’ and ‘home’ on the Options → General admin page. The values in the database are still the ‘http’ ones, but since the Options page is an admin page the filter will run when it pre-loads those form fields.

If there is interest, I can package up the above code into a legitimate plugin and submit it to the WordPress plugins list.

Footnotes

1. See http://en.wikipedia.org/wiki/XMLHttpRequest for more information on XMLHttpRequest.

Okay — this seemed like a lot harder than it should have been. At the very least, it took piecing together information from a number of places in order to make it happen. The goal is to use a Go Daddy Turbo SSL Secure Certificate (the $19.95/year one) to secure an OpenLDAP server. On the surface, this shouldn’t be so hard. The tricky part comes because the requested SSL cert is not signed by a recognized Certificate Authority root; instead, Go Daddy uses an intermediary certificate and the tricky part is making sure the whole chain of SSL certificates line up properly. There is a wealth of documentation for using intermediary certificates with web servers, but I found very little for OpenLDAP servers. I hope by posting this into the blogosphere you will find it useful someday, too.

Environment

The Certificate

So go through the modestly convoluted process of generating the Certificate Signing Request (CSR), giving Go Daddy your $19.95, requesting the certificate, have the request approved by your DNS zone administrator, receive the e-mail of the signed certificate from Go Daddy, and then come back here.

OpenLDAP’s ‘slapd.conf’ Server Setup

First, one has to go to the Go Daddy Secure Certificate Services Repository. Many of the directions I found for getting the intermediary certificate working with web servers said to download the intermediate certificate alone (or, as Go Daddy calls it, the sf_issuing.crt file). I found this didn’t work — rather, the “Root Bundle” (or ca_bundle.crt file) is what is needed.

[Updated 20070904T1104 : It looks like Go Daddy changed their certificate chain last month. What you need now is called "gd_bundle.crt" from the Go Daddy certificate repository -- you'll find it under the heading "New Go Daddy Certificate Chain" (at least that is where you'll find it today).]

Then add this to your slapd.conf file:

TLSCipherSuite HIGH:MEDIUM:+SSLv2# Your signed CSR that you got back from Go DaddyTLSCertificateFile /etc/ssl/certs/ldap.ohiolink.crt# The private key file for the certificateTLSCertificateKeyFile /etc/ssl/certs/ldap.ohiolink.key# The "Root Bundle" file from Go Daddy's Certificates RepositoryTLSCACertificateFile /etc/ssl/certs/ca_bundle.crt

Next, move onto the client side. (Your LDAP server also has the client libraries installed — you’ll likely want to start there.)

OpenLDAP’s ‘ldap.conf’ Client Setup

So let’s start with OpenLDAP’s ldap.conf file; you’ll likely find this in the /etc/openldap directory. (At least that is where you’ll find it with Gentoo — YMMV.) In that file, you’ll want to put these pieces:
[code]
BASE dc=ohiolink,dc=edu
URI ldap://ldap.ohiolink.edu/
TLS_CACERTDIR /etc/ssl/certs
TLS_REQCERT demand
[/code]
You’ll, of course, want to replace the BASE and URI parameters with the ones most appropriate for your installation. I’ve found that third line to be somewhat unexpectedly important, however. The OpenLDAP libraries need to know where to go to find the trusted root certificates, and so you need to specify the path where they exist on your system. These got installed with OpenSSL, which you needed back in “The Certificate” stage when you generated the CSR. Again, these are in /etc/ssl/certs on a typically-configured Gentoo box; you might find them elsewhere in other distributions.

NSS/PAM’s ‘ldap.conf’ Client Setup

Testing

Conclusion

The text was modified to remove a link to http://gentoo-wiki.com/HOWTO_LDAPv3 on January 19th, 2011.

The text was modified to update a link from http://wiki.debian.org/OpenLDAPSetup to http://wiki.debian.org/LDAP/OpenLDAPSetup on January 19th, 2011.