Get an SSL certificate to guard against FireSheep

A recently published Firefox add-in named “Firesheep” can be used by “hackers” to easily hijack the connection of any nearby WiFi users visiting many popular Web sites such as Facebook, Twitter, or Hotmail. This vulnerability is a basic artifact of the way the Internet works. In order to prevent this problem, these sites will need to properly implement SSL (https) security.

If you are running a WordPress blog on our servers, your private administrator login connection is also vulnerable to hackers using programs like Firesheep if you don’t use SSL security.

The solution is to this is to install an SSL certificate on your Web site. We discussed this in a blog post titled “Protect your WordPress login” back in May. Please be sure you’ve read it if you have a blog on our servers. The availability of Firesheep makes things easier than ever for hackers, so be sure to protect your blog.

This security recommendation also applies to other types of software that you might install on our servers, such as forum software.

We sell SSL certificates for a very low price — much less than it would cost you in terms of time to recover from any successful hacker attack.

8 Comments

  1. Why do anything in the clear anymore? Isn’t Firesheep a great message? It’s let everyone know
    to encrypt everything. For https, once the connection’s made via https, there’s not a lot
    of extra cpu overhead, right?

    Also for hotspots I see that the recommendation is to use WPA2 and broadcast the password
    in the SSID. (for an open hostspot of course)

    Is there any upside to using http? Is there any downside to https?

  2. R.H. wrote:

    >Is there any upside to using http? Is there any downside to https?

    We think everyone should use https. We use it for all our internal processes, for example.

    The downside is that it costs money and adds hassle. We’re trying hard to change that with inexpensive and easy SSL ordering for our customers, but it’s still harder than doing nothing, unfortunately.

  3. I’ve done some reading on self-signed certs as it pertains to a web-hosted, shared-ip environment but I
    still am not clear on why a dedicated ip is required.

    Is it a requirement to have a dedicated IP only because a self-signed cert is always untrusted
    and therefore causes the browser to assert there’s a problem with the cert? Or is there more
    to it?

  4. SSL certificates always require a dedicated IP address because that’s how the Web server chooses which SSL certificate to present to the visitor. It actually doesn’t matter whether they’re self-signed or not.

    If you think of how a non-SSL connection works, the client connects and sends an HTTP request that includes the hostname. Then the Web server looks at the hostname and then decides which “site” the client wanted.

    With SSL, the server needs to choose which SSL certificate to use when a client connects. You might think that it could use the same method: look at the hostname the client sends, then pick the matching certificate to use. However, that won’t work, because the server has to choose the certificate before the client sends any part of the request (otherwise the request data — think credit card numbers — wouldn’t be encrypted). The only way to choose a certificate without knowing a hostname is to assign each unique SSL-secured hostname a dedicated IP address. When a client connects to a certain IP address, the server can map that to a particular certificate, even before the client sends a single byte.

    The Apache SSL documentation explains this a different way if it still doesn’t make sense.

    A more recent technology called Server Name Indication (SNI) promises to eventually end this problem; it allows clients to send the hostname in encrypted form as part of the SSL negotiation, meaning it’s possible to host multiple SSL sites on a shared IP address. Unfortunately, SNI is a (relatively) new technology that doesn’t work in older browsers — for example, it doesn’t work when connecting from Internet Explorer 6, or from Internet Explorer 7 on Windows XP, both of which are still common enough that it isn’t reasonable to start using SNI on the server end yet. Give it a few years, though….

  5. This makes sense. Following the link to apache-ssl it describes a work-around.
    Would it be possible to do this:

    Two sites use 4.3.2.1

    sitea.com
    siteb.com

    Could siteb.com have SSL on port 30001? While sitea.com would be unchanged and unaffected
    If I understood that apache-ssl page they are suggesting that it would work.

    And it seems that SNI is an all-clients-must-support-or-will-not-implement feature.
    Which would mean that all browsers connecting to 4.3.2.1 must handle SNI.

  6. R.H. wrote:

    >Could siteb.com have SSL on port 30001?

    Sure, that works on a technical level, too, because the Web server can match the certificate based on the combination of IP address and port.

    But on a practical level for most sites, people avoid it. It’s easier to be able to simply add an “s” to the “http” and have it work securely, without messing with port numbers. When you add port numbers, you have to worry about things like “will my site be blocked from hotels that have a firewall that only allows ports 80 and 443?” Such problems are all too common.

    >And it seems that SNI is an all-clients-must-support-or-will-not-implement feature.

    Yes, exactly. That’s why even though all current browsers have supported it for a couple of years, sites aren’t routinely relying on it yet. But 5 years from now, very few visitors will be using MSIE 6 or Windows XP, and many people will consider it reasonable to deploy.

    (Even now, if a site is accessed securely by only a small number of people — think employees who are issued work computers where the employer controls the browser — SNI may be practical for some.)

  7. Amazing how many still use IE6.

    >(Even now, if a site is accessed securely by only a small number of people — think employees who are issued work computers where the employer controls the browser — SNI may be practical for some.)

    But if the ip is shared by another site then SNI wouldn’t work, but a company site would not, typically, share an ip.

  8. >but a company site would not, typically, share an ip.

    Oh, I wouldn’t say that. We host thousands of sites for companies on shared IP addresses.

    They tend to be smaller companies that don’t have their own IT infrastructure, but some of their employees use scripts on our servers that require passwords. They could definitely benefit from SSL certificates.