XMPP Service Operators - 2019-08-19


  1. tom

    Is there any reason not to allow http plaintext connections to your http_upload server?

  2. Holger

    tom: I'd ask about the Gajim stuff in the Gajim room.

  3. Holger

    tom: > Is there any reason not to allow http plaintext connections to your http_upload server? Sure, you might not want to allow the man in the middle to intercept your users' uploads.

  4. tom

    but is there any reason to make https mandatory instead of optional?

  5. tom

    having https as an option metigates that, but as a cdn, Is it not good to allow plaintext access as well?

  6. Holger

    The upload extension doesn't support offering more than a single URL.

  7. Holger

    So you can't offer the client to choose between HTTP and HTTPS.

  8. tom

    true, but clients (not uploaders) downloading static content can overide the https to do http

  9. Holger

    Just blindly try HTTP and retry via TLS if that fails?

  10. Holger

    If people wanted this behavior it would make more sense to extend the spec accordingly. But I doubt you'll convince people in these HTTPS-everywhere times.

  11. Licaon_Kter

    tom: what's the usecase for non-httpS ?

  12. tom

    well, for static content that's not confidential

  13. tom

    for private conversations OMEMO would encrypt anyways

  14. tom

    http is less overhead and can be easily cached my client-side proxies like squid or polipo

  15. tom

    *by

  16. tom

    also, when I do TLS I set it up right. so that means blacklisting all insecure cihpersuites

  17. tom

    which realisticly only allows chacha20 and AESG

  18. tom

    the worst thing I want to do is provide a false sense of security. where if you turn on https and I want to be secure, but if you use http on purpose you don't have the illusion of security

  19. tom

    *AESGCM

  20. tom

    older clients may not be able to speak TLSv1.2: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384

  21. Holger

    All other ciphersuites are "insecure", sure.

  22. tom

    give or take a few cipher modulo and hash length 128/256/384

  23. jonas’

    that’s not even TLSv1.3

  24. Holger

    I'm convinced it makes sense to break interop (i.e. better don't get the cat pic at all than to take the risk) by not offering ciphers such as, say, AES-128-CBC-SHA one someone shows how exactly to break it.

  25. tom

    what about tls 1.3?

  26. Holger

    I'm convinced it makes sense to break interop (i.e. better don't get the cat pic at all than to take the risk) by not offering ciphers such as, say, AES-128-CBC-SHA once someone shows how exactly to break it.

  27. tom

    nevermind

  28. tom

    I'm not asking about my cipherlist

  29. Holger

    tom: Sure, you're just making the point that you need HTTP for interop because you can't offer HTTPS except with a super-restrictive cipherlist because anything else would impose a false sense of security 🙂

  30. tom

    well not exactly. I don't /need/ plaintext access I'm just wondering if there should be any plaintext access

  31. tom

    no clients have problems with my restrictive cipherlist that I know of

  32. pep.

    Let's just use http everywhere because TLS is not perfect anyway and it provides a false sense of security :)

  33. jonas’

    that’s the usual symptom of restrictive cipher lists

  34. Holger

    tom: Well many have. But whatever. I do see your points about overhead and proxies. I just doubt you'll convince people.

  35. jonas’

    I didn’t notice that I lost connectivity to jabber.ru until someone pointed it out out-of-band *shrug*

  36. jonas’

    I didn’t notice that I lost connectivity to jabber.ru until someone pointed it out out-of-band

  37. jonas’

    I didn’t notice that I lost connectivity to jabber.ru due to TLS foo until someone pointed it out out-of-band

  38. pep.

    Also tom it'd be great if you stopped taking over this channel for every single topic you want to talk about. Please

  39. jonas’

    it *is* operations, pep.

  40. jonas’

    it *is* related to operations, pep.

  41. tom

    > I do see your points about overhead and proxies. I just doubt you'll convince people. I'm not worried about convincing people, I'm just wondering if there is any other scenario besides the proxy example

  42. pep.

    jonas’: it started with gajim and jingle

  43. jonas’

    I didn’t scroll up that far

  44. tom

    >pep.‎: Also tom it'd be great if you stopped taking over this channel for every single topic you want to talk about. Please this channel is idle 90% of the time. If anybody else has a topic they'd like to talk about nothing's stopping them from bringing it up

  45. pep.

    It's idle 90% of the time so what. Let's all have a single channel with every xmpp users so that it's not idle at all?

  46. Holger

    tom: That's the usual response of people being asked to stay on topic. The problem is not everybody joined here is interested in having his phone beeping when it's about Jingle for Gajim. I'm not, for one.

  47. tom

    maybe the gajim conversation was a bit offtopic

  48. Holger

    (Personally I *am* somewhat interested in Gajim and Jingle, but I joined this room with the phone to be notified of actual operators stuff quickly; while I'm joined to the Gajim room only on my desktop. Just to give an example.)

  49. tom

    sure

  50. pep.

    tom: fwiw, join the gajim room and talk about what you want to do re UI, and the codebase in there. The current maintainer has done a huge amount of work cleaning it up, there are probably parts you can merge in your potential 0.16 fork if it happens

  51. pep.

    Ah you have joined, cool :)