Mapping privilege separation on non-SSL/SSL

Sorry, I'm new here. Is this area for "voting"? If so... I would like this feature. Also apparently lots of others would too. Just search for "https login page" or "ssl login page" and notice all the discussion activity in this area.

SSL for admin is also an excellent idea, but IMHO the main thing there I want encrypted is the user passwords and an SSL login page will provide a work-around for that.

I'd agree this would be a very useful addition. I have used apache redirects to force certain paths to use https:// as the $base_url, but I've noticed issues with some modules when the $base_url varies between http:// and https:// -- e.g. the module cannot get a drupal path from the referer_uri() because a different $base_url was in effect on the previous page.

See bugzilla as an example of a web app with an option to force SSL for user logins.

changed version.

http://drupal.org/node/53618 was marked duplicate of this

http://drupal.org/node/55785 was marked dupe. I copied the patch in that issue here.

what stops this being a contrib module?

Just adding a comment to subscribe to this thread since that's my patch.

chx: what stops this being a contrib module?

http://drupal.org/node/65632

Doesn't apply.

See http://drupal.org/node/37932 too (long forum post).

I haven't found anything so far that wound allow Drupal 5.x to redirect a login request to SSL, so I made a quick (and dirty) hack to user.module :

- adds a "Secure Login" entry in the admin pages, with a checkbox to activate SSL logins and a field to submit the https version of the site's base_url (no automatic grabbing so far)
- if SSL login is activated, prefixes the target URL with the https base_url when login is submitted

That's all (which means in particular that changing a user's password through the user profile page isn't redirected).

The patch can be found here, no warranty implied, blah blah blah. Again, this is for 5.x ONLY, this problem in 4.7.x can adequately be addressed via Apache redirection.

@bozo: Sorry, but new feature patches will never be commited for existing releases - Drupal 5 in this case. I'd be happy to see basic SSL support in Drupal core though.

I didn't really mean it as a feature patch (the code would most certainly need some serious review!), it's rather a small workaround.

I shouldn't have posted it in an issue thread, though, my mistake.

subscribing. interested in adding this for /admin access.

subscribing

The way I did it.

Edit file modules/user/user.module

For the login block. In the function user_login_block replace the following line:

'#action' => url($_GET['q'], drupal_get_destination()),

with

'#action' => preg_replace('/^http/', 'https', url($_GET['q'], drupal_get_destination(), null, true)),

That's it for the login block to send its data over SSL.

For the user login page modify the function user_login and add the following code before the return line:

Correction to my previous post.

The lines should be like:

to avoid getting urls starting with 'httpss' if you already are in ssl.

subscribing

Subscribing.

Ref. my (new) suggestion and others' relevant concerns in the discussion in this duplicate (closed) issue:
http://drupal.org/node/13240#comment-325295

FYI - This issue is also (again) brought up in discussing the next release:

"Drupal 6 usability suggestions":
http://drupal.org/node/141043#comment-229103

Many people are concerned about this. I really hope we can make a better-than-nothing solution for this.

http://drupal.org/project/securepages

After a brief talk with chx, I decided to reopen this issue. Logging in over SSL is something that is security-critical and that way too few websites use. Inclusion in core (possibly with the option to use an "SSL proxy" like it is offered for many shared hosts) could therefore enhance security.

After a brief talk with chx, I decided to reopen this issue. Logging in over SSL is something that is security-critical and that way too few websites use. Inclusion in core (possibly with the option to use an "SSL proxy" like it is offered for many shared hosts) could therefore enhance security.

A related issue I'd like to fix in d7: http://drupal.org/node/170310
Recent versions of drupal make PHP's session.cookie_secure setting difficult to implement (if you use the same hostname for your SSL and non-SSL sites), because they force these sites to use the same session name. If a logged-in user goes back to the non-SSL site, their SSL session cookie will be overwritten and they'll have to login again. This was easily implemented in the past by using different session names for the different sites, but drupal core no longer allows the session name to be customized.

I'd like to pipe in that this is really critical. I see a lot of sites gathering personal info (US Social Security #, birthdate, etc) that, within various legal contexts, need to be securely protected and/or purged at specified intervals. I see no obvious paths to implementations that achieve these requirements, and serious legal liability to Drupal sites if they do not implement secure transactions in these instances... this requirement extends quite a bit beyond just login/admin, to needing to provide SSL encryption on any page that transmits "private" data and/or potentially exposes that data...

New features go to 7.

I wonder how this wasn't put into Drupal 6.x core... It seems many people have been requesting such a feature for five years! I understand there's a lot of features and updates and all to be done with a new release, but this one seems to be among the more important, as it involves critical security for many types of websites, as 1.kentthomas pointed out.

