Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The form submission is secure (see the ACTION attribute in the FORM tag). So the information is sent encrypted.

    The user doesn't get the reassuring lock icon on the form page, but that's arguably a misfeature in browsers. The important thing isn't whether the form is encrypted but whether the submission is encrypted, and there's no icon for that. You just get a warning if you have an insecure submission from a secure form, but I think a lot of people ignore those warnings.
    • I didn't notice that (and I'm sure the less web-saavy folks didn't either). The more paranoid among us would not have been reassured.

      Does the Web browser encrypt the information on the client side if the initial form isn't SSL'd? Meaning, couldn't it just send the form submission to the SSL server without getting the server's key to encode it? Does that make sense?
      • We're talking about two different HTTP requests that have nothing to do with each other (they could even be to completely separate servers). The first is the request to get the form, which the browser displays. Since the (empty) form doesn't contain any of your personal information, it doesn't matter whether that transaction is secure.

        The second happens when you submit the form and send the data to the server, which responds with the confirmation page. That's the transaction that needs to be secure.

        In mos
        • You're not totally right. SSL is not only about protectting your privacy from third parties. The problem with the form page not being served from a secure server is that you can never be sure that is has not been changed by an evil hacker to submit itself to https://apple.fishingproxy.com

          Plus, looking at the HTML source won't help you much either unless you disable JavaScript because the page can be changed before submitting the form.

          • True, but then the fact that the connection is secure tells you nothing about whether the server itself has been compromised. I don't see how SSL would protect against the page on the real apple.com server being changed. And in any case, if the server has been compromised, the attacker can probably get the data anyway.

            But maybe I'm misunderstanding what you're talking about. SSL does protect against someone compromising your local DNS and pointing apple.com to their own server, which is worthwhile. So I sh
            • SSL does protect against someone compromising your local DNS and pointing apple.com to their own server, which is worthwhile.

              Unless you're using IE. IIRC there's an IE bug (now patched, but what proportion of IEs out in the wide world are patched) whereby it won't warn if someone is using a certificate signed by the wrong authority. Or something easily forgeable like that.