Re: SSH revised

[Bas Wijnen]

On Tue, Mar 28, 2006 at 10:24:28AM +0200, Marcus Brinkmann wrote:
> > > The easy part is that the system doesn't have access to the encryption
> > > keys.  If the ssh public key was transferred to the user via a separate
> > > channel, the system cannot snoop the connection.  That's because the
> > > user code does the decryption, the system code only transports the
> > > encrypted data.
> > 
> > well, in current ssh, the session private key is a system-global one
> 
> No, the session private key is private to the session.  You may be confusing
> it with the host authentication key, which is used to avoid man in the
> middle attacks.

What I wrote was assuming that the user's public key was used to negotiate the
session key.  This is not the case, the host key is used for that.  This means
that the system ssh server can indeed snoop on the connection, because it can
_do_ the man in the middle attack.

> > and I don't know the real process, but this can't work if the current ssh
> > clients first handshake on a way to encrypt the session and after that is
> > when the client gives the username and password
> 
> Why not?  The session en- and decryption can behandled privately at the
> transport layer to and from the user.

Yes, but the key it uses is generated by the system (or at least over a
channel which the system can control if it wants), which means that the system
ssh server must be trusted by the user.  This is unfortunate, since with a
different protocol definition, this trust would not have been required.

> > I mean, when the user server gets the connection, it is already encrypted,
> > so unless a re-negotiation of session encryption takes place, any of the
> > programs that handled that connection cap. to the user server could be
> > snooping on it...
> 
> "Any of these programs" are exactly the ssh server and the user's own
> programs handling the connection.

The only relevant one is the system ssh server.

> There is no issue here.

Of course you must trust the system anyway, but it would have been nice if the
ssh server could have been kept out of the TCB.  It can though, if users run
their own server (through their own domain, or each on their own port).  This
may be a good reason for doing it that way.  However, we don't really need
full trust in the code (as we do for the TCB), we must only know that it is
confined.  That is, the layer doing the en/decryption must get the
capabilities to both ends of the connection, and no other unconfined
capabilities.  In that case, even if it does a man in the middle attack, it
cannot tell anyone about it (except a compromised server on the other end, but
if we have that, we lose anyway).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature