I recently moved my WordPress installation to an “https://” address, that is, I now route all traffic (except the user’s first visit to a page) over a Secure Sockets Layer (SSL). As the title of this blog posting suggests, the upgrade was maddening. I encountered a “too-many-redirects” error, which turns out to be a bug in WordPress 3.0.2. and probably other recent builds. Readers more interested in how I dealt with this problem should skip to the section entitled My experience with SSL, below. As will be seen, although I succeeded, I was not able to find a general solution to the problem. Those want to read more generally about my decision to use SSL connections should start at the section immediately below and continue to read until the end.
Context: Baaa! Baaa! Firesheep
When Firesheep was released, I checked whether administrative interfaces to the various online services I use really were secure. A few months ago I strengthened all of my passwords. When the AMNH put my laptop on their network, their IT department required that I install anti-virus software. Mac users like to brag that there are no malware threats to OS X. I am certain that’s false; moreover, it’s only a matter of time before they become common. As well, Mac users ought to detect and eliminate Windows malware they receive from the latter, so as not to pass them on. The release of Firesheep motivated me to take this last step of securing online connections to sites or services requiring a login. I poked around online to see what the best strategies were, and I concluded that I ought to upgrade my web service so that it could host SSL connections. As it turns out, all of the web applications I use are secure, including TMDA administration, Qmail administration, the various webmail clients and online financial and shopping sites I use. I don’t use Facebook (*gasp!*). Twitter, to its credit, offers the option to route all traffic through an SSL connection. Most of all, I wanted to secure administrative access to my WordPress installation. I am pretty sure that the stock installation is set up so that the administrator logins and administration functions are carried out in clear text. I can’t check, however, because I have succeeded in securing my site. 🙂
The central lesson that people should have learned from Firesheep is that securing login interfaces is not enough. This point comes across clearly on Firesheep’s web page. The login information is encrypted when the user first logs in, but if the pages of the administrative interface are not also encrypted, passwords transmitted when using the interface are open to snooping. Users are warned that they are most vulnerable when using unsecured public networks, such as those found in coffee shops or other Internet hot spots. My impression is that most of the discussion presupposed that people had already secured their home networks using some form of WPA encryption and that, if the hot spot network is secured that way, a user should consider him- or her-self safe. I hope that’s true. There is some risk; it appears that the aircrack-ng tools can crack some forms of WPA encryption.
While an unsecured coffee shop or hot spot network are indeed particularly fertile fields for harvesting other peoples’ data, a cable does not provide security by itself. On the one hand, unsecured wifi signals pervade the environment, and almost every laptop has a wifi adapter capable of receiving these signals; on the other hand, tapping a router takes more effort and expertise. Nonetheless, the serious data thief most probably has the time and knowledge required. This would yield a high return on investment for someone who succeeds at it. As well, mistakes and malfeasance alike in system design can expose traffic at a particular site or traffic routed through a particular ISP to unwanted listening. The Internet is a world with virtual addresses, and it requires virtual security, not physical security.
Someone using his or her organization’s network can be protected by a VPN; if the internal network is secure, connections made using the VPN are too. This does not solve the problem of security at sites like Facebook. Since they are not on the secured network, they do not benefit from it.
I was unable to find information about any serious disadvantages of SSL, except cost and performance. SSL is only useful when used as a part of a larger infrastructure that incorporates trusted authorities, such as Verisign or Blah, that can attest to the identity of SSL certificate holders. This requires a subscription to some such service. As a means of securing Internet communications, so much as I can tell, it is adequate for communicating about the most delicate, private matters, including medical records, and personal and institutional finance.
For perspective, consider that even one of the strongest forms of encryption, RSA encryption, can be broken relatively quickly. A quantum computer is required for this, so probably only governments or multinational corporations will be able to make use of this method. This being the case, it’s more likely that the unwelcome will find a way to private data due, not to decryption by outsiders, but because security utilities are incorrectly configured, implemented poorly, out of date, or not used at all.
“Who wants my data?”
In case they’re not clear, it’s important to mention the reasons why site security is important. One response I often hear when discussing the quality of passwords or the need for secure connections is, “Why should I care? Who wants my information? So what if someone reads my email; that person won’t know me or any of the people I correspond with.” The person extends this kind of thinking to his or her entire hard disk and online services.
Well, there are plenty of people that would like to get their hands on everyone’s data. Witness the amount of malware designed to extract information from, and push advertisements to users of MS Windows. True, it’s unlikely that a government agency or a stalker is targeting you in particular, but spammers and identity thieves target everyone at once. Some people’s unsecured computers become zombies, or have keyloggers installed on them. With login and password information obtained in these ways, a human malefactor can access to systems you use, such as your email service or web host, to cause further damage to other people or institutions online. ISP’s are particularly at risk.
For evidence of this, look at the logs on your machine that record attempts to contact your computer online. The robot minions of spammers and thieves systematically visit every Internet address. Should your machine begin to share information with one of these robots, the robot will listen and explore for a way to make closer contact. I find many thousands of such attempts recorded in my logs in Console.app. I have my network interface set to “stealth mode,” so my machine does not acknowledge any of these not-so-friendly visits.
If you insist on using “12345” or “login” or “password” as your login, and ignore security precautions on your own machines and the web services you use, think of the rest of us, who do not want to suffer from your carelessness and lax attitude.
What’s probably more important than the behavior of individuals is that service providers at all levels of the Internet architecture pay as much attention to security as they do to designing new user tools and site design. This is an endeavor at which WordPress, sadly, has failed. I adduce the difficulty of configuring a WordPress site for SSL as evidence of this.
My experience with SSL
Realizing that connections made over SSL are indeed quite secure, and that the cost for a single site address fits neatly into my budget, and that only minimal effort is required to set up the connection with my ISP, I went ahead with it. At my ISP’s advice, I signed up with Goddady, which appears to be the cheapest available. Kitschy site design and its founder’s cult of personality notwithstanding, it was easy to get the service up and running quickly, and also to correct mistakes I made along the way in generating keys and certificate signing requests (“csr’s”). I was not prepared for what came next, configuring my WordPress blog to run its administrative interface over the SSL layer.
My WordPress installation is hosted at geekisp.com (an excellent service and highly recommended!); I keep it up to date, and have a minimum of plug-ins. WordPress has a reputation for excellent documentation; I found instructions about how to modify my wp-config.php file in order to force all login and administrative connections to use SSL.
I inserted this line into the file—and this rendered the blog totally inaccessible. Gulp. The problem is a “too many redirections” error. This is particularly bad because the administration pages cannot be loaded due to this error. I edited my wp-config.php file on the server and my blog came back to life, but still in unsecured form.
Googling desperately, I discovered that these kinds of errors started to appear in WordPress versions circa 2.6. It is a WordPress bug. I found links to solutions at enlightened webmastery, in a WordPress discussion forum, none of which worked for me. There is a plug-in that disables WordPress’ redirection mechanism. This didn’t solve the problem for me, and in any case, I think that disabling the redirection mechanism is probably a bad idea, since I don’t know what it really does, and it sounds important, which is probably explained by its creator, Mark Jaquith. Some people modified their .htaccess files. This sounds to me like a relatively low-risk strategy, but I wouldn’t have tried it without consulting with geekisp support first. I also found a particularly depressing exchange in the WordPress support forum. It consists of one question and one response, which is “I am having the same problem. Have you gotten any help with this? I can’t even find a lot of info on it anywhere on the web at all.” The thread is now closed.
The solution to the problem was to add
$_SERVER[‘HTTP_HOST’] = ‘shiftingbalance.org’;
to my wp-config.php file.
Unfortunately, I cannot recall where I found this solution online, although I think it is essentially the same as the solution in the WordPress discussion forum mentioned above.
I also use the wordpress-https plugin, setting only “Internal HTTPS Elements,” described by “Force internal elements to HTTPS when viewing a secure page.” It is not clear to me whether this has any effect, but with it selected, connections are via SSL. If I select “HTTPS Front Page,” the redirect error occurs. This option is described as “Force internal elements to HTTPS when viewing a secure page.”
Another way to generate the redirection error is to select “Force SSL,” an option in the “Publish” section of the post editing interface. In principle, this option will force an SSL connection for the page. Specifying this for each page might be useful, because the wordpress-https plugin provides a way to prevent pages that do not have this option set from loading over SSL. I can imagine some application that interferes with SSL, so that it might be reasonable to disable that page’s transmission via SSL.
After restoring my site, there were still holes in the SSL connections, that is, pages that loaded some unsecured elements. Most of the administration pages were not secure. On the advice of others online, I conjectured that some plug-in was at fault. The WordPress.com Stats plug-in is not secure; nor is the use of “Gravatars.” Once these were disabled, my connection was secure over every login and administration page; pages visible to the user are also encrypted, although https://shiftingbalance.org does not redirect browsers to https://shiftingbalance.org. Maybe this is a matter for my .htaccess file. Any page accessed from the unsecured front page is loaded over the secure connection. I think that all pages should be secured. People that want to comment should not have to have their email address and other identity information transmitted in clear text. The WordPress Stats plug-in can be made to work—partly—with the SSL connections by using the HTTPS stats fix plug-in. The administration pages are completely secure, if the stats fix plug-in is used; but postings and pages are not. The browser will report that there are unsecured items on the page.
If you want to secure your WordPress installation, be prepared for agony. I hope I can save someone the trouble of searching for errors or incompatibilities among widgets and plug-ins by pointing out that this a WordPress bug. Unfortunately, I cannot do anything more than offer my sympathy and best wishes in advance of what seems for now to be the only “solution” to this problem: find something that works for you.
Et tu, WordPress?
WordPress is rightly proud of its architecture and reliability. There are a few oddities, for instance, a plug-in’s “control panels” cannot be accessed by way of its entry in the list of available plug-ins. Nonetheless, the interface for day-to-day work—creating and editing blog posts and “pages”—is admirably simple, and almost foolproof. Though it is, as I mentioned above, well-documented, it’s rarely necessary to consult the manual because the self-documentation of each page is almost totally transparent.
Despite all this, there are some idiosyncrasies, quite out of character with the kind of thoughtful design and good programming described in the previous paragraph. The WordPress administration interface is apparently designed for avoiding SSL encryption. The first problem is that, unlike the plug-in and widget architecture, there is no natural, intuitive way to onfigure WordPress’ administrative functions for SSL. If it really is just a matter of adding a single line to the wp-config file, why not have a separate menu item in the administrative interface “Security,” with a single check-box or giant button, on the model of Apple’s Time Machine, that is marked “SSL security on.” Choosing this option would modify the wp-config file, or perhaps create a file wp-ssl, whose only line turns on the ssl connections. This file would be ready by a function call in wp-config; choosing the secure option would not, therefore, result in changing wp-config. Maybe changing that file is what WordPress engineers want to avoid. I have no idea.
A second curiosity is that, in addition to providing an option for routing all administrator information over SSL, WordPress provides an option for routing logins, but not other administration traffic, over SSL. I have mentioned this above as an example of a breach of security. This is analogous to a contractor suggesting that he or she build a client’s house with a reinforced door and deadbolt locks, but with windows that cannot be locked.
There are two more serious oversights that, unfortunately, result in rendering some of what could be some of WordPress’ most useful features inoperable, unless the absolutely disastrous practice of using a totally unsecured connection is engaged in. The automatic upgrade function requires a vanilla ftp connection (as opposed to sftp or some other secured connection). When I saw this, I double-checked with geekisp support, who said that this tactic is commonly used as a way of simplifying transfers and upgrades—neither the user nor the application are required to deal with passwords, login names, or changes in protocol. Similarly, uploading video, images, or other documents for display in WordPress blog postings or for downloading requires an unsecured transfer.
I still cannot believe that this “feature” is incorporated into WordPress. When I need to upgrade, upload a document, or install a new plug-in, I check the page with the “automatic” option as though my past experience with it were in some way unreliable. I am pretty sure that, with the exception of anonymous connections to public-access repositories, I have never in my life used a plain-vanilla ftp link. Not that my life as a computer user has been particularly long; but I do remember that, in my sophomore year in college, in my training as a student computer lab assistant at UC Santa Cruz, being forcefully urged to use secure transfer options, plain ftp being a relic of a naive age before the WWW when all Internet users knew one another and they were each three degrees of separation from either Richard Stallman or Donald Knuth. WordPress has rather chosen this way of reckless madness, totally irresponsible, all the more so, since this user-friendly feature is directed at those who don’t want to tinker with the guts of their WordPress installations and who probably won’t know that unsecured transfers are anathema.
The too-many-redirections bug introduced in later versions of the software is of a piece with the kinds of shortcuts around security I’ve described above. The sine qua non for the release of a new version of WordPress ought to be that it can be completely secure. Updates are for plugging security holes, not for blowing site security wide open.