Re: NSURLConnection and self-signed certs?
Re: NSURLConnection and self-signed certs?
- Subject: Re: NSURLConnection and self-signed certs?
- From: Wade Tregaskis <email@hidden>
- Date: Mon, 14 Jun 2004 11:13:20 +1000
I am actually working with SSL using URLAccess so our games can
communicate with our server and we can have scoring ladders and
whatnot someday. The problem with not using known certs is that
someone could get between you and the server, and you'd never know it.
They could act as a go between, and mangle the data. This seems far
fetched, we tend to think that there is nobody out on the net who
would want to do this, or they would not be able to. But the odds go
way up as soon as someone is behind a LAN at a college or business or
whatnot, and especially if they happen to log in one day over airport
at some cafe.
This is why peer PKI architectures (e.g. PGP) were developed... you
have to start somewhere, but once you've got a foothold, things are a
lot easier. Then the capitalists landed and we ended up with the gross
commercial PKI we have now. :(
In a game in particular, the problem of unknown certs/identities is
relatively easy to solve; allow the players to chat to each other, and
provide a mechanism for "bookmarking" trusted players... once the
players have chatted to the new person and confirmed their identity in
whatever way they please, they can trust them.
For other uses, this may not be possible. In that case I guess all you
can do is inform the user that they're visiting an untrusted
site/whatever, and allow them to determine whether they trust it or not
in their own manner.
I have a question of my own. I am thinking of putting some random
data into my transactions to throw off would be hackers, mainly
because unencrypted data will probably be sent over TCP/UDP at some
point for the actual game communication. This data will have come
from the SSL stream, and I am wondering if mathematically, there is a
way to recover an encryption key if you know a sequence of bytes in
the stream, and it's always at the same position. For instance,
imagine a stream where the first 128 bits was things like IP, port,
player name, things that can be easily guessed or deduced. Is there a
way to work backwards and reconstruct the key, because you know the
first 128 bits (at least for 128 bit encryption)? If there is any
risk at all, then I will put random data at the start and various
places in the stream. Ideally I would like to encrypt traffic between
players (like a layer over NetSprocket), but after reading this
article, I think my attempts would probably leave numerous holes, so
perhaps it's not worth it. Thanx,
Known-plaintext attacks, as you're describing, are one of the biggest
technical dangers with encrypted communications. Yes, it is entirely
possible for someone to recover the encryption key if they have enough
sample ciphertext with corresponding plaintext. Most applications
include some way around this, as suitable - while SSL/TLS doesn't
insert random data itself (so far as I know), many users of it do, as
you suggest.
The caveat with this is of course that the other side must be informed
of what is real and what is junk data, which means that a third party
may be able to determine the same information, depending on how you do
it.
It should be sufficient to insert random pascal-like strings into your
communications, i.e. the first byte is the length, followed by the junk
data. The single-byte length encoding shouldn't be recoverable by any
reasonable means from the ciphertext, even if they know it's always
there (since it could be anything from 0 to 255, which strangely enough
doesn't help them much :) ).
But if you want to insert random data repeatedly, at different points,
you'll need some mechanism for telling it apart from valid data. If
you use too many bytes as a "header" or whatever, this may weaken the
scheme.... you can do tricksy things like introducing pseudo-random
sequence numbers into that header, or using a FSM (finite state
machine) at each end to "encode" and "decode" data in some particular
fashion... depends on how exotic you really want all this to be, given
that probably 99% of all encrypted communications are broken via social
engineering or plain old-fashion hardware theft... :)
Another point is that you'll need to insert junk data after some (if
not all) significant data, because if you don't then eavesdroppers can
completely ignore your junk data by virtue of knowing the TCP packet
length - if they know your real data is 128-bytes long, they can assume
it's the last 128 bytes if they know you only put random data at the
start. This is quite a problem in general with packet-based
communication... you always need to be thinking about what additional
information is being leaked to the world via TCP/IP (or UDP; same
thing). As I said, placing junk data after each key (i.e.
determinable) packet is one solution, although as you investigate this
further you add more and more cruft to your communications...
In the end, encryption is always worth it, even if it's bad, because it
adds just one extra layer that would-be hackers have to get through
(which, whether trivial or not, still equates to extra time). If it is
bad, it's kind of just security through obscurity, but as much as we
try not to rely on that in the real world, it is a valid method -
provided you don't set up any high expectations for your
less-than-ideal method.
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.