On Sun, Jul 11, 2004 at 12:04:02PM -0400, Greg Hudson wrote:
>
> I think you may have misunderstood me. I'm not suggesting we use a
> command to initiate TLS; I'm suggesting that if the server sends the
> "tls" capability, and the client sends the "tls" capability, we do TLS
> negotiation right after the client response. I don't see a need for a
> "notls" capability which has no effect other than to help a new
> non-TLS-supporting client recognize more quickly when it's not going to
> get in.
>
Ahh.. I think I put that "notls" in to allow for cases where a
TLS capable server allows only in-the-clear communications, but that can
be done by having no `tls' keyword in the capabilities list. This could
also let older clients work still.
/me slaps forehead.
> > I did not think of virtual hosting with SVN when writing this,
> > but it is a good idea.
>
> Okay. Either the client can send the URL truncated at the hostname
> part, or we can rely on the TLS extension David mentioned, if it's
> implemented in the library we use. Whichever's easier to implement, I
> think.
Yep. Maybe we have the facility for having the truncated URL
anyway, as it can be useful for implementations which do not support the
TLS extensions such as OpenSSL now.. but considering current implementation
support is no way to design a protocol too.
> I note that the server certificate is not the only issue; different
> repositories may also have different databases of user certificates for
> user authentication. But I guess the server can just hold onto the
> client certificate until the full repository URL is specified.
Hmm.. yes the server can send a failure error response and
terminate the connection at the authentication stage.
> > This is a server response. It is generated to indicate a success
> > or failure to the client on whether to go into the TLS handshake.
>
> It seems simplest to just always do SSL in this case. If the server has
> no certificate for the specified host, it can perform a handshake
> without sending a server certificate. If that's okay with the client,
> the connection might still reap the benefit of being opaque to passive
> eavesdroppers, using a Diffie-Hellman exchange.
You have a point. The server anyway has an opportunity to drop
the connection if it is not satisfied with the TLS after its setup.
Do you want me to send a patch to the protocol document, based on
what we have discussed?
Mukund
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 11 23:58:23 2004