Re: TLS/SSL patch (alpha)

[Derek R. Price]

I don't have time to dive really deeply into this but some quick thoughts:

Bear Giles wrote:

>    1) the cleanest way to integrate TLS/SSL into CVS is to
>       use an "upgrade" mechanism - early in negotiations the
>       client can request
>
>         Starttls
>
>       and this buffer will be pushed onto the existing
>       socket/fd buffer.
>
>       However, two buffers are defined for the socket and fd
>       buffers, but we must have a combined view because of
>       the traffic which occurs at the TLS/SSL layer but not
>       the application layer.
>
>       Is there a clean way to do this?  Or will this require
>       revisiting the design of the socket and fd buffer
>       initialization?

What, exactly, is stopping you from using whatever buffers are already in
existence to negotiate the connection?  I should check in my socket provider
code soon - it's not as clean as it could probably be, but it demonstrates
applying the auth_server to whatever connection is already in existence.


>    2) Should the server require a digital cert?  (easy answer
>       is 'yes' - it can always use a self-signed cert generated
>       with OpenSSL.)

`Yes, when TLS/SSL is in use' should be fine.  At the risk of telling you
something you already know, make sure that CVS doesn't require a cert when
running in modes other than TLS/SSL...


>       Should the client require a digital cert?  Without a
>       cert, TLS/SSL can only be used for encryption.  With a
>       cert, it can be used for authentication as well.

My vote is that this should be optional/configurable.  Then the server can
reject access to a client without a cert if this is desirable or just allow the
simple authentication server over an encrypted connection if they prefer.


>    3) Alternately, instead of checking the certificate chain
>       maybe it makes more sense to use a strategy like SSH's
>       "known_hosts" and "authorized_keys" schema.  The "known_hosts"
>       would be CVS servers known to the client, and the "authorized_keys"
>       would be user keys recognized by the server.

If possible, CVS should be capable of using the SSH keys instead of separate
ones, even.


>    4) SMTP experience shows that it is best to include
>       a FQDN with the 'starttls' command if server certs are
>       required.  Without one, you can't implement virtual
>       domains.
>
>       So
>
>          Starttls
>
>       becomes
>
>          Starttls root
>
>       and server certs management becomes that much more
>       complex.  However, if 'root' isn't specified we can fall
>       back to a common cert.

I don't know enough about SSL to understand this yet.


>    5) support for session resumption?  Since the client is usually
>       run as a series of separate processes, I don't know if this
>       is practical.

Why would this be desirable?


>    6) TLS/SSL uses packets, not byte-wise transmission, and it's
>       possible this holds surprises for us....

Nothing insurmountable, I assume...


>    7) For the truly paranoid, should we support automatic SSL key
>       renegotiation?

If not overly complicated, we should always cater to the paranoid.  A
configurable option would be best - not sure whether this should be client,
server, or both...


>    8) Integration with SASL.

I took a look at this once and it looked interesting.  Not to discourage you, as
I think this all sounds like good stuff and is much needed, but have you taken a
look at Alexey Mahotkin's nserver ( http://alexm.here.ru/cvs-nserver/ )?  If so,
what were your reasons for deciding against it.  I am just trying to prevent
duplication of effort as some of what you mention sounds similar.

Also, part of the nserver design does sound very desirable and you seem to miss
it here - the removal of most of the authentication/encryption code not only
into a separate library, but into a separate executable in order to minimize
exploitable buffer overflow bugs and the like.  Then the auth executable can
setuid and exec the cvs server when necessary/desirable.

Of course you seem to have a better handle on TLS/SSL and some concepts like
virtual domains...  maybe cooperation is in order?


> /* flag that indicates if we're server or client - or is there
>    a cleaner way to determine this? */
>
> extern int i_am_server;

extern int server_active;

I forget where it is defined, but it is already present in the code and being
used.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@collab.net         CollabNet ( http://collab.net )
--
"I tried to think but nothing happened!"
            - Curly