[icecast] a new directory service
all at biosys.net
Thu Oct 18 04:00:24 UTC 2001
At 09:43 PM 10/17/2001 -0600, you wrote:
>The chances of someone sucessfully attacking a target of their choice is
>quite slim in this system, unless they can assume control of the server
>machine or assume control of the source machine. In either of those
>situations, it would matter little what security method was used.
Well they can also attack any system in between to set up a Mallory (as the
guy in the middle is called) and dupe you. It's just a matter of
intercepting the packets bound for the directory server, connecting them to
your own, and then connecting from your directory server to the real
one. Then you're altering things in real time, and it's totally
transparent.. This is a "big" problem no matter what sort of double-blind
system you use however.
>Public keys are not really as easy to use as everyone would like. If
>needed it can be done. And I have no doubts that at some point
>something like this will get in there, but there's little reason to do
>so right now.
Well I beg to differ on the first point. A simple method is to just have
the server generate it's keypair on initial startup/installation and then
serve up the public key when requested. It's a little harder on machines
on both ends to do the encryption, but horsepower is disgustingly cheap
Consider the following simple protocol:
1) Client connects to server and downloads the servers public key.
2) Client encrypts it's own public key (or a private per-session key) with
the key it downloaded in step #1 and sends it.
3) Both ends initiate encrypted communication.
This is simple and perfectly secure so long as the client trusts that it
indeed got the actual servers public key. This can be accomplished by
using multiple methods of key verification, or by using a known-good public
key server which signs the key transfer with it's own known-good key.
There are several packages out there that can automate a great deal of this
in code.. it's just a matter of using a wrapper for all your socket calls
that has an internal "encrypted=true|false" state.
This isn't foolproof itself to a determined adversary, but it would stop
all but the most determined and sophisticated attacks.
>If you think there are scenarios that aren't being considered, or you
>feel strongly that sniffing attacks are sufficiently dangerous, then by
>all means speak up :)
I just did. ;) I don't think that the situation currently warrants this
level of paranoia; However, I don't think it would add any harm or much
effort to add it in. Kind of like not limiting ourselves to 640K like
someone once did for us.. still haunting us in some ways to this very day. ;)
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast