XMPP Service Operators - 2021-05-03

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

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

I already switched off tls1.0 and 1.1

I suggest others to do the same

Had no problems

Nobody was actually still using that

Including s2s side

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

Yeah

I offer tls 1.2 and 1.3

And soon 1.4 and 1.66

Ugh

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

This is the ciphersuite you'll need

Let me know if I made any mistakes

HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL:!ECDHE-RSA-AES256-SHA384:!ECDHE-ECDSA-AES256-SHA384:!ECDHE-RSA-AES256-SHA:!ECDHE-ECDSA-AES256-SHA:!SRP-DSS-AES-256-CBC-SHA:!SRP-RSA-AES-256-CBC-SHA:!SRP-AES-256-CBC-SHA:!RSA-PSK-AES256-CBC-SHA384:!DHE-PSK-AES256-CBC-SHA384:!DHE-PSK-AES256-CBC-SHA:!ECDHE-PSK-CAMELLIA256-SHA384:!RSA-PSK-CAMELLIA256-SHA384:!DHE-PSK-CAMELLIA256-SHA384:!PSK-AES256-CBC-SHA384:!PSK-CAMELLIA256-SHA384:!DHE-RSA-AES256-SHA256:!DHE-DSS-AES256-SHA256:!DH-RSA-AES256-SHA256:!DH-DSS-AES256-SHA256:!DHE-RSA-AES256-SHA:!DHE-DSS-AES256-SHA:!DH-RSA-AES256-SHA:!DH-DSS-AES256-SHA:!ECDHE-RSA-CAMELLIA256-SHA384:!ECDHE-ECDSA-CAMELLIA256-SHA384:!DHE-RSA-CAMELLIA256-SHA256:!DHE-DSS-CAMELLIA256-SHA256:!DH-RSA-CAMELLIA256-SHA256:!DH-DSS-CAMELLIA256-SHA256:!DHE-RSA-CAMELLIA256-SHA:!DHE-DSS-CAMELLIA256-SHA:!DH-RSA-CAMELLIA256-SHA:!DH-DSS-CAMELLIA256-SHA:!AECDH-AES256-SHA:!ADH-AES256-SHA256:!ADH-AES256-SHA:!ADH-CAMELLIA256-SHA256:!ADH-CAMELLIA256-SHA:!ECDH-RSA-AES256-SHA384:!ECDH-ECDSA-AES256-SHA384:!ECDH-RSA-AES256-SHA:!ECDH-ECDSA-AES256-SHA:!ECDH-RSA-CAMELLIA256-SHA384:!ECDH-ECDSA-CAMELLIA256-SHA384:!AES256-SHA256:!AES256-SHA:!CAMELLIA256-SHA256:!ECDHE-PSK-AES256-CBC-SHA384:!ECDHE-PSK-AES256-CBC-SHA:!CAMELLIA256-SHA:!RSA-PSK-AES256-CBC-SHA:!PSK-AES256-CBC-SHA:!ECDHE-RSA-AES128-SHA256:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-RSA-AES128-SHA:!ECDHE-ECDSA-AES128-SHA:!SRP-DSS-AES-128-CBC-SHA:!SRP-RSA-AES-128-CBC-SHA:!SRP-AES-128-CBC-SHA:!DHE-RSA-AES128-SHA256:!DHE-DSS-AES128-SHA256:!DH-RSA-AES128-SHA256:!DH-DSS-AES128-SHA256:!DHE-RSA-AES128-SHA:!DHE-DSS-AES128-SHA:!DH-RSA-AES128-SHA:!DH-DSS-AES128-SHA:!ECDHE-RSA-CAMELLIA128-SHA256:!ECDHE-ECDSA-CAMELLIA128-SHA256:!DHE-RSA-CAMELLIA128-SHA256:!DHE-DSS-CAMELLIA128-SHA256:!DH-RSA-CAMELLIA128-SHA256:!DH-DSS-CAMELLIA128-SHA256:!DHE-RSA-SEED-SHA:!DHE-DSS-SEED-SHA:!DH-RSA-SEED-SHA:!DH-DSS-SEED-SHA:!DHE-RSA-CAMELLIA128-SHA:!DHE-DSS-CAMELLIA128-SHA:!DH-RSA-CAMELLIA128-SHA:!DH-DSS-CAMELLIA128-SHA:!AECDH-AES128-SHA:!ADH-AES128-SHA256:!ADH-AES128-SHA:!ADH-CAMELLIA128-SHA256:!ADH-SEED-SHA:!ADH-CAMELLIA128-SHA:!ECDH-RSA-AES128-SHA256:!ECDH-ECDSA-AES128-SHA256:!ECDH-RSA-AES128-SHA:!ECDH-ECDSA-AES128-SHA:!ECDH-RSA-CAMELLIA128-SHA256:!ECDH-ECDSA-CAMELLIA128-SHA256:!AES128-SHA256:!AES128-SHA:!CAMELLIA128-SHA256:!ECDHE-PSK-AES128-CBC-SHA256:!ECDHE-PSK-AES128-CBC-SHA:!RSA-PSK-AES128-CBC-SHA256:!DHE-PSK-AES128-CBC-SHA256:!DHE-PSK-AES128-CBC-SHA:!SEED-SHA:!CAMELLIA128-SHA:!ECDHE-PSK-CAMELLIA128-SHA256:!RSA-PSK-CAMELLIA128-SHA256:!DHE-PSK-CAMELLIA128-SHA256:!PSK-AES128-CBC-SHA256:!PSK-CAMELLIA128-SHA256:!IDEA-CBC-SHA:!RSA-PSK-AES128-CBC-SHA:!PSK-AES128-CBC-SHA:!KRB5-IDEA-CBC-SHA:!KRB5-IDEA-CBC-MD5:!ECDHE-RSA-DES-CBC3-SHA:!ECDHE-ECDSA-DES-CBC3-SHA:!SRP-DSS-3DES-EDE-CBC-SHA:!SRP-RSA-3DES-EDE-CBC-SHA:!SRP-3DES-EDE-CBC-SHA:!EDH-RSA-DES-CBC3-SHA:!EDH-DSS-DES-CBC3-SHA:!DH-RSA-DES-CBC3-SHA:!DH-DSS-DES-CBC3-SHA:!AECDH-DES-CBC3-SHA:!ADH-DES-CBC3-SHA:!ECDH-RSA-DES-CBC3-SHA:!ECDH-ECDSA-DES-CBC3-SHA:!DES-CBC3-SHA:!RSA-PSK-3DES-EDE-CBC-SHA:!PSK-3DES-EDE-CBC-SHA:!KRB5-DES-CBC3-SHA:!KRB5-DES-CBC3-MD5:!ECDHE-PSK-3DES-EDE-CBC-SHA:!DHE-PSK-3DES-EDE-CBC-SHA:!EXP1024-DHE-DSS-DES-CBC-SHA:!EDH-RSA-DES-CBC-SHA:!EDH-DSS-DES-CBC-SHA:!DH-RSA-DES-CBC-SHA:!DH-DSS-DES-CBC-SHA:!ADH-DES-CBC-SHA:!EXP1024-DES-CBC-SHA:!DES-CBC-SHA:!KRB5-DES-CBC-SHA:!KRB5-DES-CBC-MD5:!EXP-EDH-RSA-DES-CBC-SHA:!EXP-EDH-DSS-DES-CBC-SHA:!EXP-ADH-DES-CBC-SHA:!EXP-DES-CBC-SHA:!EXP-RC2-CBC-MD5:!EXP-KRB5-RC2-CBC-SHA:!EXP-KRB5-DES-CBC-SHA:!EXP-KRB5-RC2-CBC-MD5:!EXP-KRB5-DES-CBC-MD5:!EXP-DH-DSS-DES-CBC-SHA:!EXP-DH-RSA-DES-CBC-SHA

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

