Re: does a form submit from a http page to a https ensure secure data?

Richard Lynch wrote:

Your form action parameter has an absolute url specifying an https protocol. When the browser submits the form, it uses the url you specify which is https. So the request is going to be encrypted. You might consider serving the form page from https as well to kind of tighten things up a little

What is tightened up exactly? The original poster is probably trying to avoid SSL everywhere possible, thus the question. This is a very considerate approach, because SSL more than triples the amount of time taken to complete the HTTP transaction. He's trying to be polite to his users, rather than using SSL on one more page just to be safe, which is a tactic I applaud.

Unfortunately, the messages going to the naive surfer will not make it clear when/where the "secure zone" is entered: *BEFORE* my data is sent, or *AFTER*? Better to have the *USER* (who shouldn't have to understand squat about HTTPS and SSL and servers) be told they are "secure" when they hit the form, and "insecure" only on the page after the page that took their information.

This is actually a very good point. In my purely logical approach to the question, I did not stop to think that a user entering a credit card number on a page without a little lock icon is not going to feel secure.

Why would you consider this badly misconfigured? I would wager that *most* Web sites use the same document root for both http and https. Do you think this is insecure? Remember, the reason for using SSL is to protect the data during transmission, *not* the data sitting on the server, wherever that may be.

In a shared server environment, if an ISP wants to provide SSL, and they let anybody put anything into the web-tree... Hey, I like the convenience, and that's how my host does it, but I'm not fooling myself that there aren't dumb CGI scripts out there that are exposing data they shouldn't between my colleagues' web-sites. I know *I* work very hard to not let any data "leak" into the file-system, process space, or any place that my fellow users can get to it, but I'm pretty damn sure other web developers are clueless about how much info I could go digging for if I wanted to. My old ISP had SSL on another server (or at least directory) and personally vetted every line of code that went on it. Royal PITA, but more secure. You are correct that SSL only protects the data between browser/server. That does not negate the "chinks" in the armor in a shared environment using the same web-tree directory to store scripts, and probably sensitive data, by the stupid. In other words, it won't make SSL itself any more secure, but it *DOES* make a difference in the data/scripts after SSL is done, and before they safely store/remove the data.

I still don't buy any of this. *shrug* I fail to see how having your SSL document root in a different place is a security benefit. Whether SSL or not, a configuration that allows other users to access your files poses a potential risk. Using separate trees in this way to isolate yourself from others users is just one way of avoiding this, and not one that I would consider that good. Maybe it's just me though. :) Cheers. Chris