interop - 2010-12-10

Bouncing prosody8

fippo, awake?

psyced-sasl doesn't like me

Everything else seems to work

Dec 10 01:44:05 s2souta052b68 debug Received[s2sout_unauthed]: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> Dec 10 01:44:05 prosody8.xmpptest.com:saslauth debug SASL EXTERNAL with psyced-sasl.xmpptest.com succeeded

but I don't receive a pong

Ah

It would help if I trusted the interop CA cert, wouldn't it? :)

This host does not serve notls.xmpptest.com

notls.xmpptest.com. 3600 IN A 89.16.172.47

^^

no srv

Ah yes, thanks for reminding me

!uptime matthewwild.co.uk

!slap Kanchil

Actually I don't need to restart

!version

Zash: Kanchil is running Riddim version alpha on an unknown platform

MattJ: btw, that reminds me, Riddim has no !uptime plugin yet

!slap MattJ

And can do that ;)

I'll have more time for even Riddim soon :)

Bot interop event! \o/ ... ;P

Right then, Friday.

and still need to set up the servers of thursday :)

So, today's plan. Make servers require TLS, and require trusted and valid certs.

And if MattJ hasn't done notls yet, that still needs doing.

remko: Just notls?

yes, and i still need an account on tigase (Florian?)

So the failures machines are all in place apart from expiredcert, which is presenting the wrong cert (although it's also expired), and notls.

Kev: I would have thought that expiredcert should be valid in every way, except that it has expired??

Yes.

That's why I said expiredcert isn't in place yet.

ah yes - can parse your sentence now!

expiredcert is in place now too.

yes, and ejabberd connects using tls to all of them :S

Well, that's one up from connecting without TLS to them :)

Right, I'll give it a run though.

We still don't have notls, but that's largely just interesting for the clients^h testing.

Given that we have Tigase.

tigasetrunk, rather

why do we need notls in addition to Tigase?

steve.kille: It would be good to test it against an XMPP server not offering TLS, as well as the legacy protocol.

But largely, it's so that the clients can test correct handling of not having TLS when PLAIN is the only available mech.

Okay, that's odd. I seem to be able to connect to everything except Tigase, and NoTls. So I suspect my settings are out, but I thought I'd checked them...

I haven't verified that the expired cert is actually expired, or that the revoked cert is actually revoked, mind.

It was yesterday.

And the expiredcert being expired forced us into using SodiumCA instead of OpenSSL to build the PKCS#12, if you recall.

Yes.

12/10 10:44:39 xmppd 21382 (root ) I-MBOX-Info Verifying certificate 12/10 10:44:39 xmppd 21382 (root ) I-MBOX-Info certificate (subject emailA ddress=xmpp@revokedcert.xmpptest.com,OU=XMPP Department,O=Your Organisation,L=Th e Internet,C=GB,CN=revokedcert.xmpptest.com), detail (email=xmpp\\40revokedcert. xmpptest.com,ou=XMPP Department,o=Your Organisation,l=The Internet,c=GB,cn=revok edcert.xmpptest.com) error certificate has been revoked (unspecified reason) 12/10 10:44:39 xmppd 21382 (root ) N-MBOX-Notice TLS certificate verificat ion failed 12/10 10:44:39 xmppd 21382 (root ) I-MBOX-Info successful setup of a recei ving db connection from mlinktrunk.xmpptest.com to revokedcert.xmpptest.com

Right, so this is acting as if strong auth isn't required, which isn't right.

Re-running gives me the (internal) errors I'd expect. So we may have a bug with reloading, since I suspect the option simply didn't take.

SO I'm not getting a connection (TCP level) to fippo's psyced-db or psyced-dwd at the moment. I'll give those another go later.

Otherwise, prosody8, ejabberd21, mlinkrelease, psyced-sasl all work, the rest fail.

Okay, psyced-db now works, but -dwd still gives me a connection refused.

psyced-db works? it should not currently

as both -db and -dwd are down

12/10 11:15:37 xmppd 21687 (root ) I-MBOX-Info Verifying certificate 12/10 11:15:37 xmppd 21687 (root ) I-MBOX-Info certificate (subject emailA ddress=fippo@mail.symlynx.com,OU=hangtime department,O=hangtime,L=The Internet,C =DE,CN=psyced-db.xmpptest.com) verified ok

Pretty sure it's the right server I'm talking to.

oh wait... my bad

it's supposed to be down

Okay. COnnecting securely to servers that aren't actually online would be quite a trick.

badlop: would you mind sending a from in the stream header?

yes, show me an example of problematic stream header

ok, patch applied and verified

thanks

yet another patch from interop to next release :)

