[RESOLVED] using SSL - individual pages or complete site?

showman13

Good Morning,

I have a membership site and to date haven't been gathering information of the sensitive nature. But now I need to get SSN and DL etc...

We bought an SSL Cert, and now my challenge is this:

Do I secure only the pages that relate to gathering this information, or am I better off securing the entire site?

And the secondary question would be what changes need to be made to existing code in order to utilize the ssl?

Any helpful hints would be greatly appreciated.

Thanks in advance.

Douglas Saferite

bradgrafelman

showman13 wrote:
Do I secure only the pages that relate to gathering this information, or am I better off securing the entire site?

That's probably up to you mostly, but I would say all that you must do as a bare minimum is force certain pages (login, edit/add SSN, etc.) to use HTTPS. In other words, instead of incurring the overhead of SSL for every page load, you probably only need to do so when sensitive information is being sent to or from the client (e.g. you display and/or they update their SSN).

showman13 wrote:
And the secondary question would be what changes need to be made to existing code in order to utilize the ssl?

None. You might need to add new code, however, that forces an HTTPS connection for certain locations (see above).

Also note that SSL only secures traffic in transit. Once it reaches your server, it is now vulnerable to theft again. As such, if you're going to store sensitive information, you should ask yourself how secure your server is.

If you have an account on a shared host, for example, simply slapping an SSL cert onto your site could be seen as a somewhat wasted effort.

showman13

bradgrafelman;10974914 wrote:
That's probably up to you mostly, but I would say all that you must do as a bare minimum is force certain pages (login, edit/add SSN, etc.) to use HTTPS. In other words, instead of incurring the overhead of SSL for every page load, you probably only need to do so when sensitive information is being sent to or from the client (e.g. you display and/or they update their SSN).

None. You might need to add new code, however, that forces an HTTPS connection for certain locations (see above).

Also note that SSL only secures traffic in transit. Once it reaches your server, it is now vulnerable to theft again. As such, if you're going to store sensitive information, you should ask yourself how secure your server is.

If you have an account on a shared host, for example, simply slapping an SSL cert onto your site could be seen as a somewhat wasted effort.

Thank you for your response. The overhead was one of the thoughts I had. So, if I only use the SSL on the pages that require privacy, then I would guess that the calls to those pages would be preceeded by https as opposed to the http. But what happens with relative links. Are they managed differently, or can they even be used when moving from insecure to secure pages and back again.

BTW, Yes, I do own my own dedicated server, so the shared issue isn't really an issue.

It has been my experience that when you go to a secured page, i.e. payment processor, and then when returning to the member website, you see a message indicating that you are going to an non-secured webpage. Is that something that will be an issue within the same website?

Also, what effect will transferring to a secure page have on sessions? Will they remain intact and transfer the necessary data to identify the member?

I know this is alot of questions, but I've spent hours searching on the web for resources relating to PHP and SSL to find the answers to these with no luck at all

I appreciate any feedback you can give me as well as any pointers and pitfalls to avoid, etc.

Another possible concern is that I use .htaccess to extract the members name from the end of the url for their replicated website. Will this be affected?

Thanks again.

Douglas

Any decent resource referrals would also be greatly appreciated.

bradgrafelman

showman13 wrote:
So, if I only use the SSL on the pages that require privacy, then I would guess that the calls to those pages would be preceeded by https as opposed to the http.

Not sure what you mean by "calls to those pages" -- you have to have some mechanism that tells the user's browser to go to a URL that begins with "https://" (e.g. a header() redirect). Really, you as a programmer/webmaster aren't using SSL - it's the clients' browsers that request the SSL connection.

showman13 wrote:
But what happens with relative links. Are they managed differently, ...

Nope. "Relative" links in HTML only change the part of the URL that you specify. If you don't specify a link beginning with "https://" or "http://", then the browser will/should simply prepend the necessary part of the current page's URL onto the link.

showman13 wrote:
It has been my experience that when you go to a secured page, i.e. payment processor, and then when returning to the member website, you see a message indicating that you are going to an non-secured webpage. Is that something that will be an issue within the same website?

I personally never see that message because I've always found it annoying and have disabled that type of warning message since the 90's on any browser I use.

I don't know what you mean by "issue" since that's just the behavior of the user's browser meant to inform him/her what is happening.

showman13 wrote:
Also, what effect will transferring to a secure page have on sessions? Will they remain intact and transfer the necessary data to identify the member?

The session data is stored on the server, so there is no "transfer" at all. The only piece of information that must be "transferred" by the client's browser from one page load to the next is the session ID.

showman13 wrote:
I've spent hours searching on the web for resources relating to PHP and SSL to find the answers to these with no luck at all

Eh, I'm not too surprised that there isn't an overload of information about those two topics together because they really don't go together. SSL just transparently secures data in transit from the server to the client and vice versa. Once the decrypted request has been received it is handed off to the next step in the pipeline just the same as if you hadn't used SSL at all.

showman13 wrote:
Another possible concern is that I use .htaccess to extract the members name from the end of the url for their replicated website. Will this be affected?

I doubt it, no. Again, once the incoming SSL data has been decrypted, Apache handles it just the same as if SSL never existed.

showman13

bradgrafelman;10974919 wrote:
Not sure what you mean by "calls to those pages" -- you have to have some mechanism that tells the user's browser to go to a URL that begins with "https://" (e.g. a header() redirect). Really, you as a programmer/webmaster aren't using SSL - it's the clients' browsers that request the SSL connection.

Nope. "Relative" links in HTML only change the part of the URL that you specify. If you don't specify a link beginning with "https://" or "http://", then the browser will/should simply prepend the necessary part of the current page's URL onto the link.

I personally never see that message because I've always found it annoying and have disabled that type of warning message since the 90's on any browser I use.

I don't know what you mean by "issue" since that's just the behavior of the user's browser meant to inform him/her what is happening.

The session data is stored on the server, so there is no "transfer" at all. The only piece of information that must be "transferred" by the client's browser from one page load to the next is the session ID.

Eh, I'm not too surprised that there isn't an overload of information about those two topics together because they really don't go together. SSL just transparently secures data in transit from the server to the client and vice versa. Once the decrypted request has been received it is handed off to the next step in the pipeline just the same as if you hadn't used SSL at all.

I doubt it, no. Again, once the incoming SSL data has been decrypted, Apache handles it just the same as if SSL never existed.

Wow... thanks for such concise responses to all of my concerns. I think with that I will be able to move forward without too much worry about screwing something up. I always hate dealing with 'new' things at least new to me, on live sites.

This is the kind of response I always hope for in these forums, but seldom receive.

Thanks again,

Douglas