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.
Thanks a lot for your comments. After thinking about this a bit more, I came to the conclusion that the change to make "require encryption" work with Eclipse should be made in Eclipse. While I still believe that it would also be possible to make that change in CVSNT, this would only work with sserver. In the case of gssapi or sspi it wouldn't, because here wrap/unwrap are not noops. I think Eclipse needs to allow connection methods to provide their own response handlers to make this all work. "Tony Hoyle" <tmh at nodomain.org> schrieb im Newsbeitrag news:c6k9l6$88o$1 at paris.nodomain.org... > Rolf Wilms wrote: > > If you're talking about Eclipse using sserver to connect to a CVSNT set to > > "Require Encryption", then it may be related to the following problem: > > > > CVSNT expects the client to send "Protocol-encrypt" as a response when > > there is "Require Encryption". Eclipse does not know about this response. > > I see two options to resolve this problem: > > > > a) Eclipse is extended at the command level to support "Protocol-encrypt". > > Or it could send Gssapi-encrypt (which should already be supported on some > level by eclipse as it's a standard part of the original protocol). The > old name still works as a synonym even though encryption has moved on since > then. > > > b) CVSNT removes this requirement since with sserver the encryption is > > done at the connection level and "Protocol-encrypt" is a noop anyway. > > It isn't a noop - it actually changes the way the server talks to the > client. On sserver the implementation is (currently) a noop, but it's not > an optional part of the encryption process. > > It also validates that the client has stated that the protocol is in fact > encrypted - there's a handshake in which the server asks for or demands > encryption, and the client acknowledges that request. It is entirely > possible to make a plaintext sserver client - plaintext SSL exists (I may > implement it someday to support the authentication only encryption that is > currently the same as encryption on sserver). > > Tony > > >