that might even increase the chance of using sasl on the public network from 5% to 15%

heh

badlop, I've a bunch of those too, now.

fippo, Reminds me - you should be seeing tls as <required/> by mlinktrunk now?

I'd say that would justify claiming the interop week has been a success, then.

In as much as we've got most things to work and fixed a bunch of bugs.

and we have a better plan how to organize the next interop event

What might be test targets in the next event?

steve.kille, Well, we still have a day on this one. I'm aiming to spend this afternoon seeing if I can get XEP-0288 to work with fippo's servers.

dave: whoop!

\o/

fippo, DO you have a XEP-0288 that'll accept non-TLS connections from anywhere? It'll speed up my testing.

Are these extras getting recorded in the Wiki?

dave: i'll change the config of -dwd so it doesn't require tls

dialback without dial-back worked quite well, too. So we just need someone to write it up :-)

steve.kille, The extras are getting recorded, but I've not written up the '198 testing that Matt and I did yesterday, mostly because I didn't stay to see it complete. But we certainly got close.

fippo, Yes. Don't you have a draft XEP?

fippo, I should have probably mentioned that mlinktrunk does dialback without dialback as well. I don't know if anyone actually used it, though.

dave: i think psyced-db should have been using it the last two days

fippo, Ah, good.

Right. So it must be time to implement XEP-0288, then.

!xep 288

Zash: XEP-0288: Bidirectional Server-to-Server Connections is Standards Track (Experimental, 2010-10-04) See: http://xmpp.org/extensions/xep-0288.html

Yes, it's already a week old, clearly it's time to implement it!! :D

Dave Cridland: your implementation of google:queue works perfectly. It did highlight that our keepalive pings are *way* too frequent though :p

google:queue?

Tobias, Evil closed standard thing. But a good idea, so I've implemented it and started to draft a XEP.

Anyone care to give me an account on their server so I can test my client?

Does google:queue have client-facing controls?

Dave Cridland: is that draft already published as a XEP?

MattJ, Yes,

Tobias, No.

k

http://mail.jabber.org/pipermail/summit/2010-February/000528.html

Tobias, I need to write up both Google's implementation and a more standardsish one.

Oh well, I have an implementation minus any controls

we hacked it into Gabble for the N900. It's particularly important on GTalk because, unless you engage it, they whitespace-ping you every 30 seconds, so even if you have a sensible interval between pings... you still wake up all the time

Heh

ahh, this thing, i remember it now :)

Bob (BJ), xmpptest@prosody8.xmpptest.com, password xmpptest

Kev, notls should be working since last night

Ah, gerat.

remko: ^

You got an IP address for that. I don't seem to be able to resolve via DNS.

Bob (BJ), does your client support SRV records?

If not, interop failure #1 :)

Dave Cridland: ah, one catch. the version of Gabble on the N900 only looks for google:roster to trigger queue, not google:queue. (Google doesn't actually advertise the latter; I guess we only added that speculative check in a later version.) Annoying.

Dave Cridland, fippo, anyone: any familiarity with "unhandled critical CRL extension"?

MattJ, I can ask the X.509 people. Any idea what the extension in question *is*?

Looking at the certs, my suspicion is CRLissuer

which is present in all the certs

and OpenSSL prints <unknown> as its value when it prints the cert

I'll look into it - I suspect this is an issue with what Sodium's putting into the certs.

Thanks

How does it work for you? :)

