Re: TLS/SSL patch (alpha)

[Derek R. Price]

Bear Giles wrote:

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

This still doesn't do it for me.  Why can't you use a buffer as your "socket"?  
So,
the client sends "starttls", then both server and client treat the buffer like a
socket for the next-stage negotiation, then both stuff the newly established 
buffers
onto the front of their buffer chain.  The only roadblock I see from the 
perspective
of my limited TLS/SSL knowledge is that you will need the server name to verify 
the
cert, but this information could easily have been stored somewhere and perhaps
requested of the buffer itself.


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

Um, what I did breaks the code into slightly smaller chunks.  I allowed an 
external
socket provider (e.g. `stunnel' or `openssl s_client'), so I also rewrote the
authentication server code to work via a buffer...  now start_pserver creates a
socket buffer & start_sserver creates a buffer on a process pipe and both call
auth_server to run the login code.


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

I didn't want a strict binding, but I don't see why a particular user shouldn't 
be
able to specify the SSH known-hosts file or stick a symlink from 
~/.cvs/known_hosts
to ~/.ssh/known_hosts, especially if you think it's reasonable to use a file 
provided
by ssh-keygen.


> > > [Virtual domains]

This would be a nice feature.


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

CVS tends to require one connection per command and a command could apply to an
entire project.  One per update, one per commit, one per diff, etc.  There are
probably some special cases like a scripted process that operates on a file at a
time, but they are mostly avoidable.  If not on the client end then the server 
can
forbid x > N connections in M seconds from the same host if it likes, as the 
Linux
inetd does.

If I assume that some of the HTTPS servers I have used are not exhausting their
entropy pools, I can compare this in a gross quantitative way to the kinds of
connections some of those HTTPS servers must get to say that it is reasonable to
expect that the number of connections per client will remain low enough not to 
worry
about in most cases, but maybe it is better here to err on the side of caution 
and
maximum salability and enable session resumption?


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

I've cc'd Alexey and the cvs-nserver list for comments.


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

Can you provide specific examples where this would be extremely useful?  
Because I'm
inclined to say that the level of coding in the application needs be quite a 
bit more
careful to avoid buffer overflow and other common bugs that allow for root 
exploits
in a setuid app on some systems.


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

Hmm...  I think I see what you're getting at, but I see two simple workarounds 
for
this:

1)  Any connection negotiation must be done before the "CVS op" is sent.  All 
the
above looks like it could be handled by a server that mostly only knew about
authentication, so the auth server would wait for, `C: begin real work' before 
it
launched the external server.

or

2)  If a CVS server (child process) quits, the authentication server checks the 
last
line sent (or still in the buffer) for `starttls' (or whatever).  Then 
renegotiates
and starts a new CVS server for `begin real work' if necessary.

The other advantage to this design is that the auth server could be generalized 
to an
extent that it could be applied like inetd or SASL to other applications...

Of course, the only bit of code I'm still leery of moving outside of CVS itself 
is
the pserver code, which includes setuid currently...  Aiyiyi...  otherwise there
isn't even a semi-secure way of setting the user's log name, unless shell 
access to
CVS is disallowed on the system...  Hmm.  Maybe I just want too much.  Well, 
okay,
I guess the auth server could leave the log username for the process in some 
secure
file somewhere, read-only to everybody else, but that seems slightly kludgy to 
me...
usable though.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@collab.net         CollabNet ( http://collab.net )
--
Elsa, I'm no good at being noble but it doesn't take much to see that the
problems of three little people doesn't amount to a hill of beans in this crazy
world.  Someday you'll understand that.

                - Humphrey Bogart as Rick, _Casablanca_