>>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. While HTTPS may be 50 times as slow as HTTP, users who don't feel safe are users who don't spend money. Technologically, only the ACTION URL needs to be HTTPS. User-interface and customer-education wise, you'd better make the FORM page itself secure, as well as the "Receipt" or "Thank You", or you'll have worried users. >>encrypted connection. Your main problem is going to be the fact that the >>http and https services are accessing two different file system spaces >>(or they should be unless you've got your server badly misconfigured) > >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. Or, put it more simply: If *YOU* don't know what's in your [shared] SSL directory, then *YOU* don't know if it's secure. On a dedicated server, this is all moot, of course, assuming you're not stupidly creating logins for no purpose or something. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
