Menu

PHP suhosin, sessions and shared SSL certificates

There’s a patch for PHP called suhosin which is part of the Hardened PHP Project to make PHP more secure. I came across an issue with the way session data is encrypted when using a shared SSL certificate on an old osCommerce install I occasionally have to support.

Note, this is not an issue with suhosin itself, but an issue with the way data is encrypted when using a shared SSL certificate.

sushosin session data encryption

When session data is written/read, sushosin encrypts/decrypts it using a variety of options as the encryption key. Read the configuration page for more details, specifically the Transparent Encryption Options section which also looks at the cookie options.

In particular, suhosin.session.cryptua and suhosin.session.cryptdocroot are enabled by default. There are no issues with the cryptua setting when it comes to shared SSL certificates, just with the cryptdocroot setting, and even then it won’t affect all hosting setups depending how shared hosting is configured.

Encrypting the session data is a good thing. Although I imagine it’s fairly trivial to decrypt it, at least it offers some immediate protection from someone just browsing the database or session files.

The issue with shared SSL certificates

If you have an SSL certificate specifically set up for your website with the same domain name, then there shouldn’t be any issues at all with the default settings, because all the variables to do with encryption won’t be affected. The document root will be the same regardless of whether it’s through SSL or not.

A shared SSL certificate, on the other hand, will most likely have a different document root with the non-SSL and SSL parts of the site. They may even be on different servers.

Let’s say the site we are looking at is www.example.com and the SSL portion of the site is at www.secure-example.com/example

The paths to these might be /var/www/example.com and /var/www/secure-example/example

As you can see the document root is different for each, which means the encryption/decryption key will be different for the SSL and non-SSL version of the site using the default settings.

The solution

All you need to do to fix this, is to disable the cryptdocroot option. This can be done in the suhosin configuration file, Apache virtualhost or .htaccess.

I prefer to just do this on a site-by-site basis so recommend doing it just in the .htaccess file. Add the following line to it, and then everything should work fine for new sessions:

php_value suhosin.session.cryptdocroot off

osCommerce notes

I mentioned I came across this issue with an osCommerce install, which is the only site I support which uses a shared certificate. For the sake of completeness, here’s the relevent osCommerce configuration to get cookies/sessions working across shared SSL, using the example domains above:

define('HTTP_SERVER', 'http://www.example.com');
define('HTTPS_SERVER', 'https://www.secure-example.com/example');
define('ENABLE_SSL', true);
define('HTTP_COOKIE_DOMAIN', 'example.com');
define('HTTPS_COOKIE_DOMAIN', 'www.secure-example.com');
define('HTTP_COOKIE_PATH', '/');
define('HTTPS_COOKIE_PATH', '/example');
Facebook Comments