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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
