Shared SSL support?

This is one of several improvements I am planning for this module. Since you've asked about it, I'll increase its priority on my queue.

I would also request the same.

:)

The lost of the session is easy to get around by passing the sessionid to the shared host in the query string, but this then breaks the ssl exploit fix.

I'd like to add that flexibility would be needed for the way different hosts offer that shared secure url, for example, I would require:

https://servername.host.com/~username/file.php

So glad to have found this, thanks!

i don't know how i should name my problem, but is the module working in a situation where i have a virtual server with one IP, but ~10 virtual drupal sites on it? this is not a multiserver install. every application has it own code.

Any way to use the SSL on URL www.example.com and login into www.test.com - both on the same IP?

We have recently switched to Drupal from a proprietary content management system for a lot of client projects. Shared SSL support is a big cost saver for clients, and our old system dealt with it fairly elegantly. The tricky part from a mod_rewrite perspective is the fact that you can't have more than one RewriteBase. However I was able to get around this by stripping the base if the port is 80. This should help, but true, robust secure pages support in Drupal may require core changes...

# ALL EXCEPT SOME FILE EXTENSIONS TO "index.php" FILE.
RewriteBase /shared_ssl_subdir
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule .* index.php

# STRIP THE REWRITEBASE RULE FROM NON-SSL CONNECTIONS.
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} ^/shared_ssl_subdir
RewriteRule .* /index.php

I’m very interested in this, as well, so that I can do secure logins for my authenticated users and admin account. Any news on this front?

I’m also in the state with my Web host where my site is hosted at one domain but the host provides a shared certificate for all users of a particular server, and to use that certificate you must connect by another URL.

So, I would connect to my site with:

http://mydomain.com/

… and to use the host’s shared SSL for that server, I’d have to connect to:

https://theirserver.theirdomain.com/~myaccount/mydirectory/

… and I’d really like Drupal to allow me to send anonymous users to the first URL but all logins (at least) and optionally subsequent pages for authenticated users to the second URL. So, I’d like to make another vote for this capability, which is valuable to anyone on shared hosting and who does not want to or cannot get a dedicated IP address for an SSL certificate.

Bump I'm interested in how to do this as well. any ideas?

There are "SAN" certificates available... in this way your are able to secure more then domain per IP.

Basically the problem is a question of security. I have not figured out any way of securely passing the user to another and log them in without a passing the session id on the URL.

This is very susceptible to to session hijacking.

So just checking – 'pologies if I seem dense for asking, but... – is it the case that there are currently no solutions for using a shared secure server?

Thanks in advance for clarifying!
:) Scott

Basically yes that is the case.

I have not found a way that will will allow me to transfer you to another server session in tack and not allow anyone to hijack the session.

Ideas are most welcome

Gordon

Hi Gordon – hmm, that doesn't sound ideal! :)

What about this patch? #242030: Allow Secure Pages to use an alternate shared host or port for encrypted pages

I saw it after I posted here... seems to address the shared server issue?

I didn't see any comments about the code in that patch... whether it addresses the hijack possibility, or if the code still leaves open that security hole?

Scott

Thanks! I was looking for a simple way to make Drupal works with shared SSL and so far (5 minutes), your method seems to work. : )

Edit: Ooops I meant #8's method... http://drupal.org/node/65890#comment-411678

If you go to the latest dev you are able to set the http and https versions of the site, and then you just need to set the session_cookie to *.example.com so the the session is shared between the 2.

Hi Gordon,

I've installed the latest dev of Secure Pages, which enables setting of the secure shared SSL server, but can you explain how to "set the session_cookie"? Also, is post #8 still required (changing the .htaccess file)?

Thanks in advance for any suggestions

Steve

No you don't.

Hello Gordon,

"No you don't"? ... to set the session_cookie, from about an hour's Google searching, requires Javascript or Perl on the server?

Presumably, the Javascript needs to be inserted into ...? the page.tpl file, the index.php file?

Back to Google, it seems. Thanks anyway.

Cheers

Actually it you look in your settings.php there is a var called $cookie_domain. just set this to something like ".example.com" <== remember the "." at the beginning.

Thanks Gordon,

Much appreciated. Working on it now.

btw, the example as given in the setting.php file does not have a "." in front of example.com, so some confusion there ...

Best ..
Steve

Problem solved with a complete slash & burn (re-install) using the new dev for 5.x.

Now there is a new problem... Whenever I go to a SSL page I'm immediately logged out and can't log in while on the SSL page.

Anyone have an idea how to fix this?

Thanks in advance,

Ok, dumb question time...

The first time that I turned the secure pages mod on in Admin everything worked OK until I configured the secure pages with the following (per the Ubercart site):

