'https' remains on various non SSL pages

[sblechner]

Dear Colleagues:

Our CiviContribute page correctly uses SSL. 

However, after visiting this page, when we click on many other non-civiCRM, non-payment links, the 'https://' remains which is unacceptable. 

Any suggestions?


CiviCRM 1.8.11536
Drupal 5.2

[Donald Lobo]

This is an outstanding bug in CiviCRM v1.9. We have not yet figured out a clean solution for this. So a patch for this would be greatly appreciated

lobo

[chrism]

I am seeing the same behaviour on a 2.0 install.  I couldn't find an issue related to this so am wondering if it's still a problem with CiviCRM 2.0 or something with my server.

chris

[Donald Lobo]

This is still an open issue. A patch to fix this would be great

lobo

[acrosman]

Building a solution into CiviCRM is probably not easy as it stands.  I'd expect that you'll need to have a list of pages that must be SSL, and a list that must not (or anything that's not forced to be https could be forced to http), but to be useful in the general case that would require adding configuration options so people could control when are where https was forced.

For apache users, mod_rewrite makes this possible now.  It's not necessarily the easiest module to use, but it's plenty powerful enough to do what's described here (and much more). Adding this to your site's configure will force the https for any directory (and apache sees modules as directories) named civicrm

Code: [Select]

####### Force SSL: ##########
RewriteEngine on
RewriteRule ^(.*)/civicrm/(.*) https://www.example.org$1/civicrm/$2
The reverse would take some sorting out (I copied this from a site I run that does basically this), I've never done the reverse.  You would just need to remember how mod_rewrite likes to 'not' expressions, and add it to the definition of your https site.

[chrism]

Good suggestion!  This approach seems like a useful solution.  I wasn't previously familiar with mod_rewrite, but dug into it and have a couple configurations that seems to be working for a Drupal site on a Plesk virtual host.

CONFIG A
Relying on the fact that all civicrm pages have "/civicrm/" in the path or "q=civicrm/ in the query (depending on whether CleanURL is enable in Drupal), then all civicrm pages can be encrypted and all non-civicrm pages can be unencrypted.

• Disable the Force Secure URLs option in CiviCRM global settings.
  
• Append these lines to conf/vhost.conf
  
  

Code: [Select]

RewriteEngine on

RewriteRule ^/civicrm/(.*) https://www.example.org$1/civicrm/$1

RewriteCond %{QUERY_STRING} ^q=civicrm/(.*) [NC]
RewriteRule (.*) https://www.example.org$1

The way that Plesk sets of the SSL configuration, the vhost.conf file is called for all non-encrypted pages, so all instructions in this file apply to http:// paths.  The first line turns on mod_rewrite.  Second line adds a rule that remaps any path with "/civicrm/" onto the secure path using "https".  The third and fourth lines do the same thing, but catch the case where a site is not using CleanURLs. If the query starts with "q=civicrm/" then do the same mapping.  If the Drupal site is not placed in the home folder, then corresponding changes to the "/civicrm/" path should be made.

• Append these lines to conf/vhost_ssl.conf

Code: [Select]

RewriteEngine on

rewriteCond %{SCRIPT_FILENAME} !^(.*)/civicrm/(.*) [NC]
rewriteCond %{QUERY_STRING} !^(.*)civicrm(.*) [NC]
rewriterule (.*) http://www.bcsustainableenergy.org$1 [L]
This file will be loaded whenever the page is encrypted, so we just have to catch the condition when we want to return to unencrypted path. The rewrite rule will be applied if both of the previous two conditions are met:  the path does not have "/civicrm/" and the query does not "q=civicrm". Note the "!" which does the NOT operation.

• Reload configuration into apache.  For Plesk this can be done with

Code: [Select]

/usr/local/psa/admin/sbin/websrvmng -a


For other server configurations, where the same configuration file handles both encrypted and enencrypted pages, the rewrite condition "rewriteCond %{SERVER_PORT} ^443$" may be useful.

CONFIG B
Allow CiviCRM to decide which pages should start being encrypted. Switch back to unencrypted once any page not on a civicrm path is visited.  This requires a hack to core code though.

- Enable Force Secure URLs option in CiviCRM global settings.
- Change CRM_Utils_System::redirectToSSL so that it doesn't check the base URL for SSL with the call to checkURL( $baseURL ).  I don't know the implications of this hack. There is a comment about checking this so that cookies work.?
- Don't implement mod_rewrite rules to switch from http to https.
- Implement the mod_rewrite rules listed above to switch from https to http.

CONFIG C (not implemented)
Allow CiviCRM to decide which pages should start being encrypted. Switch back to unencrypted once any transaction pages have been left.   Would also require the hack to core code.

- Enable Force Secure URLs option in CiviCRM global settings.
- Don't implement mod_rewrite rules to switch from http to https
- Make a list of all transaction page paths that can occur in CiviCRM and add revise granularity of the mod_rewrite rules listed above to switch from https to http. (I haven't done this)

OPTION D (not implemented)
The preferable option would be the internal fix to CiviCRM code. Would reduce the installation burden, and if there are issues with requiring 'cookies' at the base_url address with https this would resolve them.

[Donald Lobo]

i think we'll stick with option (a) for the short/medium term.

Folks keen on seeing Option C / Option D implemented, please submit a patch that does so

lobo

[chrism]

I have discovered a much easier solution for Drupal that also works better: http://drupal.org/project/securepages Secure Pages module. 

While this relies on an external module, getting browser approved secure pages in CiviCRM is not fully independent from the rest of the CMS. For the browser to show a page as being secure (address bar turns different colour, lock icon appears, ..) all the content on a page must be run through https. Using mod rewrite does direct the base content of a page through https, but some of the Drupal 5 theme files have absolute addresses using http. This means that while the credit card info is secure, users don't get the security confidence indication.

Secure Pages module provides redirection lists exactly the way I developed in mod rewrite, but also takes care of redirecting internal Drupal pages, and has a very easy interface.

I specified the following pages in the Secure Pages list:

civicrm/event/register
civicrm/contribute/transact
civicrm/contribute/offline

and this solution elegantly meets CiviCRM security needs in Drupal.  If there was an equivalent Joomla module, this may cover security needs for CiviCRM, and at least for Drupal 5 I think is preferable to what could be done by CiviCRM itself.

In the future if Drupal fixes all their internal links to use relative paths (maybe in Drupal 6 ?), then an internal CiviCRM redirect would again become a useful option to consider.  The Secure Pages module would be a good base to draw from if this route was pursued.
 

[chrism]

I added a "How do I install SSL on my site" section to the security documentation page
http://wiki.civicrm.org/confluence/display/CRMDOC/Security+Considerations

A specific recommendation from a Joomla user for a preferred Joomla implementation would be nice to add.

[lcdweb]

Here's some recommended mods to htaccess for Joomla users:

Code: [Select]

RewriteEngine On
RewriteCond %{QUERY_STRING} ^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://www.example.org/$1
This will only work if you are NOT using SEF for any civi pages, as it searches the query string for com_civicrm. With SEF on, urls are based on the alias field as you define it -- there's no consistent reference to the component in use -- so you can't really define criteria in the htaccess directives.

Also not that this changes *all* civi pages to https -- not just the contribution pages. That's not ideal, as https takes longer to load, which may be undesirable for admin pages where you don't need https (and don't want the slow down).

[lcdweb]

My earlier post needs adjustment. It breaks in the backend because it loses the administrator/ subfolder. Here's what I've done, though I highly suspect there's a more efficient solution:

Code: [Select]

RewriteCond %{QUERY_STRING} ^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{QUERY_STRING} !^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{QUERY_STRING} ^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} ^/administrator
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{QUERY_STRING} !^option=com_civicrm(.*) [NC]
RewriteCond %{HTTPS} =on
RewriteCond %{REQUEST_URI} ^/administrator
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
What I don't like about this is that it removes all https requests from the interface. So if you have other Joomla components that need to use SSL, I think you'll need to adjust this to accommodate.

[Guy Iaccarino]

What I don't understand about this request is why you wouldn't want ALL pages in CiviCRM to be served over ssl (which I would love to know how to do). There is so much personally identifiable information in the database, why not err on the side of caution? What am I missing?

[lcdweb]

the issue is not specifically civicrm pages --
once the url has moved to https, it affects all pages on the site -- including non-civicrm pages. they will remain on https unless forced to move back to http
while some sites may want the entire site handled over ssl (easily achieved via apache directives), i suspect most will want non-ssl as the default for most pages and only those carrying sensitive info to be over https. one reason is that page load performance takes a hit with ssl.

[mcarson]

I'm glad I found this thread, as I will be attempting to 'switch-on' SSL, but not sure as to what to serve over https or http

Case #1:
CiviCRM is installed in a subdomain (vhosts) and ensure that this subdomain has it's own IP and certificate, or perhaps look into SNI (Server Name Indication)
Case #2:
Configure a separate vhost on a sub directory of your main domain, configuring SSL for this only. (Plesk 10 with FastCGI/suExec) Not sure how this would work with multiple clients sharing same install...
Case #3:
I know it will be a performance hit; serve the whole website over SSL. A few of the larger companies have done this and it seems to reinforce user-trust.

I will most likely be going for Case #2, then Case #3. Case #1 would be expensive...

Thanks for the heads-up on mod_rewrite and 'securepages'