Maybe I could submit a patch

tom: wtf...

Wtfw Licaon_Kter?

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

Why would i do that

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

This isn't IRC we have multiple lines do stuff

Yes, but that's spammy

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

https://ssl-config.mozilla.org/

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

so would `ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

😳️

You have combinations inside it

I'm aware there aare some duplicates inside it

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

also

`!AESCBC`?

chacha20 and xchacha

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

`ssl_ciphers HIGH+kEECDH:HIGH+kEDH:!CAMELLIA:!PSK:!SRP:!3DES:!aNULL:!AESCCM:!AESCCM8:!ARIAGCM;`

That's what I have

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

and CCM can be considered secure

CCM is different

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

`!AES`?

Maybe

also why are you disabling CAMELLIA?

no definitely not. I want AES

that would break a lot of shit

Isn't AES only AESCBC?

no

you can have Galois counter mode

``` michel@debian:~$ openssl ciphers HIGH:\!AES TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ADH-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:ARIA256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-ARIA256-GCM-SHA384:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:ARIA128-GCM-SHA256:PSK-ARIA128-GCM-SHA256:CAMELLIA256-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:CAMELLIA256-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:CAMELLIA128-SHA:PSK-CAMELLIA128-SHA256 ```

Only disables CBC

``` michel@debian:~$ openssl ciphers HIGH+kEECDH:HIGH+kEDH:\!CAMELLIA:\!PSK:\!SRP:\!3DES:\!aNULL:\!AESCCM:\!AESCCM8:\!ARIAGCM:\!AES TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305 ```

hold on

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

why?

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

TLS_>AES_<256_GCM_SHA384

``` michel@debian:~$ openssl ciphers HIGH+kEECDH:HIGH+kEDH:\!CAMELLIA:\!PSK:\!SRP:\!3DES:\!aNULL:\!AESCCM:\!ARIAGCM:\!AES TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305 ```

tom, AES is AESCBC. AESGCM is AESGCM

``` michel@debian:~$ openssl ciphers AESGCM TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ADH-AES128-GCM-SHA256:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256 ```

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?

this command seems to show conflicting information

Hmm

what version are you using?

But

``` michel@debian:~$ openssl ciphers HIGH\!AES TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ADH-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:ARIA256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-ARIA256-GCM-SHA384:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:ARIA128-GCM-SHA256:PSK-ARIA128-GCM-SHA256:CAMELLIA256-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:CAMELLIA256-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:CAMELLIA128-SHA:PSK-CAMELLIA128-SHA256 ```

`OpenSSL 1.1.1k 25 Mar 2021`

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

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

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

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

i'm concerned about oracle padding attacks

and openssl's HIGH doesn't protect against them

So your defaults should be safe

Really

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

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

Or just go with TLSv1.3 only

I can't

Why?

a lot of servers are still connecting with tls1.2

maybe i could for c2s

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

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

and also takes care of things like DH size

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.

word.

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

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.

well

that's not appropriate for an XMPP server

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

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

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.)

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

now

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

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

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

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

i Could clean it up a bit

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

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

Holger: it's not hardcoding cipher lists

it's blacklisting known bad ones

notice the :!

AES CBC is not considered insecure

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

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

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

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

A working exploit would contradict such things quite convincingly.

(But I'll shut up now sorry.)

> Unable to select database

your not able to view the webpage?

Yes

But there is archive

Anyway, that was patched

OpenSSL should not be vulnerable now

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

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

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

thankyou

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

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

yes

Ok, thanks jonas’

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

nvm

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

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

qaz

Plus other services depending on this one being fine.

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

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

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

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

So i try to keep it outside my network

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

For services that need legacy-compat

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

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

What about the s2s connection though?

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

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

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

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

I think the government should step in and mandate v6 deployment

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

Thanks Holger

> 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!

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

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

especially with widespread and pervasive government and corporate surveillance

> 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.

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

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

Anyone managed to reach the tiagese guys?

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

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

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

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

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

I just sent them a DM with that info.

Thanks

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

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

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

dialback is fine and perfectly secure as long as good+valid certificates is required right 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

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

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

>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)?

dialback should also involve proper validation of certificate

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?

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

moparisthebest: Oh thanks for your expertise :-)

>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".

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.

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

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

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

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.

>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

"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.

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

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

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

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

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

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

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

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

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

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

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

Please. Don't go with the CAs bad

We have CT now

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

https://xmpp.404.city:5280/usershare/6d33720a4a94189f7b96d206ee5f6128196decf2/jIwjrFEUVCIj6HI2WtRJLQbJ2XsvGyeHJapQ02Pb/Schrodingers_cat.svg.png

>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.

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.

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

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

Poor kitty

How can one do such a cruel thing?

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

How is DANE support?

‎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.

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.

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

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

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

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

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

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

it provides no authentication or replay-proofing at all

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

it's absolutely not a replacement for TLS

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

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

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

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

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

> ‎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. ✏

> ‎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

yes

>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.

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

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

>‎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.

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