I have seen many detailed discussions for security on drupal.org and elsewhere. If I've learned anything watching the 2014 onslaught of cyber attacks it is this: "make it simple or it won't be used." I'm a system builder, trying to add SSL to a site (I've done this in the past.) and the challenge I face is a simple, current, best practice approach for SSL that provides decent performance (ie. allows proxy traffic, opcache, etc.)
I have tried to use both securelogin and securepages. both are beta at best and the latter requires drupal core patches on upgrades. Well, people are not going to do that. Is there a good, basic solution for protecting forms and authenticated traffic? Can we get the docs updated to reflect that?
Not sure if this is the right venue for this discussion, but I want to see Drupal Succeed and sometimes a different perspective can help.
Comments
SSL for the whole site by
SSL for the whole site by default (ie, HTTPS only) is an option, and the easiest of the ones you mention. It is also probably the best option moving forward.
If you read the Secure Pages issues about Beta status, it is staying that way because it requires two core patches. Those two patches are held up by the Backport Policy. I have clients using Secure Pages on their sites w/o problems with those patches, and have done so for a long time.
I'd agree that all-HTTPS for
I'd agree that all-HTTPS for the site is by far the preferred option if possible. It's not that hard - adjust .htaccess or your vhost to redirect all requests to https.
In settings.php set:
ini_set('session.cookie_secure', TRUE);Secure Pages and the like are at best bandaids that prevent submission of clear-text passwords, but they introduce a lot of possible complexity and the need to support mixed-mode sessions can lead to additional vulnerabilities.
What about performance
My (simplistic) understanding is that directing all traffic to SSL for a site will compromise performance (opcache, memcache, boost, etc.) This site is not getting much traffic, but I understand the penalty is large. Considering cloudflare as they just started allowing free SSL traffic.
Nonetheless the securepages route and having to manage core patches is possibly making big assumptions about the user base (which I'm also doing right now :)
BTW - there are also dozens of suggestions on how to route via SSL.
I did this (my cert is for xxxxx.com not www.xxxxx.com):
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
I also ran into trouble with insecure content and added this:
Header set Access-Control-Allow-Origin "*"
If this is best practice, should I (or someone more competent:) update the docs?
Performance is becoming less
Performance is becoming less of an issue now with faster servers. Total https is the way to go if you think google ranking is important. See http://googlewebmastercentral.blogspot.co.uk/2014/08/https-as-ranking-si...
I think you are confused. SSL
I think you are confused.
SSL has no effect on opcode cache or memcache, unless you are thinking that serving SSL pages via Apache httpd on the same server as everything else will mean httpd needs more memory and you'd have to cut PHP and memcache memory?
I doubt the difference will matter if you were going to do mixed-mode as an alternative.
As a side note, here's what I put in settings.php for Drupal 6:
$is_https = isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on';
if ($is_https) {
// Force session cookie over HTTPS only.
ini_set('session.cookie_secure', 1);
}
// Don't let JS access the session cookie.
ini_set('session.cookie_httponly', 1);
and in htaccess:
RewriteCond %{HTTP_HOST} www.example.org$ [NC]RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://www.example.org/1ドル [L,R=301]
Performance shouldn't be an issue anymore
Use a real cert.
We have an shared server using an 80.conf that redirects traffic to https configured via the 443.conf.
Everything in drupal installs just stays the same. The standard .htaccess doesn't need changes... Saves on upgrade memory lapses too.
Sorry for typos... Using a tablet.