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 firstname.lastname@example.org.
inline 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. kz