Home

Drupalcon Security Followup: Automatically use SSL logins on drupal.org

Submitted by andrew on Fri, 03/06/2009 - 12:34
in

Today at the Advanced Security Drupalcon talk it was mentioned that drupal.org supports SSL access. Using user JavaScript, it becomes possible to modify the drupal.org login fields to use SSL. Here are the steps you need to ensure that logging in will use SSL automatically.

Step 1: Install the root CACert certificate

CACert provides free SSL certificates. Though they are very close to being included in Firefox, their certificate is not currently included by any mainstream browsers. In order to get your web browser to properly validate the certificate, you need to install the root CACert certificate. Go to the CACert certificate page and download the certificate. Firefox will ask to add the certificate, while Safari will download the file which can be opened with Keychain Access to make it available to the whole system.

Here is a direct link to the CACert root certificate.

Step 2: Install support for User JavaScripts

  • If you're using Firefox, install GreaseMonkey.
  • If you're using Safari, install GreaseKit.
  • For Opera, it's built-in.
  • For IE, as far as I know you can't do it. Switch to one of the above browsers.

Step 3: Download the user script

Download the user script and install it. Both GreaseMonkey and GreaseKit should ask to install it automatically. By default, it will enable itself for drupal.org and groups.drupal.org.

Step 4: Log in!

Note that groups.drupal.org uses the same certificate as drupal.org, so it will require accepting the certificate manually when you log in. Note that after logging in, you will be redirected back to the unencrypted version of the page.

Feel free to post any suggestions or improvements in the comments!

Related Links: 
GreaseMonkey
Related Links: 
GreaseKit

Comments

Still unsecure

Submitted by Mikkel Høgh (not verified) on Sat, 03/07/2009 - 05:46.

Well, SSL is a good thing, but when you only use it for the actual login, you have actually accomplished very little, since a would be eavesdropper can still just grab your session cookie from the first regular HTTP request and use that to steal your account.

So although this approach will protect the actual password, it doesn't help session hijacking. For that, we will have to serve up every single non-anonymous pageview via SSL. And that's currently not feasible.

Alas, this isn't going to

Submitted by christefano (not verified) on Sun, 03/08/2009 - 00:33.

Alas, this isn't going to work. It's a different approach from my own (I wrote a Firefox extension last year) and an interesting one at that, but Heine has already written the definitive post on this, Security theater #1 - Using SSL for login.

Yes, session hijacking is

Submitted by andrew on Sun, 03/08/2009 - 21:15.

Yes, session hijacking is still a problem. I'd hoped to write an updated version which would also force subsequent page loads to occur over SSL, but if there's concerns about d.o performance then perhaps I'll hold off. Perhaps the next conference WiFi will use WPA to at least make it more difficult for traffic sniffing to occur.

Thanks for your comments!