Gajim - 2015-04-02


  1. cm hey
  2. cm is someone else getting the "insecure connection" dialogue in windows with 16.1? under linux everything works perfectly.
  3. Darlan cm, in Gajim?
  4. Darlan Oh, yes.
  5. cm yes
  6. cm but only under windows
  7. Darlan cm, what is the TLD of the XMPP server you use?
  8. Darlan TLD = Top Level Domain
  9. cm its a private xmpp server
  10. cm using tls 1.2
  11. Link Mauve cm, is your certificate correctly configured?
  12. cm yes. but it is self signed. works fine under linux.
  13. Link Mauve Have you tried with another profile?
  14. cm i could try another user
  15. Link Mauve Because self-signed cerficates should always give you that warning, if you don’t explicitely accept it.
  16. cm i got the warning under linux. and did accept it there explictly. but under windows i get only "insecure connection", where it says it would try to auth in plain text
  17. cm without any crypto
  18. Link Mauve oO
  19. Link Mauve Are you on Windows XP perhaps?
  20. cm so my guess was, that for some reasons the windows version can not talk tls1.2
  21. cm win7
  22. Link Mauve AFAIK this one shouldn’t have such issue.
  23. cm im not sure how to troubleshoot
  24. cm oh, i could check out server logs
  25. Link Mauve Yeah.
  26. Link Mauve Look at debug logs if they aren’t enabled already.
  27. Link Mauve Also, maybe launch gajim with -v.
  28. cm but still strange. since jitsi and pidgin are working fine
  29. Link Mauve It will log more things to stdout.
  30. Link Mauve They may use a different TLS stack than Gajim’s, dunno.
  31. cm i wonder, if "plaintext" auth should be even possible. tls should be required
  32. Link Mauve That’s my opinion as well.
  33. cm d
  34. cm would the output of the xml console be helpful to understanding the issue?
  35. Link Mauve Not really, but post it anyway so we can see if the server is actually offering STARTTLS.
  36. Link Mauve My guess is it does, since Pidgin and Jitsi have no problem.
  37. cm yes, thats my interpretation of this
  38. cm <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>PLAIN</mechanism> </mechanisms> <c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.process-one.net/en/ejabberd/' ver='/nWL9StXSXhEsL2wg0+s4xo/UdA='/> <register xmlns='http://jabber.org/features/iq-register'/> </stream:features>
  39. cm does that mean sth like "start tls and then send passwort plaintext"
  40. Link Mauve No, that’s it supports both STARTTLS and PLAIN over unencrypted. :x
  41. Link Mauve Ah, Ejabberd…
  42. Link Mauve You should look at disabling that offer for PLAIN.
  43. Link Mauve Really, nobody should ever propose any auth over unencrypted. :/
  44. cm i already added 'starttls_required', but i also deactivated tlsv1.1 for testing purposes, but im observer this says it is enabled :D
  45. cm IM Observer still says
  46. cm so wtf? :D
  47. Link Mauve Well, it doesn’t seem required here.
  48. cm so basically, ejabberd makes its own interpretaton of the configs :)
  49. Link Mauve :/
  50. cm thats just wrong :D
  51. cm well, but the main question is, why does gajim choose plain, if the server sais plain and tls is available
  52. Link Mauve Launch it with -v, and look at hints about it not upgrading to STARTTLS.
  53. cm gajim.exe -v doenst do anything under windows
  54. cm or is it gajim /x
  55. cm nope
  56. Link Mauve I have no idea how to do that on Windows. :/
  57. Link Mauve Try launching it from a Python console?
  58. 0xAFFE cm: there is %appdata%\Gajim and there you find gajim.exe.log and gajim.log
  59. cm found this:
  60. cm Error while TLS handshake: Traceback (most recent call last): File "c:\python27\lib\site-packages\nbxmpp\tls_nb.py", line 456, in _startSSL_pyOpenSSL SysCallError: (10057, 'Socket is not connected')
  61. cm and alot more. i dont want to spam it here. but looks like the tls handshake failed for some reason
  62. cm an OpenSSL.SSL.Error exception is caught
  63. cm it seems that it first tries tls, which failes for reasons i cannot understand from the logs, then it tries the obsolete ssl on 5223, which fails for obvious reason and then offers me plaintext auth.
  64. Link Mauve Makes sense.
  65. Link Mauve But this traceback shouldn’t happen.
  66. Link Mauve It’s at the “tcpsock._sslObj.do_handshake()” step.
  67. Link Mauve Thanks for investigating this, now I guess it’s Asterix’ turn to fix it.
  68. cm so its a bug?
  69. Link Mauve Probably, yeah.
  70. Link Mauve I can’t think of any workaround, or additional debug you could do, sorry.
  71. cm ah, no problem :)
  72. cm its always a process :)