Page 1 of 1

SSL sessions to Non-SSL

Posted: Wed Jul 13, 2011 6:45 pm
by unplugme71
Is it possible to carryover a SSL session to a non-SSL page?

For example, my SSL host is https://secure.mydomain.com

and after the person logs in, I want them to get back to http://www.domain.com and display their name and/or username. They can also go back to the https:// site to update their contact info, submit payment, etc. How can I call the same session and session variables from a different subdomain and also being non-SSL?

What security issues does this impose, if any? The password would be stored as sha512

Re: SSL sessions to Non-SSL

Posted: Mon Aug 08, 2011 5:05 am
by social_experiment
Is there a particular reason that would warrant this, because there is no real downside (to my knowledge) to having to navigate between https pages. I'm not an expert on sessions between https and non-https but i would think there is not difference between the value of $_SESSION['user_id'] set on either one of the protocols.
unplugme71 wrote:What security issues does this impose, if any? The password would be stored as sha512
The obvious issue is that data transported to / from the server on non-https pages wouldn't be encrypted. Login is done using a https page (from the given description) so there shouldn't be a issue about it's vulnerability during login but https / non-https isn't my forte.

Re: SSL sessions to Non-SSL

Posted: Mon Aug 08, 2011 10:36 am
by flying_circus
unplugme71 wrote:Is it possible to carryover a SSL session to a non-SSL page?

For example, my SSL host is https://secure.mydomain.com

and after the person logs in, I want them to get back to http://www.domain.com and display their name and/or username. They can also go back to the https:// site to update their contact info, submit payment, etc. How can I call the same session and session variables from a different subdomain and also being non-SSL?
The problem that you are going to run into, is that the domain names are different. Sessions are typically based on cookies and your browser should only allow a website to read cookies from it's own domain. If the domain was the same, subdomains should not a problem or can be configured for using session.cookie_domain setting

I suppose you could go back to passing the session identifier in the querystring, but that's not exactly desireable either, however, it might be the only way to do what you want to do. I seem to recall this being a big issue back in the osCommerce days and working with shared SSL certificates.

Once you have the sessions started, you should write some code to figure out if the request was http or https, if its https, I typically check for an additional "secure" cookie with a token, so that I know the user is who they say they are. Only then, will they get access to the secure area.

Re: SSL sessions to Non-SSL

Posted: Mon Aug 08, 2011 2:44 pm
by social_experiment
I missed the different domains first time round :|

Re: SSL sessions to Non-SSL

Posted: Tue Aug 09, 2011 3:12 am
by Apollo
Why not just using https://www.domain.com all the time?

Re: SSL sessions to Non-SSL

Posted: Tue Aug 09, 2011 10:31 am
by flying_circus
Apollo wrote:Why not just using https://www.domain.com all the time?
If the site grows, then he will soon be fighting resource challenges.

In my opinion, certain information needs to be transmitted over a secure link, stuff like user identifiable information, authentication credentials, payment information, and account history might be a very short list.

However, public images, javascript files, stylesheets, along with any generic page like your home page, about us, policies, etc, do not need to be sent over SSL.

Take a look at the traffic logs and see where the largest chunks of data transfer are coming from. Maybe it would make more sense to run everything through SSL?

Re: SSL sessions to Non-SSL

Posted: Wed Aug 10, 2011 11:00 pm
by Jonah Bron
I guess the amount of trouble worth it depends on how much of your site requires security. For example, if you browse around on a Google Code project, you're just on HTTP. But if you go from there to your Google Code Profile, it sends you to HTTPS. In that situation it's clear that you wouldn't want it to always be on HTTPS. You could have one session with a cookie for HTTP, and one with a cookie for HTTPS. The one on HTTP never contains personal data, that way it can't be accidentally leaked through sloppy code. Is that a valid option?

Re: SSL sessions to Non-SSL

Posted: Thu Aug 11, 2011 12:14 am
by flying_circus
Jonah Bron wrote:I guess the amount of trouble worth it depends on how much of your site requires security. For example, if you browse around on a Google Code project, you're just on HTTP. But if you go from there to your Google Code Profile, it sends you to HTTPS. In that situation it's clear that you wouldn't want it to always be on HTTPS. You could have one session with a cookie for HTTP, and one with a cookie for HTTPS. The one on HTTP never contains personal data, that way it can't be accidentally leaked through sloppy code. Is that a valid option?
Hi Jonah,

I will assume that you're talking about maintaining individual HTTP and HTTPS sessions on the same domain. You're statement about google above describes the quintessential example of mixing HTTP and HTTPS on a website.

