XMPP Service Operators - 2021-05-03

  1. tom

    I'm going to switch of cipher block chaining on my server

  2. tom

    Nobody has actually used that mode in quite a long time (more than any of my logs indicate)

  3. tom

    I already switched off tls1.0 and 1.1

  4. tom

    I suggest others to do the same

  5. tom

    Had no problems

  6. tom

    Nobody was actually still using that

  7. tom

    Including s2s side

  8. christian

    If you offer tls1.2 nobody will be able to use 1.1

  9. tom


  10. tom

    I offer tls 1.2 and 1.3

  11. christian

    And soon 1.4 and 1.66

  12. tom


  13. tom

    This is surely redundent but openssl is a bitch and doesn't actually disable block chaining modes when you !AESCCM

  14. tom

    This is the ciphersuite you'll need

  15. tom

    Let me know if I made any mistakes

  16. tom


  17. tom

    Hopefully in the future openssl adds a better way to do this

  18. tom

    Maybe I could submit a patch

  19. Licaon_Kter

    tom: wtf...

  20. tom

    Wtfw Licaon_Kter?

  21. Licaon_Kter

    Why paste that here, use a bin, gist, snip

  22. tom

    Why would i do that

  23. tom

    That's like a whole nother place and application to open

  24. tom

    This isn't IRC we have multiple lines do stuff

  25. Licaon_Kter

    Yes, but that's spammy

  26. mimi89999

    tom, that ciphersuite is way to long. What do you want to achieve?

  27. mimi89999


  28. tom

    mimi89999: too long for what? It's accepted by prosody. Disabling cipher block chaining

  29. mimi89999


  30. Holger


  31. mimi89999

    You have combinations inside it

  32. tom

    I'm aware there aare some duplicates inside it

  33. tom

    I was generally trying to avoid an allowlist, because new ciphersuits will come along

  34. tom


  35. mimi89999


  36. tom

    chacha20 and xchacha

  37. tom

    mimi89999: there is no AESCBC in openssl 1.1.1d. man openssl-ciphers

  38. mimi89999


  39. mimi89999

    That's what I have

  40. tom

    there's AESCCM but it doesn't quite do the same thing

  41. tom

    and CCM can be considered secure

  42. mimi89999

    CCM is different

  43. tom

    mimi89999: you don't need to have !AESCCM:!AESCCM8. !AESCCM encompasses !AESCCM8:

  44. mimi89999


  45. mimi89999


  46. tom

    also why are you disabling CAMELLIA?

  47. tom

    no definitely not. I want AES

  48. tom

    that would break a lot of shit

  49. mimi89999

    Isn't AES only AESCBC?

  50. tom


  51. tom

    you can have Galois counter mode

  52. mimi89999


  53. mimi89999

    Only disables CBC

  54. mimi89999


  55. tom

    hold on

  56. tom

    you have !AES in your cipher string but TLS_AES_256_GCM_SHA384 is a supported cipher?

  57. tom


  58. tom

    isn't TLS_AES_256_GCM_SHA384 AES? It says so right there in the suite

  59. tom


  60. mimi89999


  61. mimi89999


  62. mimi89999


  63. tom

    mimi89999: » $ openssl ciphers -v 'AES' | grep GCM » TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD » TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD » ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD » ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD » DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD » DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD » ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD » ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD » ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD » DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD » DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD » ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD » RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD » DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD » AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD » PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD » RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD » DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD » AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD » PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD » are you sure about that?

  64. tom

    this command seems to show conflicting information

  65. mimi89999


  66. tom

    what version are you using?

  67. mimi89999


  68. mimi89999


  69. mimi89999

    `OpenSSL 1.1.1k 25 Mar 2021`

  70. mimi89999

    `openssl ciphers -v 'AES' | grep GCM` gives me the same

  71. mimi89999

    tom, I recommend you stay with the defaults. If you have an old version and defaults are unsafe, I recommend you update.

  72. tom

    AES keyboard also doesn't seem to be listed in the man page

  73. tom

    mimi89999: I'm not using an old version i'm on Devuan beowulf's stable

  74. tom

    i'm concerned about oracle padding attacks

  75. tom

    and openssl's HIGH doesn't protect against them

  76. mimi89999

    So your defaults should be safe

  77. mimi89999


  78. mimi89999

    > i'm concerned about oracle padding attacks Depends on implementation. OpenSSL was once vulnerable, but that was patched long time ago.

  79. Holger

    At the very least I would not hard-code specific ciphers.

  80. mimi89999

    Or just go with TLSv1.3 only

  81. tom

    I can't

  82. mimi89999


  83. tom

    a lot of servers are still connecting with tls1.2

  84. tom

    maybe i could for c2s

  85. Holger

    You'll forget to update your superdupersecure cipher list once OpenSSL supports newer ones.

  86. jonas’

    chances are that your OS already has a security level defined which suits your purposes

  87. jonas’

    and also takes care of things like DH size

  88. Holger

    And maybe you're superman and won't forget. But if I was superman I would, at the very least, not post such lists in public. Because others might think "wow tom is superman, I'll copy paste his super-duper-secure cipher list", and then fail to maintain it.

  89. jonas’


  90. jonas’

    I still need to age out the formerly great applied crypto hardening lists of all my automation because they were never updated

  91. Holger

    I just do something like this usually: `"HIGH:!aNULL:!3DES:@STRENGTH"` If my users are hacked because that's too unsecure, I'll send them to tom next time.

  92. tom


  93. tom

    that's not appropriate for an XMPP server

  94. Holger

    On servers with super-duper-secure co-admins who insist on PFS, I do this: `"ECDH:DH:!3DES:!aNULL:!eNULL:!MEDIUM:@STRENGTH"`

  95. mimi89999

    Defaults were once unsafe. That's why setting custom ciphersuites became popular. Now they are good.

  96. Holger

    I think posting explicit cipher lists in public isnt't appropriate and I explained why. Presumably my first list will support way cooler ciphers than yours a few years from now. (Yes the second is already a bit problemativ in that it insists on DH.)

  97. tom

    for one, PSK and SRP suites are completely pointless for an XMPP connection. Secondly they aren't good. Their backwards compat opens it up to padding oracle attacks

  98. tom


  99. mimi89999

    Unless you really know what you are doing, stay with the defaults

  100. tom

    I don't need THAT much backwards compat, other than running safe ciphers through tls 1.2

  101. mimi89999

    Or somebody decided what ciphers are allowed and what are not in the org, then you must apply 😕️

  102. tom

    that big bloated list i sent first does do that job of excluding known bad suites vulnerable to padding oracle attacks, however the biggest problem is that it's ugly as hell (cosmetic) and that it's redundant eg, i'm already dissallowing preshared key and 3DES suites

  103. tom

    i Could clean it up a bit

  104. tom

    but i'm wonder if this may be a thing to send as a patch to upstream openssl in order to have a !CBC group actually work

  105. Holger

    tom, I'd call suggesting others to hard-code cipher lists a security issue, not a cosmetic issue.

  106. tom

    Holger: it's not hardcoding cipher lists

  107. tom

    it's blacklisting known bad ones

  108. tom

    notice the :!

  109. mimi89999

    AES CBC is not considered insecure

  110. Holger

    Ah `HIGH+kEDH:HIGH+kEECDH:HIGH:`, I missed the final `:HIGH:`, sorry.

  111. mimi89999

    Yes, they were not accepted in TLSv1.3, but there is nor reason to force disable them.

  112. Holger

    Ignore me then. Then it's just stupid but probably won't hurt except maybe interop, and I don't care 😛

  113. tom

    » <mimi89999> AES CBC is not considered insecure http://www.isg.rhul.ac.uk/tls/Lucky13.html seems to contradict that

  114. Holger

    A working exploit would contradict such things quite convincingly.

  115. Holger

    (But I'll shut up now sorry.)

  116. mimi89999

    > Unable to select database

  117. tom

    your not able to view the webpage?

  118. mimi89999


  119. mimi89999

    But there is archive

  120. mimi89999

    Anyway, that was patched

  121. mimi89999

    OpenSSL should not be vulnerable now

  122. tom

    oh, would you happen to have any information on that? I'd rather read a paper than take your word. no offense

  123. tom

    it says it's a problem with the spec itself, not an implementation

  124. mimi89999

    tom, https://security-tracker.debian.org/tracker/CVE-2013-0169

  125. tom


  126. tom

    is there a way to print all current c2s+s2s connection in prosody + their current ciphersuite in use?

  127. millesimus

    Does xmpp.net test need the tested server to be available via IPv4?

  128. jonas’


  129. millesimus

    Ok, thanks jonas’

  130. jonas’

    we wish to change that eventually but that's not likely to happen before the whole thing is rewritten

  131. tom


  132. Holger

    Dual-stack is always great fun, even more so with monitoring.

  133. Holger

    "v4 status: critical (send e-mail + SMS notifications), v6 status: recovered from non-critical problem (send e-mail)". SIGSEGV.

  134. tom


  135. Holger

    Plus other services depending on this one being fine.

  136. tom

    it helps if the only thing with v4 addresses is your reverse proxy and nat

  137. Holger

    if (v6_status != v4_status) just_do_nothing(); // It would be wrong anyway.

  138. Holger

    Yeah, dealing with dual-stack by avoiding it helps 🙂

  139. tom

    Well the way i see it Holger is ipv4 is legacy crap that should have been deprecated in the 80s were it not have been for the dotcom boom

  140. tom

    So i try to keep it outside my network

  141. tom

    And only via a nat (because i don't want to pay extra for allocations as well)

  142. tom

    For services that need legacy-compat

  143. tom

    Why does conversations.im only support tls1.2? Aren't they supposed to be modern im?

  144. Holger

    tom, old versions of the Conversations app will fail to log in if TLSv1.3 is offered, due to a client bug.

  145. tom

    What about the s2s connection though?

  146. Holger

    True, we could offer 1.3 there, just didn't bother so far.

  147. tom

    It's so very unfortunate that so many regional ISP monopolies in the USA have still to this day refused to implement ipv6

  148. Holger

    > What about the s2s connection though? Should work now.

  149. tom

    At this point, the lack of v6 connectivity is a serious hurdle in the way for new isps and companies to spring up as there's simply no more v4 address space left to sell

  150. tom

    I think the government should step in and mandate v6 deployment

  151. tom

    Make it a requirement for calling a service 'broadband' or something

  152. tom

    Thanks Holger

  153. mimi89999

    > tom, old versions of the Conversations app will fail to log in if TLSv1.3 is offered, due to a client bug. Let's force them to update!

  154. tom

    mimi89999: I really have no preference or opinion about how other sites managed their c2s settings

  155. tom

    or what clients people want to use. I do however think the s2s side should have secure crypto

  156. tom

    especially with widespread and pervasive government and corporate surveillance

  157. croax

    > I think the government should step in and mandate v6 deployment tom: agree. I guess they just don't care. For sure lobbyist would also get benefit of this situation by selling NAT, consultancy and speculate on ipv4 exhaustion.

  158. Martin

    > tom, old versions of the Conversations app will fail to log in if TLSv1.3 is offered, due to a client bug. How old?

  159. tom

    https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7624

  160. Martin

    Anyone managed to reach the tiagese guys?

  161. tom

    I also think that with keeping in mind the reality that many governments do in fact record ALL internet traffic to disk.. now you might think that's crazy but egypt actually did that and the utah datacenter and ESPECIALLY google have the ability to do that

  162. tom

    that we shouldn't be just enabling the absolute minimum in terms of security and crypto

  163. mike

    What's up with Tigase? Their Masto account posted just a few minutes ago so someone's around.

  164. Martin

    Can't join their chat as their cert is invalid again.

  165. Martin

    Establishing a secure connection from mdosch.de to muc.tigase.org failed. Certificate hash: 6309c033094e3d8fb71d4dea59197ac81bd38240a4c03a68c10fee75fc09ac47. Error with certificate 0: certificate has expired.

  166. mike

    I just sent them a DM with that info.

  167. Martin


  168. 404.city

    tom, you are talking about the security of ciphers, but most servers accept self-signed certificates and are harassing those who want to change. It looks like a security theater. https://github.com/E-404/Manifestos/blob/master/1.md

  169. moparisthebest

    404.city, "s2s_secure_auth = false" doesn't mean "allow self signed certificates" right ?

  170. Menel

    Who is harassing? I wouldn't care for those servers that still don't use a valid cert.

  171. moparisthebest

    dialback is fine and perfectly secure as long as good+valid certificates is required right 404.city ?

  172. 404.city

    I can consider this manifesto a failure, because some administrators who signed it do not comply with it, and some administrators began to actively oppose the manifest, fearing to lose some of the users connected to insecure servers

  173. moparisthebest

    I'd consider it a failure because the basic premise is a misunderstanding

  174. moparisthebest

    404.city, I can't speak to ejabberd, but prosody's default config includes `s2s_secure_auth = false` but DOES NOT allow self-signed certs, and in fact requires valid certs for all s2s communication

  175. 404.city

    >moparisthebest‎: dialback is fine and perfectly secure How are you going to validate the dialback (s2s) when the interlocutor connects to a other server with a self-signed certificate (c2s)?

  176. moparisthebest

    dialback should also involve proper validation of certificate

  177. croax

    LetsEncrypt provides certificates using DNS and IP address source and destination. Dialback with self-signed certificates offers same service. Why would it be less secure?

  178. moparisthebest

    croax, I can answer that one, letsencrypt checks DNS from multiple geographically seperate endpoints, not just 1

  179. croax

    moparisthebest: Oh thanks for your expertise :-)

  180. 404.city

    >Dialback with self-signed certificates offers same service. Why would it be less secure? Your interlocutor checks manually self signed certificates for his server. Many people ignore security and accept any self-signed certificates. Security is a "set of measures", and not only everything is "fine here".

  181. croax

    404.city: I was just speaking about s2s. Dialback is a way to validate self signed certificates. It's not just accepting. c2s is a particular context, under the scope of the server policy. Out of scope of federation.

  182. qrpnxz

    speaking of ipv6, noticed i'm missing a AAAA record for my website 😬 I'm sorry World.

  183. 404.city

    Many security standards are developed based on security incidents. Yes, dialback does not protect against untrusted Wi-Fi, your interlocutor, and therefore, in general, the connection cannot be considered secure. dialback was made at a time when certificates were "paid" and completely fulfilled its purpose. This is now an obsolete standard. We recommend everyone who wants to use self-signed certificates to use PGP, inside clients

  184. Wiktor

    404.city: by "use pgp" you mean use pgp for e2ee not for cert verification? Then why pgp and not omemo?

  185. croax

    404.city: That's unlikely that a dialback connection will go through Wifi. I agree that valid certificate is better but Dialback seems not so bad. Do you think a central authority issuing 90% (just random figure) of certificate is less subject to security agency abuses? Response might be yes though.

  186. 404.city

    >Wiktor‎: 404.city: by "use pgp" you mean use pgp for e2ee not for cert verification? Then why pgp and not omemo? Yes, e2e encryption is a more precise definition

  187. 404.city

    "Use PGP" is special for % croax % as it serves their purpose. Who wants to use a self-signed certificate on the server as client PGP encryption.

  188. octagon

    re ciphers: fedora and centos 8 has: update-crypto-policies --set NEXT # or FUTURE

  189. moparisthebest

    if we are going to push for better s2s authentication why not go with the real solution? DANE :)

  190. moparisthebest

    that means anyone with an .im TLD has to get rid of it, but otherwise should be great

  191. 404.city

    > That's unlikely that a dialback connection will go through Wifi. The most frequent case: c2s connection through your interlocutor, through an unsafe connection

  192. croax

    404.city, I don't get it, Dialback occurs on s2s

  193. croax

    moparisthebest: yeah DANE! Why ICANN not pushing DNSSEC? Same than IPv6..

  194. moparisthebest

    they kind of are pushing DNSSEC, all new gTLDs must support it for instance

  195. 404.city

    croax‎: 🙂 If the XMPP server has insecure s2s, the server also has insecure c2s)

  196. croax

    404.city: might be the case but not necessary. That's a big shortcut.

  197. croax

    CAs may be context-dependent. And they're alternatives like DANE, posh, ...

  198. moparisthebest

    my server has always supported DANE, unsure if others do, it's the same story with email really, I only know of me and debian.org with support

  199. croax

    CAs may be context-dependent. And they're alternatives like DANE, POSH, ...

  200. mimi89999

    Please. Don't go with the CAs bad

  201. mimi89999

    We have CT now

  202. mimi89999

    And DANE won't make it possible to detect temporary interception unlike CT logs.

  203. 404.city


  204. 404.city

    >croax‎: 404.city: might be the case but not necessary. That's a big shortcut. There are only rare exceptions to this rule. Security systems should work automatically and not allow "it may or may not be". "Schrödinger's cat". Imagine that the lock from the safe, which contains the "Top Secret Documents", will be closed, or maybe not closed. This is counterintuitive and unexpected security behavior.

  205. croax

    404.city: Don't following. There's no unique worldwide CA store. One's not suppose to trust any widely used CA. One can issue context specific CA, like organizational ones. This is all matter of security vs interoperability. And all is context dependent.

  206. moparisthebest

    mimi89999, any servers or clients check CT? CT is a nice addition to CA stuff but not nearly as good of a replacement for DANE

  207. croax

    Moreover making any assumption of link between s2s (concerning federation) and c2s (server scope) is wrong.

  208. mimi89999

    Poor kitty

  209. mimi89999

    How can one do such a cruel thing?

  210. mimi89999

    moparisthebest, no, but on Android you can use https://github.com/appmattus/certificatetransparency

  211. mimi89999

    How is DANE support?

  212. 404.city

    ‎croax‎ you propose to remove all CAs (Until you delete all certification authorities, your actions are meaningless) built into the system and instead manually check untrusted connections in some mystical way (carrier pigeons). I think this is not very rational. Please don't come up with your own encryption, just use PGP. It's easier, safer and more convenient.

  213. 404.city

    PGP (e2e) does all the necessary tasks without involving additional entities, and TLS has no security task at the level you suggest. Using TLS encryption like e2e is like hammering nails with a microscope.

  214. Wiktor

    > ‎just use PGP. It's easier, safer and more convenient. First time I saw "PGP" used in the same paragraph with "easier and safer"

  215. 404.city

    >First time I saw "PGP" used in the same paragraph with "easier and safer" In context with TLS

  216. moparisthebest

    TLS protects an entirely different set of things and serves entirely different purposes than e2e, they can't be compared

  217. moparisthebest

    current-PGP (xep-27) in XMPP provides far fewer guarantees than a normal person expects out of e2e these days, for instance

  218. mimi89999

    I opened https://github.com/iNPUTmice/Conversations/issues/4068

  219. croax

    Exactly. You could leak all meta-data compromising you by connecting on a wrong server, still encrypting e2e.

  220. moparisthebest

    it provides no authentication or replay-proofing at all

  221. moparisthebest

    and it protects message body only, nothing else, and no meta-data

  222. moparisthebest

    it's absolutely not a replacement for TLS

  223. 404.city

    Wiktor I am not a supporter of saying which e2e encryption is better or worse. Many famous people used different e2e encryption systems, and I think their competence in these matters is higher. Stolman - PGP, Snowden - OMEMO / OTR, assange julian - OTR

  224. croax

    Ex of meta-data: correspondant JID, message time, ...

  225. moparisthebest

    there is no "better" or "worse" but there are ENTIRELY DIFFERENT GUARANTEES provided by each type that need understood by people who want to use them

  226. croax

    Eg. of meta-data: correspondant JID, message time, ...

  227. moparisthebest

    there is absolutely "better" or "worse" e2e for a specific person with a specific threat model though

  228. moparisthebest

    hence the need to understand 1) your threat model 2) the guarantees provided by each

  229. croax

    > ‎croax‎ you propose to remove all CAs (Until you delete all certification authorities, your actions are meaningless) built into the system and instead manually check untrusted connections in some mystical way (carrier pigeons). I think this is not very rational. Please don't come up with your own encryption, just use PGP. It's easier, safer and more convenient. Non, just saying there's dialback. And asking to blacklist this mecanism is nonsense.

  230. croax

    > ‎croax‎ you propose to remove all CAs (Until you delete all certification authorities, your actions are meaningless) built into the system and instead manually check untrusted connections in some mystical way (carrier pigeons). I think this is not very rational. Please don't come up with your own encryption, just use PGP. It's easier, safer and more convenient. No, just saying there's dialback. And asking to blacklist this mecanism is nonsense.

  231. 404.city

    > ‎moparisthebest‎: it's absolutely not a replacement for TLS I think there are some difficulties with translation. I do not mean abandoning TLS, I mean not using self-signet TLS "as" E2E encryption(PGP). The best option is valid TLS + E2E

  232. moparisthebest


  233. 404.city

    >No, just saying there's dialback. And asking to blacklist this mecanism is nonsense. croax How should a person who has not issued a self-signed certificate verify a self-signed certificate? We are not talking about dialback at the moment. dialback not used with c2s.

  234. croax

    404.city: From the link you posted > delete support self-signed certificates "mod_s2s_dialback

  235. croax

    404.city: c2s is server scope specific. No need to ask anything for better federation.

  236. 404.city

    >‎croax‎: 404.city: From the link you posted I will explain to you the reason why this setting is used. I'm not talking specifically about protecting s2s connections even. Self-signed certificates reduce security without any useful application.

  237. moparisthebest

    404.city: that's not technically true either, self signed provides protection against passive surveillance, just not active attacks