From: Matěj C. <mc...@re...> - 2009-10-13 17:11:22
Attachments:
smime.p7s
|
Not sure much what more information is required and how to get it. My verbose gajim log is on http://mcepl.fedorapeople.org/tmp/gajim-log-pyOpenSSL.txt Unfortunately the server is behind VPN, so you have to tell me whatever tests or debugging you need to be done. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Besides, the determined Real Programmer can write Fortran programs in any language. -- Ed Post, Real Programmers Don't Use Pascal |
From: <ex...@tw...> - 2009-10-13 17:21:38
|
On 05:11 pm, mc...@re... wrote: >Not sure much what more information is required and how to get it. My >verbose gajim log is on >http://mcepl.fedorapeople.org/tmp/gajim-log-pyOpenSSL.txt > >Unfortunately the server is behind VPN, so you have to tell me whatever >tests or debugging you need to be done. There are some known interoperability issues between OpenSSL and the SSL libraries used by some Java XMPP services. If this is the problem, you can work around it by setting the OP_NO_TICKET (0x00004000) option in the client. If this doesn't fix the problem, then I don't have any other guesses as to what might be wrong. Jean-Paul |
From: Matěj C. <mc...@re...> - 2009-10-14 10:26:10
Attachments:
smime.p7s
|
Dne 13.10.2009 19:21, ex...@tw... napsal(a): > There are some known interoperability issues between OpenSSL and the SSL > libraries used by some Java XMPP services. If this is the problem, you > can work around it by setting the OP_NO_TICKET (0x00004000) option in > the client. If this doesn't fix the problem, then I don't have any > other guesses as to what might be wrong. tcpsock._sslObj.get_context().set_options(OpenSSL.SSL.OP_NO_TICK) bradford:gajim$ git diff HEAD^1 diff --git a/src/common/xmpp/tls_nb.py b/src/common/xmpp/tls_nb.py index 5ed1072..e7302a1 100644 --- a/src/common/xmpp/tls_nb.py +++ b/src/common/xmpp/tls_nb.py @@ -359,6 +359,7 @@ class NonBlockingTLS(PlugIn): tcpsock._sslObj = OpenSSL.SSL.Connection(tcpsock._sslContext, tcpsock._sock) tcpsock._sslObj.set_connect_state() # set to client mode + tcpsock._sslObj.get_context().set_options(OpenSSL.SSL.OP_NO_TICK wrapper = PyOpenSSLWrapper(tcpsock._sslObj) tcpsock._recv = wrapper.recv tcpsock._send = wrapper.send (indenting got screwed up in the email) But no observeable change happened. Matěj P.S.: BTW, would it be possible to add this list to gmane.org? I prefer it much for dealing with email lists. -- http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Those to whom evil is done \\ Do evil in return. -- W. H. Auden, September 1, 1939 http://www.poets.org/viewmedia.php/prmMID/15545 |
From: Matěj C. <mc...@re...> - 2009-11-04 15:03:40
Attachments:
smime.p7s
|
Dne 13.10.2009 19:21, ex...@tw... napsal(a): > There are some known interoperability issues between OpenSSL and the SSL > libraries used by some Java XMPP services. If this is the problem, you > can work around it by setting the OP_NO_TICKET (0x00004000) option in > the client. If this doesn't fix the problem, then I don't have any > other guesses as to what might be wrong. Currently I have this patch against the master branch of gajim (thanks partially to Dave Kirkland for this), but I haven't seen any noticeable difference ... gajim still hangs in "Initiating handshake..." diff --git a/src/common/xmpp/tls_nb.py b/src/common/xmpp/tls_nb.py index 5ed1072..fc6b496 100644 --- a/src/common/xmpp/tls_nb.py +++ b/src/common/xmpp/tls_nb.py @@ -334,6 +334,10 @@ class NonBlockingTLS(PlugIn): begin = -1 i += 1 + def info_callback(conn, where, ret): + print >>sys.stderr, "[SSL info] %x = %d" % (where, + ret)#,`conn.state_string()` + def _startSSL_pyOpenSSL(self): log.debug("_startSSL_pyOpenSSL called") tcpsock = self._owner @@ -359,6 +363,8 @@ class NonBlockingTLS(PlugIn): tcpsock._sslObj = OpenSSL.SSL.Connection(tcpsock._sslContext, tcpsock._sock) tcpsock._sslObj.set_connect_state() # set to client mode + tcpsock._sslContext.set_options(OpenSSL.SSL.OP_NO_TICKET) + tcpsock._sslContext.set_info_callback( info_callback ) wrapper = PyOpenSSLWrapper(tcpsock._sslObj) tcpsock._recv = wrapper.recv tcpsock._send = wrapper.send Any ideas what should I do? Thanks for the replies so far, Matěj Cepl -- http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Faithful love is what people look for in a person; ... -- Proverbs 19:22 (NJB) |
From: <ex...@tw...> - 2009-11-05 18:07:49
|
On 4 Nov, 03:03 pm, mc...@re... wrote: >Dne 13.10.2009 19:21, ex...@tw... napsal(a): >>There are some known interoperability issues between OpenSSL and the >>SSL >>libraries used by some Java XMPP services. If this is the problem, >>you >>can work around it by setting the OP_NO_TICKET (0x00004000) option in >>the client. If this doesn't fix the problem, then I don't have any >>other guesses as to what might be wrong. > >Currently I have this patch against the master branch of gajim (thanks >partially to Dave Kirkland for this), but I haven't seen any noticeable >difference ... gajim still hangs in "Initiating handshake..." > >diff --git a/src/common/xmpp/tls_nb.py b/src/common/xmpp/tls_nb.py >index 5ed1072..fc6b496 100644 >--- a/src/common/xmpp/tls_nb.py >+++ b/src/common/xmpp/tls_nb.py >@@ -334,6 +334,10 @@ class NonBlockingTLS(PlugIn): > begin = -1 > i += 1 > >+ def info_callback(conn, where, ret): >+ print >>sys.stderr, "[SSL info] %x = %d" % (where, >+ ret)#,`conn.state_string()` >+ > def _startSSL_pyOpenSSL(self): > log.debug("_startSSL_pyOpenSSL called") > tcpsock = self._owner >@@ -359,6 +363,8 @@ class NonBlockingTLS(PlugIn): > tcpsock._sslObj = >OpenSSL.SSL.Connection(tcpsock._sslContext, > tcpsock._sock) > tcpsock._sslObj.set_connect_state() # set to client >mode >+ >tcpsock._sslContext.set_options(OpenSSL.SSL.OP_NO_TICKET) >+ tcpsock._sslContext.set_info_callback( info_callback ) > wrapper = PyOpenSSLWrapper(tcpsock._sslObj) > tcpsock._recv = wrapper.recv > tcpsock._send = wrapper.send > >Any ideas what should I do? > >Thanks for the replies so far, This looks like the right solution for the problem I had in mind. So, I'm not sure what's going on here. Something like tlsdump may shed further light on the issue. Or, I see you're using the info callback here - is that revealing anything interesting? Jean-Paul |