Re: CVS & SSL

[Derek R. Price]

"Greg A. Woods" wrote:

> [ On Wednesday, May 23, 2001 at 10:30:22 (-0400), Derek R. Price wrote: ]
> > Subject: Re: CVS & SSL
> >
> > Yes there is.  The connection can no longer be sniffed.  Stealing a
> > user's password would now require access to the user's machine to read
> > the .cvspass file.
>
> Maybe you forget that most security issues come from within.  I don't
> know how hard it would be to break but I suspect your connections are
> all protected by the very same key (after all you only have one real
> identity at the server side and you've got to negotiate the secure
> connection *before* anything inside CVS can be used to identify the fake
> identity).

I only added code to cvs to exec an external "socket provider" and then run
a pserver connection over that link.  Whether that socket provider is
cleartext, like say tcpserver, an SSL connection using the same key every
time, or an SSL connection smart enough to rotate keys like SSH does is
irrelevant to CVS.  This should allow the user some flexibility.

Also, in regards to problems from within, I telecommute to work via a cable
modem.  My firewall logs show packets from an entire class A subnet bouncing
off the wall.  I'm guessing that means AT&T is providing something that at
least _looks_ like a single LAN to something like, at least, my entire
county of something over 1 million people.  Not to rag on them too much, but
1 million people probably includes a fair number of teenagers with too much
time on their hands who might think it an interesting game to sniff
passwords.

An ounce of prevention is worth a pound of cure and an SSL link for my
pserver connection is a significant security leap given my setup.


> > Hacks are always unecessary.  This one happens to be somewhat useful,
> > simple, and fits tidily in with the existing code.
>
> hmmm...  I'd rather see pserver ripped out entirely.  It's not even
> necessary for anonymous access.  What a waste of effort......
>

What alternative do you propose?

> Because this works without setting up a permanent tunnel.  That's one

> > less step of overhead involved in connecting.  Your typical user
> > doesn't want to worry about establishing a tunnel.  They want their
> > client to connect.
>
> You don't have to set up a permanent tunnel, but a session tunnel
> (started when the user first boots his client, or whatever) is certainly
> more efficient than setting up a secure connection per CVS invocation.
>
> > Hacks are always unecessary.  This one happens to be somewhat useful,
> > simple, and fits tidily in with the existing code.
>
> hmmm...  I'd rather see pserver ripped out entirely.  It's not even
> necessary for anonymous access.  What a waste of effort......

The actual code difference from something like a :ext: server is only around
100 or 200 lines.


> >  Besides, the pserver operation can now be tested locally (except for
> > the tcp code, which wasn't being tested anyhow) by shoving 'cvs
> > --allow-root=... pserver' in as the "socket provider".  I have my
> > entire sanity.sh script running that way with only a few
> > modifications.  This is also useful.
>
> You're running your builds and sanity.sh as root?  What a major major
> mistake that is!  You're probably wide open to remote root-level hacks!
> (they're just not directly obvious, and a bit harder to hide from
> audits)

Not at all.  I wrote the tests to log in as a bogus username and set up
CVSROOT/passwd to map to whatever username the script is running as.  Thus
the setuid suceeds...

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden         CollabNet ( http://collab.net )
--
If you can read this, please flip me back over... (seen upside down, on a Jeep)