Re: TLS/SSL patch (alpha)

[Bear Giles]

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

> > [ buffer questions ]
> 
> What, exactly, is stopping you from using whatever buffers are already in
> existence to negotiate the connection?  

The intent is to mimic the existing authentication protocols - 
handshake over the existing connection until an "upgrade command"
is seen, possibly "starttls", but it could be anything, then 
continuing with TLS/SSL encryption.

It's important to note that this is completely orthogonal to the
other authentication methods.

> 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.

What I need most is either a road map, or the code broken down into
managable chunks.

> >    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.

The actual SSH keys can't be used, since that creates an unnecessary
binding between two unrelated applications.  (E.g., how do you set up
the files for users with CVS access, but not shell access?)  But it may
be reasonable to use "ssh-keygen" with a different output directory
specified.

> > [Virtual domains]
> 
> I don't know enough about SSL to understand this yet.

It's a general problem with PKI.  How do you handle virtual domains
when the client expects the server cert to have only one FQDN, not
the dozens (or hundreds) that a virtual domain server may support?
The best way seems to be the approach used by (non-TLS) SMTP and
HTTP 1.1 - the client tells the server who it thinks it's talking to.
The server can then provide the proper cert during subsequent TLS/SSL
negotiations.

The last time I checked CVS doesn't support virtual domains, exactly, 
but multiple CVSROOTs are close enough to foresee a time when CVS
will support virtual domains.  The idea is that the server will know,
somehow, that "cvs.example.com/cvsroot" maps to 
"/some/prefix/virtual-cvs/com/example/cvsroot".  In these cases,
the cert saying that the server really is "cvs.example.com" will need
to be linked to that CVSROOT.

> >    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?

The initial handshaking can be time-consuming, and if you're doing
a lot of small interactions you could exhaust your entrophy pool.
Remember, every session requires a new random key.

> >    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/ )?

I haven't looked at it, but I know that SASL is covered by a number
of RFCs and numerous other projects are adding support for it.  This
provides an opportunity for "herd immunity" - CVS picks up strong
authentication because a site has set it up for another application,
but since both apps use SASL the cost of the additional coverage is
trivial.

> 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.

I don't think either TLS/SSL or SASL require root access, although it
might be set up that way by some admins.  I believe most SASL modules,
like the corresponding PAM modules, will usually invoke a separate
program instead of requiring root access for themselves.

As for a separate executable to handle authentication, it sharply limits
your options.  In the real world, encryption not only creates packets
instead of sending data byte-by-byte, it also includes a control messages
that are never seen by the application.  While you probably could create
a reliable proxy that didn't create deadlock conditions if you're doing
careful coding, you lose all ability of the application to exercise fine
control over the protocol.

If you do the encryption in the application, then you're linking in those
libraries.

Finally, there's a definite chicken-and-egg aspect to this - it's not
unreasonable for a client-server exchange to go something like this:

C: hello, I'm Bob
S: hello Bob?, I'm a read-only server
C: I wanna give you my password anyway
S: OK, but passwords require "anonymous DH" SSL or better
C: (start TLS with anonymous-DH)
S: (start TLS)
C: I lied.  I'll really Joe.  And I really want to talk to a virtual 
   domain on your system.
S: hello Joe?, I'm a read-only server
C: (start TLS with cert and specified virtual domain)
S: (start TLS)
S: hello Joe!, I'm a read/write server for your virtual domain.
C: begin real work...

In this case an eavesdropper knows that a session was established,
but not that it was "Joe" talking to a virtual domain in r/w mode.

Bear