jdev - 2023-12-23


  1. kapad

    Guus: i'm not gonna say no, but it was your project that triggered me, to rethink and say, what many times i did/do alone. 1st your project is cool +1 by me. i really like the page, the animation, the code indisde, and the idea. 2nd I never put my server on that list, but that is for the reasons i say above. It was rather a theoretic/philosophic think about the general the subject. Nothing because of your project

  2. kapad

    Guus: i'm not gonna say no, but it was your project that triggered me, to rethink and say, what many times i did/do alone. 1st your project is cool +1 by me. i really like the page, the animation, the code indisde, and the idea. 2nd I never put my server on that list, but that is for the reasons i say above. It was rather a theoretic/philosophic think about the subject general. Nothing for your project

  3. kapad

    last time had to rethink my approach, was 2-3 days before when read this https://kevquirk.com/threads-and-the-fediverse . It's not i dont agree, but imo is false also.

  4. kapad

    how things works surely can affect real life. traffic, bandwidth, latency, cpus are real things. So what theoretic can also affect in real term both the quality and the infrastructure of an ecosystem. Small, less resources nodes can easily disappear out there by our practices both as users or service providers. It's easy

  5. kapad

    of course like humans, this is very familiar to us not scary at all, cause our civilization, our societies share the shame pattern. But could be interesting, if in this virtual world, can make things happen another way... An ecosystem of nodes no matter what, that freely exchange data and stanzas in a chaotic way, without that could harm or break down the machines

  6. kapad

    or the ecosystem

  7. kapad

    or the ecosystem.

  8. moparisthebest

    (disclaimer: I know others here will disagree, I speak for myself) kapad: XMPP is neutral, it's just a tool, and like any other tool, hammers, guns etc, it can be used for good or evil. The thing alone doesn't imply good or bad.

  9. kapad

    totally agree.

  10. kapad

    that's my point of thinking also right this. Because of that room, i'm sure many here have already anwrew

  11. moparisthebest

    Inevitably someone will "but design decisions make certain tech more or less likely to be used for evil" and I agree to a point, but still things useful for good will also be useful for evil

  12. kapad

    ~

  13. kapad

    i speak about use. responsible use after considering and give my view in that balance

  14. moparisthebest

    Also things change over time, when XMPP was created, the internet was a different place, no encryption was fine, but now it's under attack by pervasive surveillance and we need to encrypt *everything*, ECH is the next huge win, coming soon to an XMPP server near you

  15. kapad

    reading this, just think that another different thing nowdays, is that traffic comes from inside can also be similar dangerous as external attacks and more difficult to generally control also

  16. moparisthebest

    Inside what?

  17. moparisthebest

    The golden rule is never trust anything from the network, not even your own server as a client, it might not have validated it :)

  18. kapad

    the network/server itself. anyone can make account and communicate with anyone on any server. that's very cool.

  19. moparisthebest

    Open federated protocols are the only way to go, preaching to the choir here though

  20. kapad

    Agree. My point is not to end up with many close nodes communicate its other secretly. Cause that is not an open ecosystem. Not sure if that possible, but many depend on the practices and the use applied

  21. kapad

    but i want to keep this, in the theoretic level, so every think and have his opinion.

  22. kapad

    How things could be, there many ways...

  23. kapad

    How things could be build, there many ways...

  24. kapad

    moparisthebest: also nowdays, things go to work in more event driving and asynchronous ways. And this is something that also need special care and right design, by who setup a service

  25. kapad

    not matter what the narrative, i think things needs some HI ( human intelligence ) ;)

  26. moparisthebest

    here's a fun question that I've spent all night debugging :D when doing the STARTTLS dance with a server, after sending `<starttls xmlns='ur n:ietf:params:xml:ns:xmpp-tls'/>` which and how many characters are allowed to be sent before *actually* starting TLS ?

  27. moparisthebest

    here's a fun question that I've spent all night debugging :D when doing the STARTTLS dance with a server, after sending `<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>` which and how many characters are allowed to be sent before *actually* starting TLS ?

  28. moparisthebest

    I *think* https://datatracker.ietf.org/doc/html/rfc6120#section-5.3.3 says no characters at all, not even whitespace?

  29. jonas’

    moparisthebest: correct

  30. jonas’

    otherwise that is likely to break the TLS handshake

  31. moparisthebest

    so why do all the servers allow it ? Martin bug report :D https://salsa.debian.org/mdosch/xmpp-dns/-/blob/master/main.go?ref_type=heads#L386

  32. jonas’

    moparisthebest: it is essentially a race condition waiting to happen

  33. moparisthebest

    I made an inadvertant change in xmpp-proxy in august that broke allowing this, but didn't deploy it until my most recent change, and everything could connect except certwatch and xmpp-dns, so I've spent all night digging at TLS library versions and chasing some go/rust incompatibility and it was a newline all along haha, classic

  34. moparisthebest

    singpolyma, if certwatch uses mellium and this is where it sends that, not the same problem :'( https://codeberg.org/mellium/xmpp/src/branch/main/starttls.go#L69

  35. moparisthebest

    I wonder what prosody and ejabberd do here though, do they read and discard whitespace after that? or read until they hit 0x16 ?

  36. jonas’

    moparisthebest: I suspect the socket libraries do a full read of whatever is in the buffer

  37. jonas’

    that is likely to be starttls + a few more bytes if there are any

  38. jonas’

    it is not deliberate, I'm sure

  39. jonas’

    so if you happened to have a tcp segment boundary within that whitespace and bad timing it would break similarly with prosody

  40. moparisthebest

    I would call that a good guess, because accidentally throwing away left over data in the buffer is the bug I fixed in august which broke this :D

  41. moparisthebest

    for now here's my fix https://code.moparisthebest.com/moparisthebest/xmpp-proxy/commit/bf6500538ebec2137491fd33d7851bc77b4c4d55

  42. moparisthebest

    tl;dr just throwing away any trash left over before I get to 0x16

  43. moparisthebest

    yep I see nothing https://hg.prosody.im/0.12/file/tip/plugins/mod_tls.lua#l126 that looks like it's handling this on purpose, I guess the parser mostly gets lucky, that's enough sleuthing for me tonight, thanks jonas’ !

  44. Martin

    moparisthebest: > so why do all the servers allow it ? Martin bug report :D https://salsa.debian.org/mdosch/xmpp-dns/-/blob/master/main.go?ref_type=heads#L386 Thanks.

    👍️ 1
  45. jonas’

    moparisthebest: as clients MUST NOT send anything and they can only start tls after receiving proceed, it's luckily not really a server bug if it behaves like prosody does

  46. Guus

    kapad: I'm still not sure if your comments are a reflection of your concerns about xmppnetwork.goodbytes.im or if the discussion around that only triggered a thought process for you. If you have specific concerns around that site, I'd love to understand them. My motivation to create the site was to potentially have a show case to see how big and relevant XMPP is. I'd like to help counter the 'XMPP is dead' arguments that are making the rounds. For that to work, the site does need more than three servers that supply data of course 😁

  47. kapad

    Guus: ... only triggered a thought process for me. There is **nothing** about your project in **all** my thinking way. i **do** like it

  48. Guus

    Excellent, thanks for clarifying that.

  49. kapad english is not my native lang, so sometimes maybe i choose words more or less appropriate for what i say, `charging` them in a way that maybe cant control 100%

  50. kapad

    Guus: as said later last night, all is a matter of use. Your code is nice. if someone take it and build something `evil`, that cannot characterise you back as same. All you can do is deal with your code as you wish and imagine. The rest is in our hands, take something and build nice, useful implementations. The most possible is both will happen, but nothing you can do about

  51. Martin

    Guus: How would two domains of the same server show up? One node or two separate nodes?

  52. flow

    Martin, smae node

  53. flow

    s/same server/same XMPP domain/

  54. moparisthebest

    > moparisthebest: as clients MUST NOT send anything and they can only start tls after receiving proceed, it's luckily not really a server bug if it behaves like prosody does jonas’: don't most things just pipeline all that these days?

  55. singpolyma

    moparisthebest: certwatch does not use mellium for the probes. So the issue is sending proceed followed by a newline or similar?

  56. moparisthebest

    singpolyma: sending starttls followed by a new line (or anything)

  57. moparisthebest

    Let me know if that's the certwatch problem too, I quickly searched the code and didn't see you sending starttls, but it was late :)

  58. Guus

    > Guus: How would two domains of the same server show up? One node or two separate nodes? Before rendering the graph, the code that is running the site right now 'casts all domain names down' (removing common subdomain identifiers like "conference" and "pubsub"). The code drops all links from one node to the same node. It also deduplicates edges (there should not be more than one link between the same two nodes. This all might not be totally accurate, but it renders a cleaner graph.

  59. Martin

    Yeah, so for me diebesban.de and mdosch.de would show up as two nodes, although being the "same server". Right?

  60. Guus

    Yes.

  61. Guus

    The code looks at the reported domain names only. It doesn't know about IP addresses or hostnames of servers running the domain.

  62. Guus

    For example, IgniteRealtime.org is a cluster of two servers. It still has just one node.

  63. Guus

    Please be aware that this is the current _intent_ of the code. That is both subject to change, as well as bugs. 😁

  64. moparisthebest

    https://xmpp.org/rfcs/rfc6120.html#security-certificates-validation > If any of those validation attempts fail, the validating entity MUST unilaterally terminate the session. But... How? From the perspective of a server handling incoming S2S, just close the TCP socket? Or finish the TLS handshake just to send a stream error ?

  65. moparisthebest

    I don't read any of these as applicable https://xmpp.org/rfcs/rfc6120.html#streams-error but unsure

  66. singpolyma

    moparisthebest: yup found it https://github.com/shuque/dane/blob/master/starttls.go#L75

  67. flow

    moparisthebest, you can't send a stanza error back since no transport connection was established at that point

  68. flow

    even with STARTTLS, all you can do is to signal a error on the TLS-layer

  69. flow

    even with STARTTLS, all you can do is to signal an error on the TLS-layer

  70. moparisthebest

    > moparisthebest: yup found it https://github.com/shuque/dane/blob/master/starttls.go#L75 \r\n ? *moparisthebest shudders* Really glad you found it though :)

  71. moparisthebest

    flow: Martin says some servers send: `<?xml version='1.0'?><stream:stream from='mdosch.de' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' id='7670efde-b82b-4408-add3-125b9d151600' xmlns='jabber:server' version='1.0' to='xmpp-dns.mdosch.de'><stream:error><not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Your server&apos;s certificate could not be validated</text></stream:error></stream:stream>` Which means they finish establishing the TLS session just to do so

  72. Guus

    Do they return that as encrypted data or as plain text?

  73. lovetox

    thats nice, but somehow unexpected

  74. flow

    moparisthebest, ok, I did not consider that the server impl may still complete the TLS handshake just to terminate the connection

  75. flow

    personally, I would really avoid doing so if there is no good reason, as it could lead to such a connection still being used erronously due a programming error

  76. flow

    I also don't see the point of the validating entity telling the other entity that it failed validating it

  77. flow

    but maybe I am missing something?

  78. Zash

    I don't see the point in telling you the point

  79. moparisthebest

    Guus: encrypted, no other choice as the TLS handshake was started

  80. moparisthebest

    I just close the connection without sending the error but others don't, I was asking here which was right or better :)

  81. flow

    moparisthebest, if you do send the error, then may consider including the reason why the certificate could not be validated in the message (as opposed to the example above)

  82. flow

    moparisthebest, if you do send the error, then please consider including the reason why the certificate could not be validated in the message (as opposed to the example above)

  83. Zash

    That's the message Prosody sends when it really couldn't validate the certificate, and doesn't know why, so there's not that much more it could tell you.

  84. Zash

    Given the 'xmpp-dns' part of the addressing, I would guess that there wasn't a certificate at all.

  85. moparisthebest

    Zash: does prosody send that (or any) error when dialback is disabled and no client cert is provided?

  86. flow

    that's a pitty, so the TLS API don't tell you the reason the validation failed (like, expired cert, no trust anchor, no matching CN/SAN)?

  87. flow

    but in any case, if you have that information, then please consider it adding it to the message

  88. moparisthebest

    Depends on the TLS API

  89. Zash

    This is really demotivating after having spent a lot of work on actually returning that info in those cases.

  90. moparisthebest

    As long as it's not in violation of the RFC I think I'm going to continue just closing the socket

  91. flow

    Zash, I could tell that its demotiving from your answer above, but I didn't mean to attack you

  92. flow

    Zash, I could tell that its demotivating from your answer above, but I didn't mean to attack you

  93. Zash

    Given the modular nature of Prosody, it's hard to tell if the code that did the certificate validation 1) was actually loaded and 2) did anything.

  94. Zash

    Currently if there's no certificate sent at all, it'll say something like that, but it'll look exactly like if the module in charge of that wasn't loaded.

  95. Zash

    Expired certificates, missing indermediates, wrong names and self-signed certs are all called out in the message if that is the case.

  96. moparisthebest

    Makes sense

  97. Zash

    This is meant to make it to other server operators, who would be better of knowing *why* than just getting their connections silently closed.

  98. Zash

    OpenSSL also does not produce very good error messages. And historically did not support validating names, and still doesn't validate names the way we do in XMPP.

  99. flow

    Zash, I am curious about the "wasn't a certificate at all" part: how can this happen?

  100. Zash

    Don't send a client certificate?

  101. Zash

    Did you know that certificates are optional for both ends?

  102. flow

    is this s2s bidi or something?

  103. Zash

    No? Just any regular s2s connection where you don't send a client certificate.

  104. Zash

    I.e. the initiating entity does not send a certificate.

  105. Zash

    Receiving entity might do. That is the normal case.

  106. flow

    ok, so s2s no-dialback and the receiving entity wants to verify the initating entity

  107. Zash

    Right

  108. flow

    you may want to consider improving the wording to hint towards that eiter not certificate was presented or that the TLS stack did not perform any validation (for whatever reason)

  109. flow

    "your certificate could not be validated" gave me the impressoin that a validation on a certificate was attempted but failed

  110. flow

    "your certificate could not be validated" gave me the impression that a validation on a certificate was attempted but failed

  111. Zash

    Wording can always be improved

  112. flow

    and if there is one thing I find really annoying, then it's (error) messages like "task failed successfully (but I won't tell you why it failed)". I perfectly understand that prosody's modular architecture can make this hard or impossible.

  113. Zash

    I think this case mostly happens to tooling, like xmpp-dns or such.

  114. flow

    and if there is one thing I find really annoying, then it's (error) messages like "task failed successfully (but I won't tell you why it failed)". I perfectly understand that prosody's modular architecture can make this hard or impossible to avoid.

  115. Zash

    do any modern xmpp servers allow running without certificates?

  116. flow

    moparisthebest, does your implementation also support authenticating the initiating entity via certificates?

  117. flow

    Zash, after sending the stream error, would prosody wait for another inbound stream error?

  118. flow

    or inbound </stream:stream>

  119. Zash

    it will probably wait for </stream>

  120. flow wonders how tls-failed stream-error sending implementations would behave if *both* sides failed to authenticate the other party and send a stream error

  121. Zash

    don't reply to an error with an error and it should be fine :)

  122. flow

    if both sides failed to authentcate the other party, then it's not really a reply to an error, but a concurrent process. but irregardless, after I was made aware that this is about telling the initating entity about the failed validation, this makes much more sense to me

  123. flow

    if both sides failed to authentcate the other party, then it's not really a reply to an error, but a concurrent process. but irregardless, after I was made aware that this is (also) about telling the initating entity about the failed validation, this makes much more sense to me

  124. flow

    I am still a bit concerned about operating a TLS connection that failed validation, but I think the tradeoff shifted towards the benefit of doing so

  125. flow

    I would even encourage this to be XEP'ified so we can gater more expierence and collect those cases like both parties failing to authenticate, where we still would want to see the stream error on both ends

  126. flow

    I would even encourage this to be XEP'ified so we can gather more expierence and collect those cases like both parties failing to authenticate, where we still would want to see the stream error on both ends

  127. Zash

    We thought that the benefit of hinting operators would outweight the risk of telling attackers what they missed.

  128. Zash

    I've had "write a XEP about extended s2s errors" on my todo for over 2 years now. :)

  129. Zash

    Mostly codifying some machine-readable extended errors for this to complement the text message.

  130. Zash

    Maybe in 2025...

  131. flow

    it sure can be a little bit longer on the list, enoy the quiet days between christmas and new year. at least, that's what I am about to do now :)

  132. flow

    happy holidays everyone

  133. Zash

    Merry sleepy time y'all