[Security] client-to-client security :: Summary and todo's
pavlix at pavlix.net
Sat Aug 23 19:23:28 CDT 2008
On Sat, 23 Aug 2008 23:59:41 +0200
Dirk Meyer <dmeyer at tzi.de> wrote:
> Pavel Simerda wrote:
> > On Sat, 23 Aug 2008 20:37:58 +0200
> > Dirk Meyer <dmeyer at tzi.de> wrote:
> >> Dirk Meyer wrote:
> >> > Pavel Simerda wrote:
> >> >> On Sat, 23 Aug 2008 18:21:38 +0200
> >> >> Dirk Meyer <dmeyer at tzi.de> wrote:
> >> >>> UPnP is a working choice, but bad. Just google for it.
> >> >>
> >> >> I know what UPnP is.
> >> >
> >> > I mean: google why it is a bad choice :) See below
> >> This is a good doc:
> >> http://www.gnucitizen.org/blog/hacking-the-interwebs/
> >> Automatic access to something without password is a very bad
> >> idea. That is why I want certificates for all my bots. I would
> >> have no problem with a bot on my router opening ports for other
> >> bots that have a valid certificate.
> > There is a difference between a password and a key.
> Sure. I want my bots to have a certificate, but using a key is as good
> as that for me. But IMHO there should be something. UPnP has no
> security; no keys, no certificates.
> > There is a difference between a symmetric croptography key and a
> > pair of public/private keys for asymmetric cryptosystems.
> I know that.
> > There is a lot of places where automatic access (read or even write)
> > without a password (or key) is appropriate.
> Yes, but not when it is about changing the dns server of the router.
> > These general statements about security are usually false (there is
> > almost always a bunch of cases where it doesn't do any good).
> What general statements? Maybe you missunderstood what I wanted to
> say: I wanted to say that I do not like the fact that UPnP has no
> security and that everything in my LAN can configure my router because
> of it. I wanted to have certificates for my bots doing that.
Maybe I did. I apologise. But you're not making it easy to understand.
"Automatic access to something without password is a very bad idea."
Where "access to something" = "configure router".
I agree that using an unauthenticated service for router configuration
is a bad idea.
But I never said it should be used for configuration.
AFAIK UPnP is used for setting up port forwarding which in itself does
not add any significant security risk (see below).
If there are no good implementation of UPnP, don't blame UPnP but the
impelmentations. If it's not possible to make a good implementation (in
the sense I describe), let's just say what's wrong and drop it. And
possibly pick a protocol that does the right thing and that is likely
to be adopted.
If you see flaws in the idea itself, please let me know, I'm very
curious about it. Just don't tell me about flaws of NAT itself, I know
Just in case... a common argument on the web is that a trojan horse
could set up unwanted port forwarding. That would allow unwanted
connections. But this is not a new issue as the trojan can start
unwanted connections itself anyway! Even incoming connections are
possible but does it make any difference?
If it is allowed to set up redirections for well-known services or for
running connections, I'd consider it a severe bug.
But a password (or different) authentication will not help this at all.
If you authenticate and authorize all computers, it's the same as
authenticating none (except the logs).
IMHO authentication is useless for this sort of portforward requests.
It's a counterpart to (also unauthenticated) *source NAT*... just as
*bind* is a counterpart to *connect*. It just has to be done right.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Security