[cvsnt] pserver && encryption

Keith D. Zimmerman keith at eagle-solutions.com
Thu Jun 5 22:33:51 BST 2003

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


keith d. zimmerman, mcsd 
eagle solutions

> -----Original Message-----
> From: Tony Hoyle [mailto:tmh at nodomain.org] 
> Sent: Thursday, June 05, 2003 5:26 PM
> To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> Subject: RE: [cvsnt] pserver && encryption
> Keith D. Zimmerman wrote:
> > Yes, but it appears to me that the client sent the password 
> before it
> > even realized pserver was not supported...  This seems like 
> a possible
> > vulnerability, not?  If the clueless user tries to connect 
> via pserver,
> > you have domain passwords flying across the internet, not?
> encryption encrypts the content, not the passwords - pserver 
> passwords are
> sent far too early in the protocol to be changed in any way 
> (unfortunately
> pserver has no negotiation stage at all, so you can't change 
> it without
> breaking compatibility with the cvshome.org version).
> Since sserver doesn't have to be compatible with anything 
> except cvsnt it
> encrypts before the password is sent, so it's never 
> vulnerable in that way.

So there would be no way other than user education to prevent the
clueless from spewing passwords across the untrusted network using
pserver, correct?

> > Can you be more specific with this "strict checking" 
> option...  If I use
> > a cert server (cacert.org, for instance) but don't turn 
> strict on, does
> > the client simply not bother to check with the authority?
> > 
> With strict checking, the client will check that the 
> certificate is signed
> by a recognised authority (verisign, cacert, etc.) and that 
> the CommonName
> is identical to the host name requested by the client.  Assuming the
> certificate authority hasn't been compromised you can then be certain
> nobody has hijacked the connection (this is basically what 
> HTTPS does).
> Without strict checking, it does all of the above for normal 
> certificates,
> but also allows self-sign certificates...  since anyone can generate a
> self-sign certificate you are far less sure that the other 
> end is really
> who they say they are (I might introduce some kind of 
> fingerprinting like
> ssh uses to detect certificate changes... this would at least 
> tell you the
> host was the same one you contacted last time).

"all of the above" - so even if strict checking is off, it'll still say
the certificate is invalid if it comes from cacert/verisign, but has
been revoked, or is invalid according to the cert authority, or the
CommonName does not match?	

> Tony
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs

Thanks once again for your help.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook