On Sat, Jul 10, 2004 at 11:13:06PM -0400, Greg Hudson wrote:
> On Sat, 2004-07-10 at 21:07, Mukund wrote:
> > Support and absense of support for TLS are advertised as capabilities
> > by the server, upon connection. The client also MUST respond with the
> > capabilities in its response to the server. The capability word is
> > `starttls' for TLS support and `nostarttls' for no use of TLS (without
> > the quotes) for both the client and the server. Both the server and
> > client MUST respond with at least one of these capabilities, i.e., they
> > can't respond without at least one of these capabilities in their list
> > of capabilities.
>
> I think this is an abuse of capabilities. Capabilities should be about
> what the server or client is capable of, not about policy. A single
> "tls" capability should be adequate.
I intended the policy to be automatically adopted based on the
capabilities. We could use a command instead, but I wanted the protocol
to enforce TLS if the capabilities were present. The side effect of
enforcing capabilities is the client and server playing with these
capabilities to turn TLS on or keep it off.
>
> Your goal here may be to avoid round trips, but I don't see that it's
> necessary. If the server wishes to mandate TLS, it can generate an
> error in response to a client response which doesn't mention the TLS
> capability.
In this case the server will also have to send command responses
of failure on every command until the command to start TLS is sent by the
client.
>
> > the server ignores the `url' argument and responds with
>
> Here we have a dilemma. Either:
>
> * The client provides the URL before TLS negotiation, which allows the
> server to use a different certificate and client cert database for each
> repository, but doesn't protect the URL from eavesdropping or
> modification. (The URL could be specified again in the TLS-protected
> stream to prevent modification.) Or,
>
> * The client does not provide the URL before TLS negotiation, so the
> URL is protected. But the server's certitificate and client cert db is
> fixed for all repositories.
>
> HTTP does it the second way, which (as I understand it) interferes with
> https virtual hosting using a single IP address and port. I don't know
> what the right answer is; if we think of the URL as like the address and
> port (part of what you can get with "traffic analysis"), then the first
> answer might be okay.
I did not think of virtual hosting with SVN when writing this,
but it is a good idea. I guess having the initial URL or a portion of it
pass in clear-text may be okay, as long as it is re-sent to the server
upon establishing TLS. The server can use this to pick the right
certificate.
>
> > starttls: ( success ( starttls ) )
>
> Why the "starttls" literal?
>
> I'm not even sure there's a need for a round trip here. It should be
> okay for the client to just launch into the TLS negotiation right after
> sending the client response, assuming both the server and client
> specified the tls capability. Particularly if we decide the client
> isn't providing the URL in its initial response in the TLS case.
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. Even
after advertising the TLS capability, the server may determine that TLS
is not available, say due to non-availability of a certificate for the
host. Then it would respond with a failure command response. You could
probably avoid the `starttls' literal.
>
> > If the client decides that the level of authentication or privacy
> > is not high enough for it to continue, it SHOULD close the connection
> > immediately after the TLS negotiation is complete. If the server
> > decides that the level of authentication or privacy is not high
> > enough for it to continue, it SHOULD reply to every command from
> > the client with a failure command response (with a possible message
> > string such as "Command refused due to lack of security").
>
> I think the server can just send an error in its auth challenge and
> close the connection.
Yep this can be done with the appropriate error message sent to
the client.
>
> > The list of capabilities returned by the server after the TLS
> > handshake MAY be different than the list returned before the TLS
> > handshake. For example, the server might not want to advertise
> > support for a particular SASL mechanism unless a client has sent
> > an appropriate client certificate during a TLS handshake.
>
> SASL mechanisms aren't advertised in capabilities.
This is not what I understood from section 2 of the protocol
document. After the greeting command-response's syntax, there is a
paragraph following it which reads:
"If the client does not support a protocol version within the specified
range, or does not support any of the specified SASL mechanisms, it
closes the connection. Otherwise, the client responds to the greeting
with an item matching the prototype:"
>
> > A common approach which was adopted by many protocols for TLS support
> > was to have a different port number with 's' suffixed to the URI scheme.
> > Nowadays it is considered by many people to be a bad idea. Extending the
> > protocol is recommended instead. A good list of points to support this
> > argument can be found in section 7 of IETF's RFC 2595.
>
> Having read this list several times, I can agree that a separate port
> number is unnecessary, but I still can't help but feel that an "svns"
> scheme, using the same port, would make a convenient shorthand for "svn
> protocol, fail if TLS not negotiated with authenticated server
> certificate and strong encryption."
Yes this is a good idea. We could have a special suffix to the
scheme as an alias to having it in the config file. Do you think keeping
it the same as other protocols, i.e., the "s" part is a good idea?
>
> > Another point to
> > add to that list is the case of some protocols such as HTTPS and virtual
> > hosting which suffers from the chicken-and-egg problem and hence needs a
> > unique IP address per domain, as the virtual host to connect to cannot
> > be specified by the client to the server until the TLS is established
> > and operational, and the server is to return a certificate with the
> > host's domain name in the CN field during the TLS setup.
>
> I'm confused. The chicken-and-egg problem appears to be orthogonal to
> whether a separate port is used, and it seemed like your proposal had
> the chicken-and-egg problem.
The chicken-and-egg problem happens because any protocol with the
's' scheme suffix for TLS assumes that even before a single octet of
protocol communication happens, TLS is established.
Yes it seems that my proposal has the chicken and egg problem :-)
It can be avoided as you have pointed out.
>
> Separate from all this, I have an implementation concern: I think the
> OpenSSL library is only thread-safe if you provide it with locking
> primitives in the single-threaded environment, and our client library
> has no means of doing that.
>
I don't have an answer for this.
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 14:05:11 2004