SSL sessions to Non-SSL

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
unplugme71
Forum Newbie
Posts: 13
Joined: Wed Jul 13, 2011 2:39 pm

SSL sessions to Non-SSL

Post 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
User avatar
social_experiment
DevNet Master
Posts: 2793
Joined: Sun Feb 15, 2009 11:08 am
Location: .za

Re: SSL sessions to Non-SSL

Post 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.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
User avatar
flying_circus
Forum Regular
Posts: 732
Joined: Wed Mar 05, 2008 10:23 pm
Location: Sunriver, OR

Re: SSL sessions to Non-SSL

Post 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.
User avatar
social_experiment
DevNet Master
Posts: 2793
Joined: Sun Feb 15, 2009 11:08 am
Location: .za

Re: SSL sessions to Non-SSL

Post by social_experiment »

I missed the different domains first time round :|
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: SSL sessions to Non-SSL

Post by Apollo »

Why not just using https://www.domain.com all the time?
User avatar
flying_circus
Forum Regular
Posts: 732
Joined: Wed Mar 05, 2008 10:23 pm
Location: Sunriver, OR

Re: SSL sessions to Non-SSL

Post 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?
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: SSL sessions to Non-SSL

Post 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?
User avatar
flying_circus
Forum Regular
Posts: 732
Joined: Wed Mar 05, 2008 10:23 pm
Location: Sunriver, OR

Re: SSL sessions to Non-SSL

Post 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 :)
User avatar
social_experiment
DevNet Master
Posts: 2793
Joined: Sun Feb 15, 2009 11:08 am
Location: .za

Re: SSL sessions to Non-SSL

Post by social_experiment »

flying_circus wrote: I also rotate the session id if the protocol changes.
Can you explain this a bit more
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
User avatar
flying_circus
Forum Regular
Posts: 732
Joined: Wed Mar 05, 2008 10:23 pm
Location: Sunriver, OR

Re: SSL sessions to Non-SSL

Post 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);
?>
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: SSL sessions to Non-SSL

Post 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. :)
User avatar
social_experiment
DevNet Master
Posts: 2793
Joined: Sun Feb 15, 2009 11:08 am
Location: .za

Re: SSL sessions to Non-SSL

Post by social_experiment »

:) Thanks for the explanation
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Post Reply