[FreeNX-kNX] FreeNX Security Model Challenge

[Kurt Pfeifle]

On Tuesday 12 July 2005 12:56, Benjamin Podszun wrote:
> Paul van der Vlis wrote:
> > Fabian Franz schreef:
> > 
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Am Mittwoch, 15. Juni 2005 11:08 schrieb Paul van der Vlis:
> >>
> >>
> >>>>This key is used to establish an initial secure tunnel, over which in
> >>>>the next stage the real login of the user, with his real (and hopefully
> >>>>kept secret by him!) credentials happens.
> >>>
> >>>By FreeNX, not by SSH. As a "stupid user", you maybe think you have SSH
> >>>security because only port 22 is open.
> >>
> >>
> >>This is correct.
> >>
> >>
> >>
> >>>>So it is a gross missrepresentation to paint the "--setup-nomachine-key"
> >>>>option as a "not really secure" one. It *IS* secure.
> >>>
> >>>It opens a door with a very secure lock (SSH) to a door with a less
> >>>tested lock (FreeNX).
> 
> *snip*
> 
> > When you use your own keypair and not the default nomachine-key I do not
> > see a security-point. Or do I miss something?
> 
> I only kept the relevant parts..

No, you didnt. 

Whoever hasnt read the previous mails in the thread is strongly 
encouraged to do so now, and make up his own mind.

> The _problem_ with the nomachine key  
> is: Everyone has access to them, they are part of the NX distribution. 
> So if you use your private keypair it's _not_ the same, because to hack 
> away on your NX server I'd first need to steal your keys, right?

Right here.

> If you use the one distributed for all interested people that download 
> any NX package, SSH's security is disabled in regard of access control. 

Wrong here.

> I can start an SSH connection to your NX server right away and play with 
> the NX protocol.

Right here.

> You generously give open the front door and trust, 

Wrong here.

The "front door" it may be....

> that   
> I won't be able to open the door to your freezer.. ;-)

...but to compare the next door to get through, after the front garden
door was opened, to a freezer door is a gross mis-representation of the 
facts. If you think SSL challeng<-->response authentication is unsecure,
please take the discussion to the OpenSSL-devel list, and stop it here.

[Every HTTPS-server on the net lets you come to its login dialog, no?
Does it mean HTTPS is inherently unsecure? Assume that the HTTPS server
was running as user "wwwrun" [sounds familiar, hmm?]. Are you calling 
the HTTPS (SSL challenge<-->response) authentication unsecure? Assume 
more, that I now introduce an additional stage of authentication: our 
HTTPS clients need first to login as user "wwwrun" and they get 
authenticated in this stage with pubkey SSH authentication; only after 
that first stage is completed, they get access to the real user login 
dialog and have, from now, in the 2nd stage of authentication, the same 
challenge<-->response mechanism as before I introduced my change.... 
*I* would call this an additional security level, by all judgements. 
You seem to take the questionable position to now call my setup an 
inherent security flaw, if I decided to distribute the client pubkey 
file and rely on SSL challenge<-->response for authentication  --  
while you do not say the same about the current HTTPS login scheme... ]

> Regards,
> Ben

Cheers,
Kurt