Re: NSURLConnection and self-signed certs?
Re: NSURLConnection and self-signed certs?
- Subject: Re: NSURLConnection and self-signed certs?
- From: joe pezzillo <email@hidden>
- Date: Sun, 13 Jun 2004 20:51:19 -0600
There are two scenarios I can think of, both of which would be useful
to me and probably others.
One, in a "browser" like application (not based on WebKit) where what's
needed is to allow the end-user to visit any site they wish (and/or
can) and retrieve the HTML for their use (either as a rendered HTML
page or for other purposes), in this case, the application software
doesn't care if the site is trusted or not, just that they have enabled
the user to access it if possible.
Second, in an application that wishes to retrieve data from a
cheapskate host (or developer, ahem) where the host address is known,
is known to not have a valid cert due to the aforementioned frugality,
and still wants to prevent casual eavesdropping of the data in transit
between the host and the application. The previously suggested example
of a game developer who may have games in the field that access his or
her own server (or different servers) to retrieve "semi-sensitive" data
(eg, the format of data that tells the remote server what the local
user's high-score is, to prevent a crafty player from sniffing the
communications and then writing a POST Perl script that makes them the
point leader, let's say).
In the second case, yes, an application-specific encryption system
could be used, but HTTPS seems like a cleaner/easier approach
(especially if the App is already doing net/web communications) than
adding on OpenSSL cipher support to the application just to be able to
post a tiny bit of data to a remote server, since it would then require
additional work on the server side to decrypt the data.
I think it's a lot more likely that there are many users who possess
the traffic sniffing/Perl scripting skills than those that can
disassemble the app to discover data structures, and even fewer who
will be able to successfully launch that cleartext attack on the known
data format, but then, I don't know how popular the game is (or what
the stakes are), and admittedly I'm constantly impressed at the skills
and knowledge that users possess, so perhaps I'm underestimating.
Anyway, I'm wary of using undocumented calls, but those are concrete
suggestions and I'll at least try them out to see if it works, thank
you!
email@hidden
On Jun 13, 2004, at 7:48 PM, Wade Tregaskis wrote:
Yes, but that's not useful. Assume you are sending an important piece
of information to a specific recipient. You need to know that a. you
are talking to the right person and b. noone else can intercept the
data in transit. If you abandon certificate verification, you abandon
part a. -- which means that you could be transmitting the very
important data to _anyone whatsoever_.
I think the original poster is just looking for encryption, regardless
of whether it is truly secure. While this sounds stupid on first
glance, it does have some redeeming qualities... it makes
eavesdropping harder for outsiders, and if the other side is in fact
trusted, then you've got no problems.
The original poster's usage may not specify any trust for remote
parties anyway, so even a valid certificate may be meaningless.
Perhaps the original poster could explain the details, rather than me
making assumptions, as I'm sure quite a few people aren't going to be
happy with any [arguably] plausible scenario's I could presently come
up with. :)
Wade Tregaskis (aim: wadetregaskis)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.