Enabling HTTP Secure (HTTPS)

Last updated November 5, 2012. Created by JacobSingh on November 11, 2009.
Edited by Ralt, cdnsteve, JimSmith, Ostasevich. Log in to edit this page.

HTTPS is a protocol which encrypts HTTP requests and their responses. This ensures that if someone were able to compromise the network between your computer and the server you are requesting from, they would not be able to listen in or tamper with the communications.

When you visit a site via HTTPS the URL looks like this: https://drupal.org/user/login. When you visit a site via plain (unencrypted) HTTP, it looks like this: http://drupal.org/user/login.

Why is it important to you (and when)

HTTPS is typically used in situations where a user would send sensitive information to a website and interception of that information would be a problem. Commonly this means:

• Credit cards
• Sensitive cookies such as PHP session cookies
• Passwords and Usernames
• Identifiable information (Social Security number, State ID numbers, etc)
• Confidential content

Especially in situations where you as the administrator are sending your Drupal password, or the FTP password for your server, you should use HTTPS whenever possible to reduce the risk of compromising your web site.

HTTPS can also prevent eavesdroppers from obtaining your authenticated session key, which is a cookie sent from your browser with each request to the site, and using it to impersonate you. For example, an attacker may gain administrative access to the site if you are a site administrator accessing the site via HTTP rather than HTTPS. This is known as session hijacking and can be accomplished with tools such as Firesheep.

Security is a balance. Serving HTTPS traffic costs more in resources than HTTP requests (both for the server and web browser) and because of this you may wish to use mixed HTTP/HTTPS where the site owner can decide which pages or users should use HTTPS.

How to enable HTTPS support in Drupal

Web server configuration

1. Get a certificate. many hosting providers set these up for you - either automatically or for a fee. Simply ask your hosting provider. If you want to secure a test site, you could instead generate a self-signed certificate.
2. Configure your web server. A few helpful links:
   • Apache instructions.
   • Ubuntu instruction
   • MAMP instructions
   • WAMP instructions
   • EngineX (Nginx) instructions
   • Barracuda/Octopus/Aegir instructions

   Chances are, your webhost can do this for you if you are using shared or managed hosting.

Note: Clean URL's If you're using Apache for HTTP and HTTPS:

You will probably have two different VirtualHost buckets.

1. A bucket for port :80 http
2. A bucket for port :443 https

Each of these VirtualHost containers or buckets, require that a specific Apache directive be added within them if you're using Clean URL's. The reason for this is that Drupal makes extensive use of .htaccess and mod_rewrite to provide friendly URL's.

Ensure you have the following within the directive, which is a child under the VirtualHost container: See Apache Documentation for AllowOverride

This means that your .htaccess takes precedence and that the Apache configuration will allow it to run as you would expect for Drupal.

Troubleshooting:
If you enabled HTTPS and it only works on the homepage and your sub links are broken, it's because the VirtualHost:443 bucket needs AllowOverride All enabled so URL's can be rewritten while in HTTPS mode.

Drupal configuration

• If you want to support mixed-mode HTTPS and HTTP sessions open up sites/default/settings.php and add $conf['https'] = TRUE;. This enables you use the same session over HTTP and HTTPS both -- but with two cookies where the HTTPS cookie is sent over HTTPS only. You will need to use contributed modules like securepages to do anything useful with this mode, like submitting forms over HTTPS and so on. While your HTTP cookie is still vulnerable to all usual attacks, a hijacked insecure session cookie can only be used to gain authenticated access to the HTTP site. It will not be valid on the HTTPS site. Whether this is a problem or not depends on the needs of your site and the various module configurations. For example, if all forms are set to go through HTTPS and your visitors can see the same information as logged in users then this is not a problem.

• For even better security, leave $conf['https'] at the default value (FALSE) and send all authenticated traffic through HTTPS and use HTTP for anonymous sessions. Once again contributed modules like 443 Session or Secure Login can help you here. Drupal 7 automatically enables the session.cookie_secure PHP configuration on HTTPS sites, which causes SSL-only secure session cookies to be issued to the browser.

• For best-possible security, setup your site to only use HTTPS, not even responding to HTTP with a redirect. HTTPS is vulnerable to man-in-the-middle attacks if the connection starts out as a HTTP connection before being redirected to HTTPS. $conf['https'] can be left at its default value (FALSE) on pure-HTTPS sites. You can run the HTTP site from a different server and simply deliver a plain text message telling your users to use HTTPS.