Re: TLS/SSL patch (alpha)

[Bear Giles]

> Bear Giles wrote:
> 
> > 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"?

I probably can - I'm just finding the current code a bit overwhelming.
Each of the bits is obvious, but there's enough of it that I still
haven't formed a coherent view of how it all fits together.  There's 
been a lot of changes since I last looked at CVS code in depth.

My point was just that TLS/SSL isn't really an authentication method,
it will be part of the buffer stack.  However, a few global variables
will be set, e.g., cvs_tls_username, and the real authentication
methods can decide whether or how to use that information.

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

That was my expectation - you had to have the FQDN of the server when
you opened the socket, so all that needs to be done by the client is
cache it and compare it to the cert.

But doing that requires that servers hosting virtual domains knows which
cert to provide.  And once you have that much infrastructure, moving onto
real virtual domains becomes reasonable -- and the more I think about it
the more this sounds like a good extension to the protocol used in the
initial handshake. 

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

I don't have one off the top of my head, it's just a general "here there
be dragons" concern.  That's because openssl, in some ways, moves some
of the networking code from the kernel to user space.  *eeek*

> the pserver code, which includes setuid currently...  Aiyiyi...  

Um....  Few applications still switch to root and then stay there.
It's far more common for the code which requires root access to
be bracketed by setreuid(root)/setreuid(user).  Also, if they only
need root access for manipulating the filesystem they'll use
setfsuid() then drop the rest of the privileges.

> unless shell access to CVS is disallowed on the system...  Hmm.

That's why setting CVS_RSH to ssh and setting up RSAAuthentication
isn't enough.  It gives you most of the functionality proposed here,
but requires shell access to the system.

Bear