So they got a new affiliate program for their iTunes Music Store, but their sign-up page requires a Tax-ID (Social Security # for those w/o another Tax ID) and it's not SSL'ed.
Say it with me, folks: Sensitive information needs to be protected! Credit card, SSN (what else?) numbers, and login credentials that will lead to that information.
Peace,
Jason
Ok, I might be learning something here :)
Purdy on 2004-09-03T20:27:44
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?Re:Ok, I might be learning something here :)
vsergu on 2004-09-03T20:54:38
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 most cases, sites that use SSL are set up to use secure connections for loading the empty form as well as sending the data, but the main reason for that is just so that people can see the lock icon when they're filling out the form. Unfortunately, there's no way for them to tell that the form submission is going to be secure without looking at the page source. Still, most of the time both are secure or both are insecure.
I would say that the Apple page is poor design, just not a security risk.Re:Ok, I might be learning something here :)
Purdy on 2004-09-04T02:42:58
So here's where I'm clueless: when the browser posts the form (from a non-SSL server) to the SSL server, will it fetch the SSL server's certificate, verify it and encode the form data before posting the data itself?
Just putting that in the ACTION tag and unprotecting the initial form doesn't "gel" with my understanding of how the transaction works.
I guess I could put a sniffer between me and the Apple form and see.
Thanks!Re:Ok, I might be learning something here :)
vsergu on 2004-09-04T03:17:27
Yes. Think about it. The request that gets the form has nothing to do with the request that posts the data. The form could be on a completely different server from the form-data-processing script used in the action. Hell, the form could be just a file on your local computer with no web server involved, or there might not even be a form -- you could just be posting the data directly using LWP or something else.Re:Ok, I might be learning something here :)
malte on 2004-09-04T15:35:36
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.
Re:Ok, I might be learning something here :)
vsergu on 2004-09-04T16:20:17
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 shouldn't have said the secure form loading was just about having the lock icon displayed.
The JavaScript point is also a good one.Re:Ok, I might be learning something here :)
nicholas on 2004-09-04T20:59:13
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.