OpenSSL source comment:

/* See if we have any critical CRL extensions: since we * currently don't handle any CRL extensions the CRL must be * rejected.

MattJ, We don't use OpenSSL for CRL checking, so we'd be affected in entirely different ways (if at all).

Ah, ok

So if it's complaining about the CRL itself, then it has to be the CRL, not the certs.

mattj: I can look into that when I found out who _removed_ my crl code

Kev, MattJ: thanks, i'll see if i can't connect to notls tonight

Dave Cridland, no, I think it's the certs

let me check

Ah no, you may be right

remko: Well, you shouldn't be able to connect to it :)

right

MattJ, Okay, so Sodium CA is inserting an extension into the CRL incorrectly.

Yay

MattJ, If I understand correctly, the extension "MUST NOT" be there because the CRL is being issued directly by the CA, but as far as I can tell it's mandatory in every other case, so OpenSSL could run into issues potentially with other CAs.

So it seems

You can disable the check (which is what I've done for now), but that's clearly not ideal :)

mattj: verify error code 36?

If that's X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION, yes

Yes, 36

I get that too (but at least revokedcert. fails properly

but so do all the other certs, no?

yes, but revokedcert fails with X509_V_ERR_CERT_REVOKED at least

fippo, what version of OpenSSL are you using?

mattj: it claims to be 0.9.8g but is probably debian pimped

MattJ, The only extension in the CRL itself that's critical is the Issuing DP - but that's optionally generated by Sodium CA. Just uncheck the box on the "Generate CRL..." dialog.

Ok, thanks

fippo, they changed the code in OpenSSL 1.x

that comment now reads:

/* The rules changed for this... previously if a CRL contained * unhandled critical extensions it could still be used to indicate * a certificate was revoked. This has since been changed since * critical extension can change the meaning of CRL entries. */

So, is there anything people need of me today?

Is there anything else we should have on the test plan? I'm fairly comfortable with both the server and client tests.

Looks fine

MattJ: Just checking - is notls set to only offer PLAIN?

Aha, good point - Prosody won't offer PLAIN on unencrypted connections either

I'll set it to offer just PLAIN

Kev: for the next time I have some dialback failures - but I need to write them up and think about how to test them

fippo: That'd be great, thanks.

We can start planning the tests for next time as soon as we're done here, if you want.

We should set up more tricky DNS situations next time

mixed A and SRV?

Like testing correct SRV target selection

That's hard, but sure.

and IDNA

and make a SRV query return a CNAME ?

Kev, it's not really hard, is it?

Zash: That's not an interesting test, I think.

Something working against invalid input isn't as interesting as it failing against valid :)

zash: I wanted to test that, but bind won't do it anymore

Or am I missing a security consideration why that's worth testing?

Iduno, but I have a CNAME catch-all thingy :)

But IDN and IPv6

Both worth testing.

Zash, IDN with X.509 is particularly interesting. I know we fail that one right now.

IDN + x509 sounds like fun!

!ping nödåtgärd.se

+1

aw

Zash: Pong from nödåtgärd.se in 7.021 seconds

:D

UTF8 processing overhead? :)

BTW Zash / MattJ, I upgraded Kanchil

!version

Zash: Kanchil is running Riddim version alpha on an unknown platform

Kev: You say?

I guess I should go and fix verse, riddim and clix to squish with the latest Prosody repo

:)

Also, latest says "I am running .."

Zash: Well, I should have updated.

I certainly tried to.

did you hg pull -u? :)

I think git updates the working copy by default when you pull

hg doesn't

Gotcha.

MattJ: git, true

hg up

hg pull says you should do hg up iirc

Bouncing prosody8

fippo, have you broken -db and -dwd? :)

I can't see the stream header you send, but Prosody is rejecting your stream:features, with "unbound prefix"

mattj: -db is down and I just changed sth in -dwd (which is mostly for dave)

Apt

Zash, "clix raw"

kind of

mattj: -dwd should work again

(not sure how it behaves in that test though :-)

MattJ: ohrly

Zash, it does XMPP auth for you, then acts as telnet

MattJ: But, for testing non-xmpp things :)

How would SRV help then? :)

(14:32:34) Send (217) <?xml version='1.0'?><stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' to='psyced-dwd.xmpptest.com' from='puncture.dave.cridland.net' version='1.0'> (14:32:34) Recv (222) <stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><switch xmlns='http://switch.psyced.org'><scheme>psyc</scheme></switch><dialback xmlns='urn:xmpp:features:dialback'><errors/></dialback></stream:features> (14:32:34) Send (102) <stream:error><bad-format xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>

dave: fixed already

fippo, No, still like that.

+1

ah... restarted the wrong server

Heh

I'm terrified I'm going to bounce prosody.im by mistake before the day is out

MattJ, Yeah, I'm glad I'm far, far away from isode.com.

Bouncing prosody8, this time with mod_dialback unloaded just to make sure :)

Dave Cridland, M-Link does dialback even with EXTERNAL?

MattJ, I just noticed that. :-)

MattJ, But the answer si that M-Link doesn't really overly care about how it authenticates to you, or indeed how you want to authenticate to it - it'll just care that it can authenticate you.

You mean as long as I have a valid cert I could say <message><body>Hey, I'm prosody.im</body></message>? :)

if I remove dialback from the stream header will it use EXTERNAL?

It will. But I've swapped around the processing order for features, so I'll update it shortly to use EXTERNAL.

ok

There's something up

I'm not getting any pongs for my pings to mlinktrunk

but Prosody reckons both s2s streams are up and running

I just bounced it, actually.

Now supporting a (very weakly tested) XEP-0288 Bidi.

As well as (I think) preferring to do EXTERNAL over dialback. Although that's obviously slower, so perhaps I should switch back.

Eh? :)

EXTERNAL has more round-trips.

Are you sure?

MattJ, With d-w-d, then yes.

Cheat

MattJ, You say "cheat", I say "optimized".

I'm still getting no pong

Maybe it's my fault, same with ejabberd

I still get pongs from trunk

Just bouncing it to clear everything, then I'll try.

OK, something really odd going on... I've got to do the school run again, but we'll figure it out when I get back.

k

The world falls apart without dialback :)

it doesn't without EXTERNAL :-)

Quite :)

so the path is clear

Plus d-w-d should be trivial to implement

btw: if you're bored you could implement bidi

I'd like to get 198 working first

then I shall

MattJ, Most of my bidi implementation time was thinking "But that can't be all it is..."

Dave Cridland, I do think it should be really easy to implement, especially in Prosody

all our code sends stanzas to the the incoming s2s stream

just Prosody redirects it at the last minute

bidi would just turn off the redirection

dave: same for me

there is a tricky thing about not sending db:verify on the same connection where I am not sure if this works as expected - but you should not have that problem

since you're doing dialback-3

OK, I think I've fixed that issue.

MattJ, You should be able to ping me now. Turns out that once it'd done the stream restart, it basically sat waiting, instead of deciding the stream was setup.

Dialback is enabled again so I can test 198

it should be enabling on outgoing streams now

MattJ, I'm doing EXTERNAL again, or should be.

Just bouncing that server yet again - I've been meaning to apply a patch that should stop an irritating crash.

Oh, gosh, that's odd. :-)

So, I'm now doing EXTERNAL again, and actually carrying on, only I'm *also* doing dialback. Whoops. :-)

:)

*sigh* I'm still doing that. Which is very annoying. But on the plus side, you're still not enabling 198, so I don't feel quite so bad.

heh

dave: the solution is to remove any EXTERNAL related code :-)

fippo, I know, I know. I'll make it an option, soon enough.

fippo, But the standard says we must, so we must.

Dave Cridland/fippo - sounds like the standards need fixing

We have way too many handshakes as it, and getting rid of the SASL handshakes for single connection secure S2S sounds like a senisilbe standardization objective

stpeter: what do you think?

steve.kille, Not so much fixing, as we need to document d-w-d properly, and ensure that it's perceived as acceptable.

I think I don't want to make more changes to 3920bis at this moment for feature of introducing too many perturbations late in the process :)

Althought helpful now, I am not sure the d-w-d name will be helpful long term

Ah, success. Now only authenticating once.

but I suggest that we complete more interop testing over the next 12 months, submit an implementation report based on the feature set in 3920bis, then rev the document again (hopefully after we have the address format fixed)

MattJ, So, I'm now fixed. Are you waiting until you've got a resource bound before enabling 198? That might be problematic on S2S.

stpeter: sounds like a reasonable plan to me

Dave Cridland, hmm, I don't think so - hold

there are enough changes between 3920 and 3920bis that I think continued interop testing and deployment feedback will be productive

while we work in parallel on those thorny internationalization issues

stpeter, I suspect future versions might (reference a) document about dialback-without-dialback :)

can we have a new name for it?

dwd is good, isn't it Dave? :)

MattJ: that would be good, I think -- based on what little I've read about it, which is only Dave's blog post

I don't think anyone else has had a XEP named after them before

dave: actually, what would happen if I tried to do EXTERNAL twice on a single stream (i.e. multiple authentications)?

I need to figure out what protocol mattj is an acronym for

!xep 198

MattJ: XEP-0198: Stream Management is Standards Track (Draft, 2010-03-05) See: http://xmpp.org/extensions/xep-0198.html

Dave Cridland, missing xmlns declaration - looks a lot healthier now

fippo, We'd drop the stream.

MattJ, Ew.... I've just noticed I'm requesting acks even when I'm only writing to the stream to ack... That's nasty. I'll fix that.

Dave: damn - but that would only allow to negotiate multiple source domains anyway

Hmm

Someone doing piggybacking asking for another remote domain - I'm not sure I'd considered that

mattj: "target piggybacking"? haven't seen that outside my lab

Oops. My experiment with source piggybacking is not going all that well.

I seem to be piggybacking my MUC domain around 6 times a second.

Does that make it the authentication stronger?

:)

Did you get my responses to your 198 message(s)?

MattJ, Yes, but they came through to my Gajim, of course.

Dave Cridland, so all is well?

badlop: selfsigned should be easy to find on public servers - CN=ejabberd is the most common certificate :-)

:)

Feel free to shoot on sight the admin of any server with CN="Prosody Example Certificate", that's expired, and self-signed

except for me

Hah

Wait... ejabberd doesn't do EXTERNAL already?

I was sure it did

no, it gets offered external but does not do use it yet

MattJ, I thought it did too - I'm sure I remember testing mine against jabber.org when it was ejabberd.

There was someone in jabber@ once

They ran a public server using ejabberd

Your poetry is useless. Doesn't even rhyme.

They were doing some testing on their laptop, and span up a test instance with their user db

behind a firewalled NAT, they claimed their ejabberd instance had sent out unsubscribes on behalf of their domain

they had the certs configured on their laptop, we put it down to EXTERNAL

mattj: you still want to update the wiki

Mmm, yes

I didn't conclude my testing because of the number of issues I had when I stopped advertising dialback :)

Maybe I just shouldn't do that

Heh

yeah... I wonder if I should have failed ejabberd actually...

but it was worthy enough to get offered external

I guess that is one of the points we should specify more cleary next time

Any 1.0 server capable of TLS can be offered external

and TLS was tested yesterday, no? :)

well... xep 0178 has this "only offer it if it will succeed" rule

Sure, but that's not a function of the implementation, but of the cert it uses

which is good because if the peer attempts external and this fails this will increase roundtrips

fippo, Right, I have a slightly better variant on my source-piggybacking attempt - can I point it at (one of the) psyced-* servers to test?