views:

49

answers:

3

I'm currently building a web-based file upload/download hub for a company that wanted an easy way to send files to customers.

My question revolves around which parts of the site really need to be SSL encrypted. Is it good practice to only encrypt the login forms, but leave other parts of the site (like the file transfer process) unencrypted?

Some of these employees work out of foreign hotels where line-sniffers are frequent. I'm definitely going to SSL the login form just to protect someone from stealing the login info and deleting files or something. However, since the files are not sensitive (no sensitive files are ever used on this system), will the speed costs associated with SSL ever severely affect the upload/download speeds?

thanks for any input!

A: 

I would SSL anything that has "sensitive" data on it.

In the case of the files you are transfering, this could be anything from a name of an employee, to a customer, or something simple like an email address.

These things should always be secure.

Anything else, does not need to be secure.

The rules vary from case to case, but anything with personal info/money should always be secure.

jimplode
true true, never know what an employee is going to put in a file.
Dan
+2  A: 

Any request that requires the user to be authenticated should be served via HTTPS. In other words, any request that includes a session identifier must be encrypted.

During authentication, most systems set a cookie to identify the user in subsequent requests. A man-in-the-middle could snoop this session identifier if it is sent over an unencrypted channel, just like they could snoop a password. If they include this stolen session identifier, the server can't distinguish the attacker's forged requests from those of the actual user.

The overhead of SSL is generally small relative to other operations, and even then, it is mainly during the key agreement phase of the SSL handshake. This can be avoided for most requests by making sure the server is set up to use SSL sessions that allow the negotiation to be skipped on subsequent requests.

erickson
Excellent response, thank you.
Dan
For apache, the optimisation mentioned in the last paragraph is enabled by the `SSLSessionCache` configuration directive.
caf
A: 

You're already SSL'ing the login, so the only argument against SSL'ing the whole site is a possible request-service-speed hit.

If you're working on the type of app that isn't very speed-sensitive, then there isn't much harm in just protecting the whole site. The benefits (any sensitive data is SSL'd) outweigh the costs,

gmoore