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