jdev - 2023-10-22

  1. lovetox

    the channel binding thing that was mentioned, only works of course if the client is save against downgrading attacks

  2. lovetox

    not exactly sure how that needs to be done, tell the user once the server does not offer scram+ anymore?

  3. lovetox

    and then let him decide?

  4. pulkomandy

    Someone mentionned https://xmpp.org/extensions/xep-0474.html which lists various options (and introduces some new ones, but even without that part is an interesting read)

  5. lovetox

    btw, does this mean if i implement this, my client will not operate anymore in company networks that do this kind of proxy mitm stuff?

  6. lovetox

    so, actually one would need to make this optional and user would need to activate it

  7. lovetox

    this XEP outlines a few attacks, but i dont really see the benefit of trying to do more on the protocol side

  8. lovetox

    i simply pin the mechanism, and inform the user if it changes

  9. lovetox

    should be fine, and much easier to implement ?

  10. pulkomandy

    that's the "Case 4" in that xep, you can decide if the possible problems listed there are acceptable or not (if your first connexion is compromised/degraded, you now notice a problem only when you connect to the correct server ; and, if the server is updated to introduce new, stronger types, you won't use them and will keep using the older pinned one)

  11. MattJ

    lovetox, yeah, there are definitely situations where channel binding would be expected to fail - some corporate/educational networks for example, and the user may prefer being able to communicate with an acknowledged MITM than not being able to communicate at all

  12. MattJ

    Such situations would likely be where the network has a custom certificate already installed on the device trust store

  13. lovetox

    MattJ, currently Gajim does not support channel binding

  14. lovetox

    is this XEP-0440: SASL Channel-Binding Type Capability

  15. lovetox

    widley supported?

  16. lovetox

    and can i assume that every server supports tls-unique?

  17. lovetox

    there is also this server-end-point thing

  18. lovetox

    somewhere i read server must support tls-unique

  19. lovetox

    so no need as a client to implement server-end-point, right?

  20. lovetox

    so i can i simply implement tls-unique for TLS 1.2 and exporter for TLS 1.3?

  21. lovetox

    do i really need to parse the type capabilities of the server ?

  22. MattJ

    lovetox, tls-unique is only for use with TLS 1.2, which is not common these days. If you have the choice, only support tls-exporter for future-proof code

  23. MattJ

    server-end-point is compatible with both, and may be used by some deployments that have intentional "MITM" devices such as load balancers

  24. MattJ

    Less common setup, but they will exist

  25. MattJ

    The problem is that SCRAM doesn't tell you which one the server is using, and if the client and server pick different ones, it will fail

  26. MattJ

    It's a flaw in SCRAM really, but XEP-0440 fixes it

  27. MattJ

    The HT token mechanisms we use in FAST encode the channel binding method in the mechanism name

  28. singpolyma

    Zash: the dane srv rfc suggests that "sni or equivalent" (and explicitly mentions xmpp stream to) be set to the target name not the service name. Since this would mean the server actually has no idea what service you're talking about i assume you just ... Don't do this?

  29. singpolyma

    The testing tool I'm forking seems to use target name for actual sni and service name for stream to. So it can work for at least startssl but probably breaks direct tls...

  30. Zash

    singpolyma, yeah that part is weird

  31. moparisthebest

    singpolyma: in the case of DNSSEC validated records you basically need to try connecting twice for each SRV record, once for each SNI name...

  32. Zash

    That sounds annoying

  33. moparisthebest

    It is, but it's all I've got :)

  34. moparisthebest

    There's no "right" choice when it comes to SRV records, no way to signal which SNI to use, and non-dnssec clients can only use 1

  35. moparisthebest

    My solution for this is to abandon srv records for a well-known https GET which does have what-to-send for SNI defined :'(

  36. singpolyma

    I mean, the only choice that can possibly work is service name. That's just unfortunately the opposite of what the rfc suggests

  37. singpolyma

    The server doesn't serve any services at the hostname so using that for SNI would just return an error

  38. moparisthebest

    SNI is for picking certificates, something else is for picking services, in HTTP that's the Host: header

  39. singpolyma

    You can have two ways sure, though the rfc intentionally tries to include them rll by saying "or sni like thengs such as XMPP stream to"

  40. singpolyma

    But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service

  41. singpolyma

    Also given what we recently had confirmed about the fragility of TLS CA trust I'm even less ok with https based discovery than i used to be

  42. Zash

    Move over to SVCB?

  43. Zash

    It's extensible so we can jam *everything* into it. A+AAAA+DANE+port numbers etc

  44. moparisthebest

    That's the problem though, in theory yes, in practice we'd need to define our own type (like https did) and then try to get DNS hosts to support it and it'd never happen

  45. moparisthebest

    > But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service Really? Strange, I just have one wildcard cert per server

  46. Zash

    > Really? Strange, I just have one wildcard cert per server That'll come in handy if that cert is ever compromised, it'll be useful for so many attacks on all kinds of services!

  47. moparisthebest

    > Also given what we recently had confirmed about the fragility of TLS CA trust I'm even less ok with https based discovery than i used to be It's ok because the HTTPS connection is protected by DANE and/or HPKP

  48. singpolyma

    >> But also this is about cert too since obviously I don't have just one cert for my whole server but rather one per service > Really? Strange, I just have one wildcard cert per server I have dozens of domains on my server though

  49. moparisthebest

    > You can combine multiple hostnames into a single certificate, up to a limit of 100 Names per Certificate. I had to look this up, anyway that's enough for 50 domains in 1 cert

  50. singpolyma

    Anyway, I think it's mostly up to the protocol and so we can just do it right. It's just awkward that the rfc uses us as an example

  51. singpolyma

    I added my server fqdn to all my certs as part of this, and then I see the rfc says to ignore the name on the cert 😂 ah well, it's not bad to have in case someone else misses that part

  52. lovetox

    MattJ, that means server-end-point works on TLS 1.3

  53. lovetox

    MattJ, that means server-end-point works on TLS 1.3?

  54. lovetox

    ah you already said that

  55. Zash

    lovetox, it works on anything, but you basically need XEP-0440 to know that the server supports it

  56. Zash

    tls-unique is mandatory to implement, but "not defined" for TLS 1.3, which is awkward

  57. singpolyma

    The new rfc makes tls-exporter the new mandatory I think

  58. Zash

    Hey Guus, does Openfire / the Java TLS stack you use support either of those channel binding methods?

  59. Zash

    IIRC tls-server-end-point is the only one feasible in many environments due to limited access to the bits needed for the others

  60. singpolyma

    I haven't read about server-end-point yet .. is there a chance i could do it from web? Heh (i assume still no, but who knows)

  61. Zash

    It's a hash of the certificate

  62. Zash

    singpolyma, https://stackoverflow.com/a/50484642 suggests you could do it from an extension...

  63. Zash

    > servers MUST and clients are RECOMMENDED to at least implement the channel-binding type tls-server-end-point Hrm, Prosody does not, never finished that :/

  64. Guus

    To date, Openfire does not support any kind of channel binding. I've raised an issue for that earlier today: https://igniterealtime.atlassian.net/browse/OF-2694

  65. Zash

    tls-server-end-point is so awkward, you don't only need the certificate, you need to know what signature algorithm the certificate uses

  66. Zash

    plus certificates are replaced more often these days

  67. singpolyma

    Isn't the algo recorded in the certificate?

  68. Zash


  69. Zash

    So just access to the PEM/DER blob is insufficient, you need to parse it.

  70. Zash

    This wasn't originally available to Prosody

  71. Zash

    And now Prosody supports tls-server-end-point ... I hope

  72. lovetox

    damn, implemented whole channel binding stuff

  73. MattJ

    Congrats :)

  74. lovetox

    and then when i call in GLib get_channel_binding_data()

  75. lovetox

    it simply secfaults :D

  76. MattJ

    Sounds about right :)