I wanted to comment that I think maintaining separate sessions is a really bad idea. The first reason is that it would be a nightmare to synchronize them. The second reason is that I believe it to be completely unnecessary. If you think about it, there is nothing different between an HTTP vs HTTPS session other than the way that the identifier is transmitted to the user. It would be a false assumption to believe that the session data stored on the server is somehow protected or encrypted if you were accessing the server over HTTPS. I mean, I suppose it *could* be, but it's not the default behavior of PHP, you'd have to write your own session handler.

I am of the opinion that you should use php to determine the request protocol, and based on that result, decide what session data is available to the user. I also rotate the session id if the protocol changes. I also rotate the session id on privilege change, like logging in or logging out. When the user is authenticated by logging in, which should always be over a HTTPS connection, I send a secure cookie containing an access token. Being that all modern browsers respect the secure flag on the cookie, it is no problem to change between protocols. If its a HTTP request, fine, load the session data and show the user their shopping cart or other products they may be interested in. If they navigate to a HTTPS page, fine, check the token in the secure cookie, rotate the session id, and show them their billing and shipping info.

Besides, I cannot think of a good reason to store user information in the session data anyways. Sessions should be used to store navigational or task related data, and only for a short time. The only personal information that needs to be kept in session data is the user id, to track the user across your website.


Sorry, I kind of went off on a tangent there :)

Re: SSL sessions to Non-SSL

Posted: Thu Aug 11, 2011 2:46 am
by social_experiment
flying_circus wrote: I also rotate the session id if the protocol changes.
Can you explain this a bit more

Re: SSL sessions to Non-SSL

Posted: Thu Aug 11, 2011 9:45 am
by flying_circus
social_experiment wrote:
flying_circus wrote: I also rotate the session id if the protocol changes.
Can you explain this a bit more
I'd be happy to!

I store a boolean flag in my session data that tells me if this current session id was created in a HTTP or HTTPS environment. I check the flag on every page request to see if the flag matches the current request protocol. If it doesn't I regenerate the session id.

The benefits are 2 fold.

1. I know that the session id used for the HTTPS areas of my website were not sent out over HTTP. Even if someone were to pick up the session id on the wire over HTTP, they'd still be missing the token I store in a secure cookie, they won't have all the ingredients to gain HTTPS access.

2. I use a custom session handler that reads/writes the session data to a database. When I read the session data from the database, the $_SESSION super global is not automatically populated, it is always empty until I manually populate it. This provides a nice line of demarcation, I store my session data in an array and the first fork is $session_data = array('https' => array(), 'http' => array()). Now that I know my protocol, I only load relevant session data into the $_SESSION superglobal to be accessed.

It's taken some time to get right, but it sure works nice!

Code: Select all

<?php
  function is_https()
  {
    if(isset($_SERVER['HTTPS']) && mb_strtolower($_SERVER['HTTPS']) == "on")
      return true;
    else if(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 1)
      return true;
    else if(isset($_SERVER['SERVER_PORT']) && $_SERVER["SERVER_PORT"] == 443)
      return true;
    else
      return false;
  }

  # Check Protocol: Have we traversed HTTP Schemes?
   if(is_https() != $_SESSION['https'])
    session_regenerate_id(1);
?>

Re: SSL sessions to Non-SSL

Posted: Thu Aug 11, 2011 10:27 am
by Jonah Bron
flying_circus wrote:I wanted to comment that I think maintaining separate sessions is a really bad idea. The first reason is that it would be a nightmare to synchronise them. The second reason is that I believe it to be completely unnecessary. If you think about it, there is nothing different between an HTTP vs HTTPS session other than the way that the identifier is transmitted to the user. It would be a false assumption to believe that the session data stored on the server is somehow protected or encrypted if you were accessing the server over HTTPS. I mean, I suppose it *could* be, but it's not the default behaviour of PHP, you'd have to write your own session handler.
I see. I wasn't sure, hence the "Is than a valid option?" :)
flying_circus wrote: I also rotate the session id if the protocol changes. I also rotate the session id on privilege change, like logging in or logging out. When the user is authenticated by logging in, which should always be over a HTTPS connection, I send a secure cookie containing an access token.
That's quite smart, I'll keep that in mind for future projects.
flying_circus wrote:Sorry, I kind of went off on a tangent there
One of the most informative tangents I've ever read. :)

Re: SSL sessions to Non-SSL

Posted: Thu Aug 11, 2011 3:20 pm
by social_experiment
:) Thanks for the explanation