connecting to wk3.org fails

agl / xmpp-client

An XMPP client with OTR support

BSD 3-Clause "New" or "Revised" License

365 stars 71 forks source link

connecting to wk3.org fails #83

Closed mdik closed 9 years ago

mdik commented 9 years ago

66161b19c6906d6f3e5c8a5ff22ad2c45c1acac3 still works, current version gives an "EOF" on or directly after starting the TLS negotiation (more complete error message when I'm back on the upgraded/defunct machine).

mdik commented 9 years ago

(6:11PM) Making connection to wk3.org:5222 via proxy
(6:11PM) Starting TLS handshake
(6:11PM) Failed to connect to XMPP server: EOF

This seems to be before Enable debug logging to /tmp/xmpp-client-debug.log? y takes effect :-(

sycamoreone commented 9 years ago

I believe this problem is due to the XMPP server not providing any of the cipher suites demanded by xmpp-client (https://github.com/agl/xmpp-client/blob/master/ui.go#L314). To confirm this you could delete the CipherSuites field from the xmppConfig, and then try to connect again.

mdik commented 9 years ago

Added "tls.TLS_RSA_WITH_AES_256_CBC_SHA," and suddenly it works. Thanks!

agl commented 9 years ago

I'm open to suggestions on this. The configuration was chosen so that only reasonable secure TLS connections are supported, but that needs to be weighed again servers like this that seem to just close the connection if a non-forward-secure ciphersuite isn't offered. Are there lots of such servers? Would it be better to connect but warn? Are more warnings just noise that will be ignored or are the users of xmpp-client sufficiently savvy that we don't need to worry about warning saturation as we do with normal software?

sycamoreone commented 9 years ago

I think it would be a great first step, if xmpp.Dial (https://github.com/agl/xmpp-client/blob/master/ui.go#L358) could return a more concrete error message explaining the problem. Then users can at least bug the server administrators about the problem.

A command line flag to disable restriction to forward-secure ciphersuites would also be an option. Then users can connect, but can't just ignore the warning.

sternenseemann commented 9 years ago

What @sycamoreone proposes sounds like a reasonable approach.