user
user/*
user/*/edit
admin
admin/*
cart/checkout
cart/checkout/review
cart/checkout/payment_details/*
cart/checkout/complete
uc_paypal/ipn/*
uc_paypal/wps/*
uc_paypal/wps/complete/*
cgi-bin/webscr

Saved it and the site is borked. I've already taken the DB entry out but it seems that I can't get back to the secure pages settings without turning the module on and I cant turn the module on without the site borking.

Here's the question... Is there somewhere other than in the MySQL db that the configuration data is stored? ( I've already deleted and reuploaded the module)

Thanks for any input

How about closing this case after 2 years!?

Anyone still working on this? I've tried following all the threads above, going back and forth from my shared SSL easily, but when I get to the shared SSL I'm not logged in.

Here's everything I've done.

Upgraded to Drupal 5.12 (latest dev I could find, oct 22, 8 from http://drupal.org/project/Drupal)
Upgraded to the latest dev of securepages (5.x-1.x-dev 2008-Aug-07 from http://drupal.org/project/securepages)

I added my cookie domain to my settings.php file, tried it with and without the beginning . ($cookie_domain = '.example.com'; )

I configured securepages, with secure and insecure url, and to just go to my shopping cart page (from previous disasters I knew not to experiment by securing my admin pages until I know it all works -- otherwise you can get locked out because the admin pages become unaccessible!!!)

I turned clean url's off to make sure it wasn't that.

Help would be appreciated.
Connie

apparently it's my server, which won't allow a cookie from another domain, unless we pass the session ID and set a new cookie.

dang

You can't do this with completely different domain names, like foo.com and bar.com it will not work.

but with using wilcard cookies like example.com and secure.example.com you can do it with wildcard cookies. I am thinking about an idea of implementing some sort of token which will load up the other session (being the secure or the insecure) so that it it is much harder to spoof the transfer.

How's about just passing the session id in the url. That's the way oscommerce does it. The security issues don't seem to be that great.
Connie

Passing the session id via url is insecure. Anyone having your session id can use your session as long it is valid.
Just bookmark a page and send it to a friend.

This is a feature request, so setting prio to normal.
Also it's probably a feature for HEAD.

I struggled with this issue, too, and just ran across this soution (might work for some of you) today. Let me explain what I did.

I have registered mysite.com. I use IXwebhosting, which does provide a shared SSL certificate. Great! But of course, the domain for their shared certificate is: mysite.c7.ixwebhosting.com

I installed and configured Secure Pages to redirect to https when /cart or cart/* is requested.

As noted above, drupal (and ubercart) lose session information when that redirection occurs, because the request is for a completely new domain. Dang, is right. Tried various stuff like setting base url or cookiedomain within settings.php , but the domain names are very different. I even tried setting the cookie domain to 'mysite*.com' figuring that would match both the secure and insecure domain names. Still no luck.

Then, I tried adding a DNS setting. : I created a CNAME entry secure.mysite.com and pointing it to mysite.c7.ixwebhosting.com So now, as far as DNS is concerned secure.mysite.com == mysite.c7.ixwebhosting.com

I went into the Drupal Secure Pages settings page, and set the 'secure base url' to https://secure.mysite.com

It's close enough to mysite.com that drupal accepts the cookies placed by mysite.com when it gets to secure.mysite.com pages. And browsers accept the secure.mysite.com domain without requiring an 'exception' or giving other complaints because they can see (from DNS, I guess) that the two domains are equal.

So, in summary, one can use a DNS CNAME to overcome the problem outlined here. All that being said, it would be handy if completely different domain names also worked. I can clearly understand how passing the session id in the URL would not be acceptable.

If this solution seems replicable for other domains, I would ask for a re-written explanation. I am just getting this out there in case others might test it in their environments.

has anyone ever gotten secure pages to work with a shared ssl in the form of https://secure.hostingcompany.com/~username/

I have tried:
(1) .htaccess rewrite stated in #8 above
(2) settings.php modifications posted in http://drupal.org/node/339552

Neither option has worked for me. When accessing a secure page, the rewrite occurs properly (https://secure.hostcompany.com/~username/secure-page), however, i'm now logged out -- not completely logged out b/c you can still hit back to get the non-secure page where you're still logged in.

A lot clients who are not making their sole income from their e-commerce can't justify the extra expense associated with dedicated IP and SSL ($75/yr for my hosting comping). There seems to be a lot of carts that do use the shared ssl -- agora cart, osCommerce, but I would prefer a drupal solution.

jimurl,

Are you setting the cookie domain in settings.php too? What about the web server configuration and DNS for mysite.com? Is it a virtual name-based host?

I'm faced with a similar issue.

A company has www.company.com as their main site and www.companystore.com as their SSL Cert domain. Because of the limitations with the cookies and sessions, I can't use two different domain names like that for a single Drupal/Ubercart site. They've only got one ip and using name-based virtual hosts so a second SSL cert won't work and I'd prefer not to replace the current SSL cert domain with the main site for legacy reasons. Perhaps CNAME-ing secure.company.com to www.companystore.com will work.

How similar do the names have to be? This is getting a bit out of my league - no experience with sessions or cookies - but I have a very similar problem to solve for a non-profit I host on my Bluehost account. Their domain is an add-on running Drupal 6.x and civiCRM. My primary domain hosts no site at all -- it redirects to another add-on. I want the non-profit's donation page to use either the secure.bluehost.com certificate or one that I would install on my primary domain. Not sure yet which, but it sounds as if both approaches would present problems. The domains are not similar: bluehost, myprimarydomain, nonprofitname.

https://secure.bluehost.com/~primaryusername/nonprofitdirectory/civicrm/... is the donation page path when testing on bluehost's SSL.

I can get this to open (haven't done a test submit yet) but it is completely unstyled - not finding the .css from the Drupal theme / civiCRM / civiContribute. Getting it to open at all required this change near the end of Drupal's .htaccess file:

RewriteBase /~rprimaryusername/nonprofitdirectory

hmm,

so it seems that shared ssl with a different domain to the sites domain, doesnt seem to work.

i tried jimurl's idea, http://drupal.org/node/65890#comment-1657638, but doesnt seem to work, thou i can see how it would. Maybe my DNS will refresh in the morning and work fine. the ssl shared cert i have is 'secure4.host.com.au/username/'..

And i have a CNAME set up so that...

secure.domain.com.au == secure4.host.com.au

and secure base url in secure pages module points at..

https://secure.domain.com.au/username/

ive tried variations of these with and without slashes and directories. Not sure how long DNS takes to refresh... each time.

------------

Im also a bit unsure of that hack, since my host would, by purchasing a private ssl, offer a new domain https://secure.domain.com.au, which is ideally the same as what im trying to hack the DNS to do.

------------

my client is changing from asp to php because of the $300 incurring cost. at the end of the project, im not too keen to say that he is going to have to now pay a $300 yearly fee for private ssl.

------------

Is it possible that when the person logs in, that a cookie/session gets set for 2 domains? ideally this is what id try and do if developing from ground up...

im also new to all this. first time working with ssl too.

EDIT: It seems that when i point 'secure.domain.com.au' to the shared cert. It does partially work.. the page doesnt load. but when i look at the certificate, its certificate valid dates are the same as the shared cert. But it doesnt work because of a security clause. both browsers seemed to say something about a site 'pretending' to be 'secure.domain.com.au'.. so the DNS is pointing correctly... *sigh*

Hi,

This still appears to be an issue, and one that I am having as well. Has this been solved? Is there any documentation on how to set-up Secure PAges with shared SSL?

Nick

subscribe

HI All

I have been trying to achieve the same thing with a site I am building where the main site runs as

http://www.mydomain.com

And the SSL runs under

https://site.securedomain.com

And this causes all sorts of strange issues.

Is there a real requirement from people for this and would people be willing to help find a solution... and more importantly if a solution was found would the module maintainers be willing to get something like this included in the module itself?

I'm still wishing for this also. There are so many people wanting this feature, I'm sure we could all pool some money and pay the developer.

I would second that.

According to http://www.15seconds.com/issue/971108.htm The way you get this to work is to submit the session id to a special page via the request string, then the special page recreates the cookie on the 2nd domain, then redirects to the traget page. People who worry about session hijacking via the request string don't realize the session id is already sent over the wire. There's no difference in security on whether the data is in a cookie or in the request string.

Thank you DraconPern. Would really like to get a solution to this. I have a large number of domains with shopping carts, and we are having to default to paypal for the security as purchasing a separate ssl for each domain would be very very expensive.

Subscribing

+1

If this is not possible to find a solution for in a secure way, how about implementing it with a warning and intended to be used only in certain situations?

Example situation:
On any site that does not have SSL, upon installing Drupal, one is forced to send the passwords insecurely. The admin has not even logged into the site yet, and already someone else can have gotten hold of the insecurely transferred password and gain access as uid1.
That situation in itself must be deemed more critical than whatever the solution to this issue may bring.

In this example, all that is needed is to be able to turn on support for a shared SSL URL so that:
a) the admin can add users and openids using the openidadmin module, and
b) reset the password on these user edit pages securely, so that after this, he/they can use OpenID to log in, and can then turn this temporary SSL function off.
Only need to use this module for a minute or two, and then turn it off.

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks