XSF Discussion - 2013-12-15

back, after a long time. 8)

Where were you Kevin?

oh not the Kev. There is more than one.

There are two.

There's only one me, though.

Kev, how's Doomsong's cert fixing going?

Or are you gunning for DNSSEC being widespread enough that you can drop it? :)

yeah, only one kev smith. and i'm not that

Simon: I need to sort this out, thanks for reminding me

Conveniently, I'm in the middle of capturing todos at the moment :)

buddycloud.com/org just completed readiness for Jan 4th.

simon: post to operators@ instead

91.5% of servers allowing starttls is good.

fippo: will do in the future

MITM says "I'd rather not startTLS". So still MITM-able.

we're not going to stop being MITM-able in january.

agreed: 4th Jan will help us understand what breaks.

like the ipv6 days.

My point is that we have a benchmark and can see if we're increasing.

http://mail.jabber.org/pipermail/standards/2007-July/016086.html

take that as comparison :-)

shocking…

makes the http cert world look pristine.

sure. nobody seemed to care back then

and your 8.5% figure is misleading. tls will typically be used when it's offered, so it's likely used on 91.5% of the connections

and 51% are most likely non-mitmable

which is not bad

how many of that 8.5% are also doing certificate auth?

I don't think many people are requiring certificate auth

so still mitm-able then.

sure.

but manifesto is not about changing that

I'm going to log a check for that on https://bitbucket.org/xnyhps/xmppoke/issues?status=new&status=open

there is no safe way to tell if a remote server enforces your cert

https://bitbucket.org/xnyhps/xmppoke/issue/12/test-for-invalid-certificates-certificate

simon: I like that ;-)

kev: just pushed updated jingle-grouping/jingle-sources :-)

fippo: There is for C2S, mind.

kev: cert checking or Jingle?

A way to check that the other end's connection to you isn't MITMable.

yeah - imho this is important. (ref: one of DWD's speeches on certs and authenticity etc etc)

Simon: So, do you use -PLUS? :)

fippo: So, ready for a revote on Wednesday, then?

g+?

kev: yes please

Simon: No, SCRAM-SHA-1-PLUS.

That's the only way the server can check that the client's not going to be MITMd.

kev - yes.

And even that's not perfect.

I'm more concerned about s2s in this case.

kev: but that doesn't allow you to tell if the remote server is using your cert to auth either (actually, why would it request scram from you?)

fippo: -PLUS doesn't help with S2S, but it helps greatly with C2S.

But only if a client doesn't allow a downgrade to PLAIN.

Which ~=everyone does.

Kev, and Swift? :)

Swift doesn't do mech pinning.

"Yet"?

I've been considering taking a client and making it "totally secure", and re-releasing it

Yet, indeed.

Swift is obviously a good candidate

There are a number of sensible things to do there, and motivation to do them.

I'm talking about removing support for anything but TLS 1.2, SCRAM-PLUS, etc.

No certificate validation bypass

This doesn't sound like fun

For whom? :)

Well - what's the motivation?

Protection against downgrades is very sensible, and doesn't stop users using the client.

But stripping out widely used things because they're not deemed to be maximally secure doesn't seem altogether helpful.

How many TLS 1.1 vulnerabilities are we seeing?

Just because we aren't seeing them doesn't mean they aren't there

And there's no point forking Swift for this, BTW. We have a mechanism for enforcing policies by sysadmins.

Everyone should realise that by now :)

Kev, then I'd repackage it at least

Why?

and you probably wouldn't want me calling it just "Swift" at that point

then how do I configure it?

brb

Linux: Install an extra make-Swift-paranoid package, Windows you can have such a checkbox in the installer, and I'm sure something can be worked out for Mac.

the node-XMPP guys are doing some good work to move their code to nicely support TLSv.1.2

Kev, are there docs on this?

MattJ: No.

But happy to chat about it over <- there in swift@.

Ok, when I have some time :)

oops - didn't mean to dredge up the digest beast in members@

Too late, it is awake

Hopefully it's died out by the time I'm back (10th Jan)

I'm not sure bringing up requirements for TLS is necessarily staying on-message at the moment.

While there's simultaneously the opportunistic TLS days happening.

For folks not in the Prosody room, I'm currently working on a mod_manifesto

https://matthewwild.co.uk/uploads/mod_manifesto_1.png

That's really nice MattJ

In terms of the text - it might put it in context to describe the problem/why at the start.

It's configurable by the admin, but this is the default message - I'm happy to take suggested amendments

I don't want it t o get too verbose

yes.

I should clarify that the list is completely automated - it is only sent to users who have contacts on unencrypted s2s links

I'd expect nothing less from the Prosody team.

I'm going to implement the actual test days into the module too if I can - overriding the config to allow only encrypted connections for the 24h period

which also means I'm aiming for UTC...

unless people think that's a bad idea

TZ of least confusion.

MattJ: Do we have good error responses on lack of TLS?

waqas, as good as could be expected

Both for local users, and for remote

I'm thinking of having mod_manifesto rewrite them for the test day though

waqas, yes, the error message says that the delivery failure was due to lack of encryption

The folks we probably want to make the most aware of this are the people on servers without good encryption

Not the local users, who are already on a good server

Yep

I considered spamming them, but... ;)

I expect all users will get a notification until jabber.org gets ready.

jabber.org /is/ ready, is it not?

In that the only thing that's needed to be ready is to have a cert.

kev: i think it would be good to have jabber.org reject non-tls connection

https://xmpp.net/result.php?domain=jabber.org&type=server

otherwise "but it works with jabber.org!!!!" is true

and fix it's cipherlist

Simon: Nothing on that page looks incompatible with servers participating in the event.

To me.

fippo: Yes, I expect we will.

i wonder why jabber.orgs pubkey score is sooo low

Because it bundles the root (Which is a pretty sensible thing to do)?

Why is it a sensible thing to do?

MattJ: Because if you're going to do leap of faith, having the root gives you a better basis for future upgrades.

Presumably the root should come from outside the connections / OS /Browser.

intermediate should be included though

also the cert is for conference.jabber.org.

The cname is c.j.o, which isn't the same thing.

It has the right SANs in it as far as I know.

there is a bug for xmpp.net that it should show SANs

i even have code for it but can't get the tool itself to work for me

fippo: this one https://bitbucket.org/xnyhps/xmppoke/issue/3/show-certificate-subjectalternativenames ?

simon: yeah

If anyone is looking for a well considered, peer reviewed ciphersuite, Mozilla Opsec have a good writeup: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite

fippo: solved you cert problem a different way https://xmpp.net/result.php?domain=estos.de&type=server ?

simon: huh? it has always shown as valid

it just doesn't show why this one is valid :-)

reread your xmpppoke issue. Makes sense now.

interestingly buddycloud.com refuses to speak to jabber.org too with the current cert.

Dec 15 21:34:43 s2sout22aafc0 info Beginning new connection attempt to jabber.org. ([208.68.163.218]:5269) Dec 15 21:34:44 mod_s2s warn Forbidding insecure connection to/from jabber.org. Dec 15 21:34:44 s2sout22aafc0 info outgoing s2s stream buddycloud.com->jabber.org. closed: stream closed Dec 15 21:34:44 s2sout22aafc0 info sending error replies for 2 queued stanzas because of failed outgoing connection to jabber.org.

s2s_secure_auth = true s2s_require_encryption = true

I don't know why that would be

Haaa

I know what the issue is, there is a '.' at the end of the hostname

the cert or the contact?

Someone is trying to send something to "jabber.org."

right

I vaguely recall something about this in the RFC

Yes, it's in 6122

It must be stripped, but it doesn't say where

well, it says: "this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP‑URI]. "

So it's a client bug for allowing it and a server bug for not stripping it either I suppose

server bug for storing it in the roster table too?

Not necessarily storing it

I don't know if roster entries must be in normalized form

Let's blame jabber.org for answering to "jabber.org."

Prosody says host-unknown