XSF Discussion - 2018-07-23


  1. Ge0rG

    Link Mauve: sorry for blaming you yesterday. You were not at fault. It was an obscure bug in smack3's handling of unknown stanzas.

  2. Link Mauve

    Ge0rG, no problem. ^^

  3. Link Mauve

    I was surprised because I wrote these modules very defensively.

  4. Ge0rG

    Who could have expected that `parseIQ()` returns the parsed IQ for most cases, except for a GET or SET with unknown payload, where it just injects a not-implemented response and returns null.

  5. jonasw

    s/smacks3/smacks4/?

  6. Ge0rG

    no idea how smack4 does it

  7. flow

    Smack 3 has no support for stream management, I assume we are talking about a patch someone put on top of a Smack 3 codebase

  8. Ge0rG

    flow: yes, a patch that's using Connection.addPacketListener() to keep track of stanzas.

  9. flow

    Ge0rG, let me know if you ever want to switch to a recent release of smack and need help

  10. jonasw

    I think both of that is the case :)

  11. Ge0rG

    flow: I'm grateful that you took the time to integrate smack4 back then, and I'm sorry that it happened on an oldish branch and I never managed to forward-port it.

  12. Ge0rG

    flow: I really want to switch to most recent smack4, and I don't have illusions about the required effort.

  13. Guus

    o/

  14. jonasw

    Guus ^_^

  15. MattJ

    \o

  16. Guus

    I'd like to do some interop testing

  17. jonasw can offer a client

  18. Guus

    does someone has a server available that does S2S over DirectTLS?

  19. jonasw canโ€™t offer that

  20. Guus is sad

  21. jonasw

    metre might be able to do such a thing

  22. Holger

    Guus: conversations.im

  23. jonasw

    .oO(S2S over DirectX)

  24. jonasw

    .oO(S2S over DirectPlay)

  25. Guus

    snap out of it! ๐Ÿ˜ƒ

  26. Guus

    thanks Holger

  27. Ge0rG

    Guus: I have mod_net_multiplex loaded on xmpp.yaxim.org:443, but IIRC not in the SRV records.

  28. Guus

    Thanks Ge0rG. I was just checking for SRV records on conversations.im ๐Ÿ™‚

  29. Holger

    Ge0rG: That way you can do TLS-on-connect for s2s connections?

  30. Ge0rG

    Holger: I hope so

  31. jonasw

    itym you wish

  32. Ge0rG

    Somebody could attempt an s2s handshake there.

  33. MattJ

    I don't see why it wouldn't work

  34. jonasw

    if I only knew the xmlstream namespace by heart

  35. Holger

    MattJ: Well it won't teach Prosody to do XMPPS for outgoing connections, will it?

  36. MattJ

    No, not for outgoing

  37. Holger

    MattJ: For incoming connections, EXTERNAL auth and/or Dialback will be fine?

  38. MattJ

    Yes?

  39. Holger

    Nice :-)

  40. jonasw

    Ge0rG, appears to work

  41. jonasw

    SENT: <stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' to='yax.im'> RECV: <?xml version='1.0'?><stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='yax.im' id='b63d1089-0aa0-4bd4-b5b4-4deb3efe83e2' to='' version='1.0' xmlns='jabber:server'><stream:features><dialback xmlns='urn:xmpp:features:dialback'/></stream:features> SENT: <stream:error><undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>no</text></stream:error> RECV: </stream:stream>

  42. jonasw

    even without xml header :-X

  43. MattJ

    The XML header isn't mandatory

  44. Dave Cridland

    Guus, dave.cridland.net should have XEP-0368 on inbound and outbound, and use the right SRV records.

  45. Guus

    Dave, excellent, as you might be the one reviewing this new Openfire code ๐Ÿ™‚

  46. Dave Cridland

    Guus, If you want to set up your own test, then it's just Metre, and I can help you figure out a config file to let you ping Metre on its own.

  47. Guus

    Thanks, maybe later Dave. Right now, I'd like to see if I can test this without adding another new component to the mix

  48. Guus

    also, crappy camping wifi /me raises fist

  49. Guus

    Dave, we miss you in open_chat, by the way

  50. MattJ

    Pft, I just got back from a camping trip with no wifi and no phone signal

  51. Guus

    "In my day, we rocket-jumped to school and back!"

  52. Guus

    well, failure on both ends ๐Ÿ˜ž

  53. Guus

    but I'm still using a self-signed cert, that probably doesn't help

  54. Guus does the Let'sEncrypt dance

  55. Guus

    right, using a proper certificate made all the difference. I think that directTLS from Openfire to dave.cridland.net and conversations.im is now working.

  56. Guus

    If someone would be willing to shoot some (direct TLS) s2s tests at goodbytes.nl, I'd be grateful.

  57. Dave Cridland

    Guus, It looks like movim.eu is also using XEP-0368 - unless I can't read my own logs.

  58. Guus

    No SRV record found for: _xmpps-server._tcp.movim.eu.

  59. Dave Cridland

    Guus, Yeah, but it seems to use it to me. Maybe.

  60. Guus

    that's entirely possible

  61. Guus

    for the record, I've disabled the lookup of _xmpp-server on goodbytes.nl, to force _xmpps-server lookups for the purpose of this test.

  62. Dave Cridland

    Guus, I found one tricky bit was to combine the two SRV lookups into a single one for the purposes of the SRV selection algorithm neatly.

  63. intosi

    Guus: why is it offering starttls when you connect on port 5270?

  64. Guus

    Dave, why not do two SRV lookups and combine the results manually?

  65. Guus

    intosi: because the code is a mess and I didn't add a proper condition there, most likely.

  66. intosi

    Fair enough.

  67. Guus

    Openfire's S2S code is using the pre-Java NIO blocking way of doing things. We've ment to replace it ages ago, but it continues to survive. Now this is bolted on

  68. Guus

    it's not pretty...

  69. intosi

    Old code doing things that aren't pretty, a fate not unique to your code ;)

  70. Guus

    I think I fixed it. I'll redeploy

  71. intosi

    Grand :)

  72. Guus

    intosi, mind trying again?

  73. Guus

    linkmauve, Openfire thinks it's funny that your cert chain contains multiple certs with identical IssuerDN's

  74. intosi

    Looks good to me, thanks!

  75. Link Mauve

    Guus, check.messaging.one too.

  76. Guus

    thanks guys

  77. Guus

    Link Mauve, I _think_ that the reason for Openfire to complain about this is that it tries to recreate the chain (matching subject and issuer of individual chains). That works around a problem where chains were provided out of order, iirc.

  78. Guus

    it now picked the last cert in the chain, as that's typically the EE cert.

  79. Link Mauve

    Oh, my renew script uses cat twice; why?!

  80. Ge0rG

    two cats are better than one

  81. Guus

    two cats is obviou...whathesaid

  82. Link Mauve

    Guus, better now?

  83. Guus

    Link Mauve, yes it stopped warning me.

  84. Guus

    I think we did StartTLS and not DirectTLS, by the way

  85. Guus

    _xmpps-server._tcp.linkmauve.fr does not seem to exist.

  86. Link Mauve

    Yes, indeed.

  87. Link Mauve

    I donโ€™t do legacy TLS on this server.

  88. Guus

    ok, but that's what I was testing in the first place ๐Ÿ™‚

  89. Ge0rG

    "legacy TLS"? What's that now?

  90. Guus

    Yeah, Openfire sadly refers to direct tls as 'legacy' in various places too ๐Ÿ˜ž

  91. Guus

    I think we even have an issue for that, to change that into 'direct'.

  92. Ge0rG

    because it was used on port 5223 for clients before starttls became a thing

  93. Guus

    stems from the introduction of StartTLS that was considered the new holy grale, replacing everything else...

  94. Ge0rG

    Yeah. We were naive back then.

  95. Holger

    Guus: > using a proper certificate made all the difference. I think that directTLS from Openfire to dave.cridland.net and conversations.im is now working. conversations.im should also accept Dialback auth, by the way.

  96. MattJ

    And we're not now

  97. Holger

    ๐Ÿ™‚

  98. Guus

    Holger: I was forcing direct TLS

  99. Holger

    Guus: Shouldn't Dialback auth work with direct TLS?

  100. Guus

    Holger, yes, but with direct TLS, you didn't like my self-signed cert, I think. Didn't even get to start dialback

  101. Holger

    Hmm, maybe something wrong on our side. I'll check.

  102. Guus

    if somethings wrong, it's probably on this side ๐Ÿ™‚

  103. Holger

    But I remember at least one versions of Openfire and ejabberd not being big friends when it came to Dialback auth in the past.

  104. Holger

    Forgot the details, and whether the issue was resolved at some point.

  105. Guus

    Holger, that's probably many moons ago.

  106. Holger

    *at least old versions

  107. Holger

    Guus: Yeah may well have been fixed long ago.

  108. Guus

    Holger: if you do find new issues, please let me know

  109. Holger

    Will do.

  110. Holger

    Dave Cridland: > but it seems to use it to me. Yes all recent ejabberds will attempt direct TLS if DNS tells them to do that.

  111. Guus

    Holger: do you prefer that over StartTLS, or do you adhere to prio / weight of SRV records?

  112. Holger

    We adhere to the prio/weight, I think the XEP tells you to.

  113. Holger

    > Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record with regard to connection order as specified by RFC 2782 [3], in that all priorities and weights are mixed.

  114. Holger

    > This enables the server operator to decide if they would rather clients connect with STARTTLS or direct TLS. However, clients MAY choose to prefer one type of connection over the other.

  115. Holger

    But you're not a client! ;-)

  116. Guus

    exactly.

  117. Guus

    'peer' ๐Ÿ™‚

  118. Guus

    just wondering. So it's a coincidence that you did directtls with dave

  119. Guus

    assuming he has both SRV records, I didn't check.

  120. Holger

    Ah he has both, but both with the same prio/weight.

  121. Holger

    Just checked, in that case (same prio/weight) we prefer direct TLS indeed.

  122. Guus

    why? shouldn't you do 50/50?

  123. daniel

    Faster

  124. daniel

    It's arguably better and if the admin didn't set a preference (which I would respect) I'd prefer direct

  125. Guus

    sure, but still - if the SRV records are set up with the same prio/weight, shouldn't the connection attempts be distributed evenly?

  126. daniel

    According to the xep which says combine the two the answer is yes

  127. daniel

    But I don't agree

  128. SamWhited

    (I am also still against that wording and think it makes no sense to combine the two)

  129. daniel

    I mean honering the prio makes sense

  130. daniel

    But honering the weight doesn't

  131. Guus

    I'm not sure it'd be a good idea to deviate from standard SRV semantics, if we use them.

  132. daniel

    Weight is load management. And why would you manage load between direct and start

  133. Guus

    sure, but then instruct/suggest to admins to use different prio's

  134. Guus

    (or: don't combine the two, sure)

  135. Holger

    Guus: Yes, strictly speaking you're right of course.

  136. Guus

    Holger, I don't think I am. They're different SRV records. It's only because the XEP tells us to combine them, ...

  137. Guus

    (records for different services, I mean)

  138. jonasw

    Guus, there is no such thing as "standard SRV semantics" when mixing two types of SRV records

  139. jonasw

    thatโ€™s an invention of XEP-0368

  140. Guus

    jonasw, that's pretty much what I just typed ๐Ÿ™‚

  141. Holger

    Yes I mean you're right that it goes against the XEP words to prefer one type.

  142. Guus

    or intended to, at least

  143. jonasw

    what

  144. jonasw

    I am not sure whether my client has shown your messages before it has shown mine

  145. jonasw

    *shrug*

  146. Holger

    jonasw: The XEP tells you to mix the records as if both were of the same type, and to then apply standard SRV semantics.

  147. Guus

    jonasw: just nod and agree with me that I was wrong ๐Ÿ™‚

  148. jonasw

    Iโ€™ll just walk away and water the plants instead! ha!

  149. Guus

    jonasw, how often did we ask you to not water the plastic plants?!

  150. jonasw

    Guus, those ainโ€™t plastic!

  151. jonasw

    https://uc.xmpp.zombofant.net/1af3e64c-98e4-4f39-b92b-df826fe9a97a/IMG_20180723_170548.jpg

  152. daniel

    2 megabytes? I hope those will be some nice plants

  153. daniel

    Once I've finished downloading that in like half an hour

  154. jonasw

    daniel, https://uc.xmpp.zombofant.net/b607154c-4bec-495e-a513-3a3521a2b192/foo.jpg is that helpful? :)

  155. jonasw

    if we had SIMS deployment, I couldโ€™ve uploaded multiple versions (or have my server rewrite that)

  156. Dave Cridland

    Holger, If the prio/weight is the same, what does it mean to "prefer" one? You bias the weight, or are you using weight like priority?

  157. Holger

    Dave Cridland: No I meant if there's an _xmpp-server. and an _xmpps-server. record and both have the same prio and the same weight (like you have for your server), we'll prefer the _xmpps-server. record. While the XEP tells us not to do this but to choose one at random instead.

  158. Dave Cridland

    So what do you do if the _xmpp-server has weight 4, and the xmpps_server has weight 5?

  159. Dave Cridland

    Do you not choose one at random then?

  160. Holger

    Then we do :-)

  161. jonasw

    hm

  162. jonasw

    thatโ€™s a very weird corner case youโ€™re constructing there

  163. Dave Cridland

    Holger, What, so you're literally special-casing equal-wieght?

  164. Holger

    Oh! Ignore me.

  165. jonasw

    I wouldโ€™ve understood if you preferred direct TLS on equal prio, but ... special casing equal weight is weird

  166. Holger

    Well don't ignore me :-)

  167. Dave Cridland

    (FWIW, I could totaqlly go along with that when all weights are zero)

  168. Holger

    Dave Cridland: Yes exactly. _xmpps-server is only preferred if the weithts are zero.

  169. Holger

    Sorry.

  170. Dave Cridland

    Holger, Ah! OK, that makes sense - you're faced with something illegal so you take a policy view.

  171. jonasw

    refresh my memory, why is it illegal?

  172. Dave Cridland

    jonasw, Because you're meant to randomly select a specific record ( weight / [total weights] ) of the time.

  173. jonasw

    yes

  174. Dave Cridland

    jonasw, If all weights are zero, then you're picking each record 0/0 of the time.

  175. Dave Cridland

    jonasw, However, a weight *can* (and should, maybe) be zero if it is the only one - and that might occur by accident if there's only one *each* of _xmpp-server and _xmpps-server.

  176. jonasw

    hm

  177. jonasw

    the text in RFC 2782 (DNS-SRV) actually tells you how to deal with (even multiple) records of weight zero, even in presence of records which have non-zero weight

  178. Holger

    > So it's a coincidence that you did directtls with dave So turns out the answer is "yes", after all.

  179. Dave Cridland

    jonasw, Yes, indeed. So "illegal" is an incorrect assertion. But still, Holger's "if everything is weight zero, do TLS" is fine.

  180. jonasw

    but DNS-SRV allows for "additional weighting information"

  181. jonasw

    in which case everything said there about how weights are used is irrelevant it seems

  182. Dave Cridland

    Well. XEP-0368 says (I paraphrase) combine all the SRVs and then do RFC 2782.

  183. Guus

    Dave, I've got that XEP-0368 PR up for you to review, btw ๐Ÿ™‚

  184. Guus

    still trying to lure you back in...

  185. Dave Cridland

    Guus, Yeah, I might even get to that.

  186. Dave Cridland

    Guus, Doing it now in fact.

  187. Guus

    \o/

  188. Guus

    (maybe have tissues ready for the occasional wiping of tears)