XSF Discussion - 2018-03-23

  1. Ge0rG

    Sigh. How one should not design XMPP clients: https://github.com/KaidanIM/Kaidan/issues/220

  2. Kev

    Swift autoaccepts requests too, but only for bidirectional

  3. Kev

    (If you send a subscription request to someone, it'll approve the one they send back)

  4. jonasw

    that makes sense

  5. daniel

    > (If you send a subscription request to someone, it'll approve the one they send back) Conversations does that too.

  6. daniel

    Even though that's actually what pre-approval is for

  7. Ge0rG

    it makes sense in a world where subscription shouldn't consist of directed graphs

  8. daniel

    Or pre Auth

  9. Ge0rG

    except pre-approval is not guaranteed

  10. daniel

    What ever that was called

  11. Ge0rG

    yaxim will do both

  12. Kev

    But Swift doesn't talk about subscription requests, it just talks about Add Contact.

  13. daniel

    Did ejabberd start announcing that stream feature?

  14. daniel

    Because at some point it had support but didn't announce the feature which doesn't make sense this the RFC tells clients to only use it if the feature is announced

  15. Ge0rG

    I wonder how many of my Swift issues got fixed for 4.0.

  16. Ge0rG

    daniel: I'm using it anyway.

  17. Ge0rG is a lazy and ignorant client dev

  18. jonasw

    Ge0rG, you do know that prosody doesn’t support it?

  19. Ge0rG

    jonasw: I know.

  20. Ge0rG

    jonasw: but what's the worst thing that can happen if I send a pre-approval to a non-supporting server?

  21. jonasw

    <malformed-request/> stream error.

  22. daniel

    Stream error

  23. daniel


  24. jonasw

    ah, <invalid-xml/>

  25. Ge0rG

    but it is valid xml. It just comes at the wrong time

  26. jonasw

    Ge0rG, invalid XML is for things which do not pass schema validation

  27. Ge0rG

    she-what? :P

  28. jonasw

    granted, I’d argue that such a server would be pretty weirdly designed to be gin with

  29. jonasw

    granted, I’d argue that such a server would be pretty weirdly designed to begin with

  30. Ge0rG

    jonasw: auto-generated by the schema-to-code thing we talked about yesternight.

  31. Ge0rG &

  32. jonasw


  33. Ge0rG

    Bad memory access (SIGBUS)

  34. lovetox

    in attic there is missing version 3.0 and 3.1 of httpupload https://xmpp.org/extensions/xep-0363.html

  35. jonasw

    there is no 3.0

  36. jonasw

    or 3.1

  37. jonasw

    do you mean 0.3.0 and 0.3.1?

  38. jonasw

    (which are also missing, indeed)

  39. jonasw

    I’ll regenerate them

  40. lovetox

    yes i meant those

  41. jonasw

    will be up shortly

  42. lovetox


  43. jonasw

    spoiler: 0.3.1 is only a typo fix ;)

  44. jonasw

    lovetox, will be available within the next five minutes

  45. Ge0rG starts tea timer

  46. lovetox

    what funny attack can you do if you have newline chars in a header value

  47. lovetox

    talking about httpupload

  48. jonasw

    lovetox, escape from the header, depending on the brokenness of implementations involved

  49. lovetox

    the authorizartion value is base64 encoded

  50. lovetox

    this means i execute on that value .strip('\n')

  51. lovetox

    not decode it and execute it on that

  52. MattJ


  53. lovetox

    kk thanks

  54. jonasw

    lovetox, that’s not sufficient

  55. MattJ

    The client is not expected to understand what the headers are

  56. jonasw

    .replace("\n", "") is safer

  57. jonasw

    or if "\n" in header_value: raise RuntimeError("gtfo")

  58. lovetox

    thats indeed better

  59. lovetox

    i should just not upload to a service providing xep violating stuff

  60. jonasw


  61. lovetox

    ups strip is only for beginn and end, indeed that would not be enough

  62. jonasw


  63. Ge0rG

    Http upload is a small security nightmare.

  64. Ge0rG

    BTW, was there a change already restricting the legal header values?

  65. Ge0rG

    > Requesting entities MUST ensure that only the headers that are explicitly allowed by this XEP (Authorization, Cookie, Expires) are copied from the slot response to the HTTP request. Ah, yes. But it's still not enforced at protocol level

  66. rion

    I've applied this restriction to Psi

  67. Ge0rG

    > MUST strip any newline characters I wonder whether "newline characters" is too vague, as it's implementation defined

  68. moparisthebest

    has anyone tried (ab)using SOCKS5 Bytestreams https://xmpp.org/extensions/xep-0065.html to poke at internal network stuff?

  69. moparisthebest

    there aren't any security considerations about it

  70. rion

    Do you mean sending something w/o opening filetransfer session of something?

  71. rion

    of traffic encryption

  72. Zash

    moparisthebest: but both parties connect to the server, the server doesn't initiate anything outbound

  73. Zash

    moparisthebest: you might be able to trick remote clients into such things tho

  74. moparisthebest

    like, the server has access to a 10.X.X.X private subnet external users do not have access to, can an external client do bad things

  75. moparisthebest

    yea that's another way to do it

  76. Ge0rG

    You'd have to trick the client to connect to a "proxy" you defined

  77. Zash

    I forget the details, but doesn't one party pick the proxies, the other responds with one it can connect to.

  78. Ge0rG

    I never knew the details, so...

  79. peter

    interesting reading: https://irisate.com/crdt-for-real-time-collaborative-apps/

  80. MattJ

    It feels like only yesterday when Operation Transformation was the best thing ever

  81. Kev

    You've gotten old.

  82. MattJ


  83. MattJ


  84. Kev

    Don't feel bad, I'll catch up soon.

  85. lovetox

    i found this in gajim code

  86. lovetox

    when creating TLS connection we pass a cipher list

  87. lovetox


  88. lovetox

    it this up to date?!

  89. lovetox

    i have no clue about ciphers :/

  90. Zash

    If it's using a modern OpenSSL then I don't think you need to worry.

  91. Zash

    Only 'HIGH' seems to matter. Removing ciphers without authentication (aNULL) from the set of "highly secure" ciphers (HIGH) does nothing.

  92. Zash

    And RC4 doesn't seem to exist anymore.

  93. SamWhited

    Still, that doesn't seem like a good sign…

  94. Holger

    Zash: Unless things changed recently, HIGH does include aNULL ciphers.

  95. Zash


  96. Zash


  97. Zash

    Hidden among all the various auth mechanisms that aren't used either

  98. SamWhited

    I'm more concerned that they would try to select RC4, regardless of whether it still exists in openssl or not.

  99. Zash

    $ diff -u <(openssl ciphers -v HIGH) <(openssl ciphers -v 'HIGH:!aNULL')|q https://q.zash.se/324a465c00bf.txt

  100. Zash

    on Debian Stable with OpenSSL 1.1.0f

  101. Zash

    SamWhited: It's pretty good compared to cipher lists like this: https://q.zash.se/da0ffe1f3f82.txt

  102. SamWhited

    What's that from?

  103. Zash

    Oooooooooold Jitsi

  104. Zash

    Possibly from 2013

  105. Zash


  106. Zash

    From those days

  107. SamWhited

    fun… Java things always seem to be behind.

  108. SamWhited

    huh, apparently RC4 was considered broken later than I thought

  109. Zash

    Defaults were pretty bad back then in most things.

  110. SamWhited

    Still though, if you're still recomnending it today that's a pretty big red flag for gajim…

  111. Zash

    Hasn't RC4 been considered "icky but let's not worry too much about it" since forever?

  112. SamWhited

    I was thinking it was late 2013, but apparently it was 2015 that the IETF stopped telling people to use it in TLS.

  113. Zash

    Comparing the current situation with that post would probably be interesting.