HTTPS Encryption

Encryption on the web has a history of being notoriously expensive, and difficult to implement.  Not long ago, you could expect to pay upwards of $1,000 per year to register your website’s SSL certificate with the root server Verisign directly.  A shorter time ago, a few re-sellers such as Godaddy came into play.  As of the date of this article, one year for Godaddy’s SSL service will cost $69.99 for one website.

While I would have loved to have had a “valid” certificate, for some of my purposes, a snake oil certificate, or self-signed certificate, was secure enough.  Since self-signed certificates aren’t validated by a Certificate Authority (CA), modern browsers will try to prevent users from navigating to websites that use them (or any other non-validated certificate).

Now, since I created the certificates on my own server — I hope I can trust myself, I can ignore those messages in that case just fine.  This was useful for securing dev websites and code repository connections.  Anything public facing, this wouldn’t really be acceptable.

I tried an application called NetDrive a few years earlier with some success in 2010, then a few years later I came across OwnCloud.  This package was a decent competitor to Dropbox itself, so I decided to give it a shot.  With anything involving logging in and transferring files, it’s a good idea to use HTTPS, so I initially started with my usual self-signed certificate.

Unfortunately if I wanted to link any of the pictures I uploaded to there, anyone clicking on them will see a larger warning message.

This gave me a few choices:

1. Chance not using encryption
2. Use SFTP to handle the file transfers
3. Search out cheap certificate authorities.

This search eventually led me to StartCom StartSSL, who offered free SSL certificates, it seemed almost too good to be true!  Sure enough I signed up, validated the domains that I wanted to set up HTTPS, and I was on my way.  There weren’t many extra steps to this process verses using a self-signed certificate, it’s mostly just the fact that a third party validates your self-signed certificate.  So after getting everything in the correct directories, and updating my Apache config files, I was online.

Fast forward a couple of years, and there is a new player in town, Let’s Encrypt.  These guys caught my attention a few months ago on the tech news article circuit, and a CommitStrip comic.  It requires you download a script onto your web server, run it, tell it which domains you want to set up HTTPS for… and you’re done.  I didn’t believe it at all until I tried it for myself.  An odd catch, the certificates it generates are good for 3 months, instead of 12 months.  It comes with the option to have it run nightly to renew them, so it’s mostly a moot point.  I haven’t gotten to the point where any have expired yet, so I may have to add a followup.

Browser encryption has come a long way has come a long way, and it’s almost at the point where it’s just as easy to have HTTPS as it is to have standard HTTP.

URL Rewriting (Part 2)

I’ve written some very basic URL rewriting scripts in the past.  With only a few URL parameters this is pretty simple to accomplish with a few lines of code.

For example, I had written a basic CMS where URLs followed a specific pattern using .htaccess scripting.  The rewrite engine would be able to convert this into something Apache can read.

• The URL bar would read as follows:
  • http://www.domain.com/category-x/article-y
• The web server would read this as:
  • http://www.domain.com?category=category-x&article=article-y

This is fine enough for basic URL patterns, but what happens when the URL tree is a little more complicated?  Starting in Joomla! version 1.5, they included a build in router that can be created on a component level.

Used Boats Ahoy! was created before this was available, so I continued to use the module JoomSEF from part one of this article.  Fortunately the scripting required for JoomSEF to work properly with a component followed a number of the rules the built in 1.5 router uses.  Unfortunately, JoomSEF only required instructions to generate the URLs and not to be able to return the URL to a form the web server understands, which is much more difficult.   Also, moving away from the original method meant a number of the URLs would no longer be valid which requires an extra layer of error handling.

URL Rewriting (Part 1)

URL rewriting is a process I’ve been using on a number of websites for a long time.  Modern CMS solutions have various built in functions and plugins to make this simple for anything that you might download and try out of the box.  What is under the hood is much less straight forward.

In older versions of Joomla!, my go-to was a plugin called joomSEF.  If all of the links are formatted correctly, this plugin will convert standard php links into more user-friendly style links.  What is happening under the hood?  Well first when the page loads, all of the links that are formatted in a way that Joomla! understands are read, then matched against the database for all of the user-friendly URLs that have been generated.  If the matches are found, the user-friendly URLs will be displayed on the page.  If the match is not found, then the plugin will generate it then insert the record into the database.

While this process is fine for websites with small to medium number of links, any kind of text matching in the database is a very resource intensive process.  One of my websites eventually had to be moved to a VPS server because of this.  By the time it was deactivated, this website alone had 1,872,945 records to search through in a table reaching upwards of a gigabyte.  I needed to actively prune unused records every so often by looking to see which URLs have been unused.