Should http be used for https login subsequent pages?

Question

I've seen many threads on SO and they suggest that password can't be securely transferred without SSL. So suppose I've https login page but

1. Should I switch back to http after user has been authenticated over https (assuming no sensitive information is sent over after login)? Because it might load page a bit faster?

2. Would it create extra overhead in terms of development (with Zend Framework)? Like maintaining different directory structures and all that.

Answer 1

1. Yes, you can switch back to http after transfering user password. There is no need to crtypt all content when there is no sensitive data on it. When you have crypted ALL sites: server need to crypt all data and your server have worst performance than without crypting.

Answer 2

1. If the data is not sensitive you could switch back to http after authenticating users to get a small speed benefit. You do have to remember to switch to https again if any kind of sensitive data would appear on site (like user profile or such). It may actually be easier to have the whole session always encrypted so you won't have to worry about turning encryption on and off depending on the page contents.

2. SSL is transparent for developers, you create your app exactly the same as you would for non secure server. You do need to have a SSL certificate that you can buy or generate yourself and set up your server to handle it. Then depending on the protocol (http or https) your session will be or won't be encrypted automatically. So it's a matter of setting correct https:// links for pages where you need an encryption and standard http:// links for other pages.

Answer 3

The time takes for an SSL connection to be encrypted and decrypted (after it has been initialized) is negligible compared to the time it takes to transfer the data. So no, it won't load "a bit" faster even.

The extra folders is dependent on your server, not your framework. If you server routes all https requests through a /httpsdocs folder or something, you could put a .htaccess in it, which redirects it to the /httpdocs folder.

Answer 4

VolkerK is right, but his response errs on the side of caution. The session can be compromised by all sorts of methods. There are ways around this (e.g. using a cached javascript client side to generate hashes against a fixed salt of a challenge generated with each page) but they are messy. By far the simplest solution is to always use SSL. However you might consider using digest authentication combined with a session cookie.

Tor Valamo is wrong. These days bandwidth is very cheap, however what is difficult to achieve is eliminating latency - and latency is the primary determinant of HTTP transfer speed (where most of the content is relatively small). For an HTTP request, there are at least 2 round trips to the server - the TCP handshake then the Request/reply. It will vary depending on the size of files and other considerations, but typically the round trip latency accounts for 50-70% of the elapsed time taken to fetch an object.

Using Keep-alives eliminates one of the round trips and therefore improves throughput greatly.

With SSL, there is at least one additional round trip required (for resumption of an existing SSL session) and more than one for initial SSL negotiation. The real killer is that Microsoft's non-standard implementation of SSL means that you can't use keep-alives from anything other than MSIIS when talking to an MSIE client (see the mod_ssl docs for more info).