[RESOLVED] https---->http

[al-la]

I used https for my login page , but now all subsequent pages are also in https , how can I use https just for the login page?

[stephan.gerlach]

there are 2 ways you can do that.

1. via .htaccess file

2. depending how you redirect visitors you have to redirect them to http://www.yourdomain.com/desired/page.php and not just to desired/page.php

i would go with the second one.

[Stephen Philbin]

Depends what you're doing, how you built the login mechanism and why you're using SSL/TLS.

I'd hazzard a guess that your login form page uses SSL/TLS and relative URLs to and from the form processing script. If that's the case, then just make the URL from the login processing script an absolute URL that begins with http://.

However, I can't say I can see much point in ensuring the login process is secure and then ensuring that the login is left completely unprotected. Seems rather like locking yer front door, but leaving the windows wide open.

Are you sure you want to do it?

[al-la]

I'm a beginner, I thought secure login was to protect user's ID & password from sniffers, so no need for subsequent pages to be secure. what you said about door/window above worries me, could you explain more.

[Stephen Philbin]

Well the subsequent page requests to your server are almost as sensitive as the user name & password combination transmission its self.

If you use SSL/TLS to encrypt the connection for sending the user name & password then that's good, but if you don't encrypt subsequent page requests, then you're still leaving the session ID completely unprotected. If someone with a sniffer wanted to be logged in as you, they could wait for you to finish logging in over your encrypted connection and then just read your session ID header as soon as you go back to a non-encrypted connection.

Here's an example. I've just logged in to the contributor's control panel of my own site. I used an encrypted connection just like I always do and every subsequent page request made whilst logged in is also over an encrypted line, just like always. I also ask the browser not to use the cookie if the line is not encrypted and and contibutor that's found to be logged in and connecting via an non-secure line has their account locked automatically.

Now if the contributor's accounts were not immediately locked if they were connecting over a non-secure line and their session cookies were transmitted over a non-secure line then someone else would be able to read the contributor's http request headers and find the session ID. Once they have the session ID, they can use that session ID to identify themself as a logged-in contributor.

Here's the headers one of my browsers sent to my server to identify its self as me. The header containing the session ID is in bold.

GET /contributor_cp/ HTTP/1.1
www.stephenphilbin.com
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.5) Gecko/20061023 SUSE/2.0.0.5-1.1 Firefox/2.0.0.5
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
en-gb,en;q=0.5
gzip,deflate
ISO-8859-1,utf-8;q=0.7,*;q=0.7
300
keep-alive
https://www.stephenphilbin.com/
PHPSESSID=3a50c42c5177e07323e3f2df7afcdb5c

If someone has have been able to read that session ID whilst it was active then they could have simply sent an http request to my site with that session ID and they would have effectively logged in as me and had full access to do whatever they liked with what little of my site I have built so far.

There are also the same (and more) risks when you allow session IDs to be stored in the URL of a user, too. Using cookies to store session ID information is generally the better of the two options.

[al-la]

Thanks stephen that clarifies everything!

[Stephen Philbin]

Happy to help. ;)