I also think this is important to have. It should also be understood that many Drupal sites are on shared hosting and so there should be some accommodation of such hosts (especially when they provide a per-server SSL certificate shared amongst several accounts).

I think it is also important to consider SSL support for access by XML-RPC or Atom publishing clients.

Ref. "I think it is also important to consider SSL support for access by XML-RPC or Atom publishing clients."

Second that.

Here's a quote from Robert Douglass' post about WordPress 2.6 features Drupal should have:

Better SSL support for the Admin: It should be easy for the (non-technical) admin to have either all of a Drupal site or just the admin and login portions go over https.

What about having a path list for https, so that you can specify it at the path level?

Now that all have chimed in on the need/necessity for this feature... (wait for it...)

When can we expect to see this in Core for 6.x etc...?

(Swerving off topic for a brief second) As far as code train maintenance/feature adds, dels, changes, Are the 5.x, 6.x, actively maintained as separate parallel trains, or does 6 supersede 5 etc.? That is does all maintenance stop on the previous version?

Thanks.
Steve

Frameshift, only bug fixes go into the current release (which is 6.x). New features go into the next release (which is 7.x).

Sorry to be short, but end of life questions should be asked elsewhere.

Regarding comment #20 it should look like:

Anyway thanks for your tips. A real time saver for me.

Subscribing

Hi all,

I have submitted a tiny patch for securepages (6.x) that enforces ssl encryption for forms that include at least one password field :

http://drupal.org/node/346873

hope that can help :)

Maât

Hi,

I would like to see this feature as well. However, from http://drupal.org/node/286499#comment-1081286, securing just the login/admin page is not enough, a method to prevent or detect session hijacking is also needed.

PHP gives you everything you need to prevent session hijacking, you just turn on the PHP session.cookie_secure flag for your HTTPS virtual host and login via HTTPS. As I mentioned above in #29, there was temporarily a bug in core which made session.cookie_secure a bit of a PITA to use with Drupal, but this has since been resolved.

I am under an impression that setting session.cookie_secure flag would be enough if a user stays on HTTPS all the time but would not be enough if he/she drops back to unencrypted mode after login. Of course, a module like Secure Pages (plus a patch which implements this) is needed for the user to be able to switch back and forth between HTTP and HTTPS with a single login.

subscribing

As already mentiond in this thread, to really make the site secure, the cookie has to be secure as well. This poses several problems: When the user goes to a non-HTTPS version of the page, it appears as though they are logged out. Additionally, browsing the entire site with HTTPS is problematic from a site performance point of view because requests over HTTPS are a lot slower than unencrypted requests, so users tend to prefer non-secured pages.

Here’s an (incomplete) solution idea:

• If SSL mode is enabled, force all logins to HTTPS. This prevents at least password theft (but not session hijacking)
• The user gets two different session cookies: one for HTTP and one for HTTPS (which is SSL-only).
• With the HTTP cookie, it only appears to the user as though he has all of the privileges, but actually only has a certain subset of privileges. If the user wants to perform a restricted functionality (one that is not included in the subset), the user is transparently redirected to the HTTPS version of the site. The HTTPS-session has all of the capabilities of the user and can perform said action.
• This allows the user to surf the site via HTTP while not exposing the session ID that has the actual capabilities; if an attacker would obtain the HTTP-session ID, they still couldn’t perform any critical abilities since they don’t have the SSL-cookie. They can’t sniff the SSL cookie because the connection is encrypted.

@Konstantin: I think this is the only solution that makes sense, but it would mean changing the permission system quite a bit.

Now that we have a full "permission" array like this:

We could add other values in the permissions, like adding a 'secure' parameter. At the end of the day, the implementation details are probably for the contrib domain. We should only make sure that core has the proper hooks to do that.

To make this work, we could split up user_access() into a function that serves for display-purposes only (e.g. that is queried when the system has to decide whether it displays a link or renders the form) and a function that is called when the activity is actually performed. That way, we could deny to the HTTP session a certain activity while allowing it for the HTTPS user. The HTTP user still sees these links, though. Now we add a redirection system that ensures that actions requiring the HTTPS session to be sent via HTTPS directly.

This is a mockup of a potential user interface

EDIT: I wrote here that Drupal already supports the two different cookie system. While Drupal /does/ support two different cookies, it does not "connect" the http and https session, so you have to log in twice.

This will need a hook_perm_alter beause it is changing from site to site what permission should be secure. It's a nice security improvement. I think we could simply set a HTTPS only cookie and store the value in $_SESSION and check the value before performing something secure.

To clarify i see this as posting the login credentials to HTTPS, getting a session cookie which is not restricted for HTTPS and a security token which is restricted to HTTPS. This way.... even if you manage to steal the session cookie, you do not get too far.

Also, I would consider doing every POST to HTTPS. That would simplify vastly coding and maybe that should be the first step before all the permissions magick?