interop - 2010-12-08

Right, yes, DNS. fippo / Dave Cridland: What were the records you were suggesting adding yesterday?

Yesterday [20:56:49] [Isode Unclassified] Dave Cridland: [[Isode Unclassified]] Kev, When you're back, then, I have 217.155.137.58 (5222/5269) servicing mlinkrelease.xmpptest.com - feel free to give it a random hostname, like, say, mlinktrunk.xmpptest.com. :-)

Please check it's now right.

Kev, No A/AAAA records, but the SRV looks OK.

A is 217.155.137.58, AAAA is 2001:470:1f09:882:c0c8:f9ff:fec0:d982

Relly?

*really

mlinktrunk.xmpptest.com IN A 217.155.137.58

That *looks* right to me.

Ah, no, because I'm a twit.

"."

mlinktrunk IN A 217.155.137.58

Should be happier now.

If I hadn't cached the duff records.

Oh, I'd assumed you'd be querying athena.

Can you stick in the AAAA as well, in case anyone's doing IPv6 interop too?

Done

Marv.

Can any server developers confirm that the service xmpp:mlinkrelease.xmpptest.com is reachable now?

it is - but it does not seem to do tls anymore?

fippo, No, that's okay, haven't done that bit yet - doing that now. Thanks.

I have a draft post for a very brief "day one" report of the interop - still chewing thru the logs for details but I wanted to get a post going

could someone take a quick look for a review (I'm also going to post to comm team list)

Mail a draft to the interop mailing list?

ah

yes

mlinkrelease.xmpptest.com should now have TLS-lovelyness.

draft posted to list

bear, Matthew Wild was/is operating the CA.

k

dave: works with with dialback-after-tls, that boring sasl thing and d-w-d

bear, And you're mixing both company names (Isode, Collabora) and product names (ejabberd, SAFEchat)

I pulled from the wiki, hmm, guess I should also update/correct that then

bear, I think both are useful, but you're listing "SAFEchat" as a client developer (it's a client, the developers are BoldonJames) and Isode as a server (Whereas our server is called M-Link)

oh - I see. that's a personal glitch of mine - I can never remember m-link and have always called your software Isode

bear, Quite. Or Will will.

eeek

OK, I've flipped my mlinktrunk.xmpptest.com server into only accepting strong authentication (ie, TLS with a verifiable certificate) for anything within xmpptest.com

ok, text adjusted - sending new version to list

I'll do something similar for mlinkrelease in a moment. I'll require a valid cert, although mlinkrelease will accept dialback as sufficient and won't do CRL checking.

Actually, mlinkrelease will even accept no TLS at all, so I may not bother.

works - I get a policy violation dialback error

12/ 8 12:12:29 xmppd 32268 (root ) D-MBOX-Auth Rejecting (require tls peer control) connect from server psyced-db.xmpptest.com

fippo, Ah, yes, dialback errors too. :-)

fippo, Posh, aren't we?

you might want to put a <required/> into starttls :-)

fippo, Oh, isn't it there? I thought I'd got that as long as you sent a from (so it can look for the peer control) or if it's global (which it isn't on that server)

Oh. No, we don't - I carefully set a flag and then never use it. Well, that's an easy fix.

:-)

mh... I have a problem reaching trunk from -sasl

you don't offer external

12/ 8 12:38:53 xmppd 32268 (root ) I-MBOX-Info Verifying certificate 12/ 8 12:38:53 xmppd 32268 (root ) I-MBOX-Info certificate (subject emailA ddress=fippo@mail.symlynx.com,OU=XMPP Department,O=Your Organisation,L=The Inter net,C=DE,CN=psyced-dwd.xmpptest.com), detail (email=fippo\\40mail.symlynx.com,ou =XMPP Department,o=Your Organisation,l=The Internet,c=DE,cn=psyced-dwd.xmpptest. com) error revocation status unknown for this certificate 12/ 8 12:38:53 xmppd 32268 (root ) N-MBOX-Notice TLS certificate verificat ion failed 12/ 8 12:38:53 xmppd 32268 (root ) D-MBOX-Auth Rejecting (require strong a uth peer control) connect from server psyced-dwd.xmpptest.com

AH... I wonder if Matt's updated his CRL...

back to debugging x509 stuff :-)

No, it's just that Matt's not updated the CRL, so it's expired.

Hence M-Link can't tell if the CRL simply hasn't been updated, or if it's been replayed to conceal your certificate being revoked.

So, who's winning? :)

right ...

MattJ: can I send you my CSR?

Sure, mwild1@gmail.com

Zash: I'll be writing some suggested tests shortly.

Florian, ah, got your PM, thanks

So at least there's some guidance on what to test :)

XMPP Interop Event | 6th - 11th December 2010 | http://wiki.xmpp.org/web/Interop

:)

is there anything I need to do? Anything broken in Tigase that I should report back?

MattJ, Can you update the CRL fiole on the website?

Dave Cridland, yes, I realised I hadn't done that this morning

I regenerated it, but something distracted me from uploading

There's a reason to use https for CRLs - an attacker could serve an old CRL over HTTP with nothing more than DNS poisoning

Florian: As nothing much as been tested yet ...

MattJ, No, because CRLs expire, so a replay attack has limited value.

Aha

Technically, CRLs indicate when a new one will be issued, which is advisory rather than a hard expiration date, although it is generally treated as an expiration date

This one's in date for a year, so have fun while you can

Kev: ah, I missed that dns question earlier. I would like a srv record for no.such.xmpptest.com pointing to "."

lol

fippo: Ok. Why, though?

I second the request

don't ask questions :)

Kev: servers should stop attempting to connect that domain

Oh, should they?

Kev, Yes.

They should, see the recent discussion on the list

Permanently?

for as long as they would cache a normal SRV lookup

Oh, well, that's no time at all presumably :)

(For clients, anyway)

it's better than pointing your records to example.com and waiting for $TCP_TIMEOUT

this is a definitive way of saying "There is no XMPP service at this domain, give up"

Kev, Well, you *can* argue that it's the TTL, however I don't think that anything other than caching resolvers should actually cache.

no.such now has an entry of .

Thanks

Dave Cridland, why do you think that?

Although the results look a whole lot like they do for an entry that just doesn't exist.

mattj: old jabberd tried to cache itself - it was a bad idea

bear: I'll read your post in a moment, thanks.

fippo, why? (you may guess by now that Prosody caches)

MattJ, Because it's just as fast to run a caching nameserver on the same machine, and that's more likely to be written by people who know about DNS.

no worries kev - I need to give it a couple hours to let other TZ's a chance to respond

Fair enough

mattj: iirc it did not expire those records properly

:)

We fixed that bug a long time ago :)

So presumably, if the CRL's been updated, then everyone should now be able to connect to mlinktrunk.xmppest.com (and everything else)?

Does OpenSSL do CRL checking automatically? It's likely I could connect to you all along :)

no

MattJ, No, don't think so. We don't use it for that, anyway. (I think it can parse CRLs, etc, but I don't think it'll fetch them for you)

if you look at the manual, you'll see that it has error codes for CRL, but that they are "Unused by OpenSSL"

Lovely

Right, so, tests.

I'll put stuff on the wiki, but I'm thinking that something like this is sensible:

* Check a server can receive an iq response to a ping to each server, with whatever configuration.

mattj: i'm wrong i think

* Set some of the servers (all that support it) to require TLS on s2s, test iq still works.

* Set servers to require TLS with identity verification, test iq still works.

MattJ: i take everything back. I should have known better than to trust on openssl documentation

That tests a base level of interop using s2s and TLS, I think.

:)

* If any of the servers allow turning off dialback completely, doing that, and repeating.

(Dialback isn't bad, but relying on it is)

* Setting up a vhost on one of the servers, issuing and revoking a cert, and checking it can't then connect to any servers.

and everyone fails that except M-Link? :)

Kev, SO you want me to drop the TLS/strong-auth requirements for mlinktrunk?

I have no idea.

Dave Cridland: I think that'd be sensible for today.

First establishing that everyone will interop without TLS seems sensible.

Even though we know that'll work.

Fine by me

What else do people want to test? I think just checking TLS+s2s this week is sensible, as a baseline and a first effort at an interop event.

That's fine by me. Do we want to check reachability to MUC domains as well?

For the clients, I think checking that they'll all connect ok to a server. Checking they'll all connect to a server with only TLS. Checking they won't connect to a server without TLS and with PLAIN. Revoking a cert and checking they warn the user (Swift will fail this). Logging in with a user cert.

Dave Cridland: Each of the listed domains would be sensible, yes.

DO we know if all the servers are configured with an Interop CA cert?

I guess we'll discover that when we try testing identity verification :)

Will someone volunteer to set up a vhost with a self-signed cert, and one with a revoked cert?

Dave Cridland, the last outstanding CSR is Florian's, which I'm now processing (just sent badlop's)

I'm happy to set up both of those vhosts, actually.

Kev, I can do that.

Kev, Oh, or you can, great.

Florian's has no SANs... should we allow this? :)

Dave Cridland: Disadvantage of that is that it needs to be yet another server for you - as you can't vhost either of your existing ones?

Kev, Sure I can, can't I?

Not if you want to test interop between that server and the denied domains.

Ah. Well, yes. I couldn't test between other domains on the same server, no.

Okay, I've reconfigured.

Shall I run through first?

I think there's no harm in it.

So, mlinkrelease I get a pong.

(Which is just as well, frankly)

This all from mlinktrunk, BTW.

tigasetrunk, ping.

ejabberd21, ping.

SANs?

prosody8, ping.

psyced-db ping.

Florian: Subject alt names.

i see you guys found the 'topic' feature ;)

psyced-dwd ping, psyced-sasl ping.

kev: would you put that list on the wiki please?

fippo: I'm doing so at the moment, yes.

So I think that's it from mlinktrunk. All success.

Florian, the only domain you have listed is in the cn field, which isn't recommended

FWIW, I can even turn off checking that.

MattJ, You can add in other SANs before signing, though.

yeh

I can? Oh yes...

That was staring me in the face

dave: that was with optional starttls? It might be worth repeating with tls disabled

RIght, just setting up a test account for mlinkrelease.

fippo, What, disabling TLS at my end?

yes. so we see that it fails with servers that <require/> tls

I think that's one to do later.

fippo: My intention is to do TLS requirements later.

wfm

Florian, do you have a MUC domain?

fippo: I'll set up vhosts with invalid certs (self-signed, mismatch, and revoked) and test that s2s doesn't work.

kev: add an expired one

muc.*

fippo: Do you hate my time that much? :)

Okay, so from mlinkrelease, this time.

kev: and one that does not contain the vhostname

kev: :-)

Or my DSA setup, for that matter.

Yes, I said I'd add one with a host mismatch.

ah

mlinktrunk, ping

ejabberd21 ping

prosody8 ping

psyced-db ping

psyced-dwd ping

psyced-sasl ping.

since XMPP implementations should recognise both xmppAddr and SRVName, only one of them should be necessary in a cert, right?

In principle... But in principle they'll recognise a URI one as well.

.

In practise, most will rely on xmppAddr, and maybe sRVName.

tigasetrunk ping.

So full house from both.

As a general note to folk, you will need to bounce your servers, or force them to disconnect S2S some other way prior to running these tests.

Otherwise you may just be reusing connections.

(I say this because I only just remembered to do it)

So, who wants to go next?

Anyone?

just doing...

12/ 8 14:38:03 xmppd 32680 (root ) I-MBOX-Info certificate (subject emailAddress=fippo@mail.symlynx.com,OU=hangtime department,O=hangtime,L=The Internet,C=DE,CN=psyced-db.xmpptest.com), detail (email=fippo\\40mail.symlynx.com,ou=hangtime department,o=hangtime,l=The Internet,c=DE,cn=psyced-db.xmpptest.com) error revocation status unknown for this certificate I shouldn't be seeing that, I don't think.

http://wiki.xmpp.org/web/Interop#Testing

full house from psyced-db to anyone with tls, two failures without tls (psyced-dwd and psyced-external, but they enforce tls so that is expected)

fippo: It'd be great if you cut put that in terms of my test numbers for me, please.

psyced-sasl, surely?

kev: will do on the wiki

dave: yes

fippo: Or that, thanks. I'm happy to put it in the wiki, if you paste something here, equally.

BTW, as far as I remember, all servers supported XEP-0199, and gave a positive result (ie, not an error).

and all servers support the good old jabber:iq:version (I prefer that to ping somehow)

Kev: arr, your test structure conflicts with my host setup

fippo: I think it just means that some of your hosts don't participate in some tests.

yeah

e.g. ones that require TLS don't do test 1, they wait until test 2.

Well, we've not disabled TLS, so those ones should also work, still, surely?

Well, true.

yeah

they will fail with tigase, but that is expected

Kev, it says notls is not yet set up - feel free to point that at me

I can set up a vhost with no c2s/s2s TLS

MattJ: On the same host, or a different one?

The problem with you using a vhost on one of the test systems is that you then can't test those.

MattJ, On a different server to prosody8, so you can test?

Good point

Kev, point it to matthewwild.co.uk

Ta.

brb

btw, I think everyone has certs now - shout if I missed a request

ANyone editing the Wiki now? If not, I'll stick my other results in.

I'll be requesting more certs shortly, and then asking you to revoke one of them :)

Dave Cridland: I am not.

dave: I just edited

Right, as did I, but quickly enough apparently.

"they will fail with tigase, but that is expected"

Expected because...?

Kev: because tigase does not do tls, so if it meets a server that enforces tls it should fail

So, server people, are there any basic s2s interop tests that we should be adding that I haven't yet done?

fippo: It will never do TLS over s2s?

kev: afaik no

Anyway - who's next on doing the tests?

I am not seing a version attribute on the stream headers either

MattJ, ?

back

I'm next I think

OK.

stpeter, Are there any other server implementors we could bring in, do you think?

have we pinged Openfire and jabberd2?

as a response to Dave's question: [15:04:05] <Artur> no, this is what I am working on right now :-)

(TLS on S2S)

stpeter: In as much as we pinged the relevant XSF lists, and I assume they listen to them.

rightio

Pinging them directly would not be a horrible idea.

stpeter, Who would we ping for those?

I haven't seen a reply to the last message I sent to some Openfire folks

Coversant?

MattJ, Good point.

Tomasz Serna is the jabberd2 contact -- mailto:tomek@xiaoka.com

Dave: if time permits (and that is a large if) I'll try to setup jabberd14

stpeter, poked in jdev

heh ok

MattJ: Tomasz is there?

smoku

right

that's the one :)

I'll ping Jason Frankel at Coversant

I was just writing a mail to Dave Richards.

But two won't hurt.

yep

email sent to Jason

Dave Cridland, did you ping manually?

MattJ, Once a year, yes.

.

MattJ, No, I used Gajim.

s/writes/adopts/

MattJ, Started a chat to each server and typed /ping

Now there's an idea

MattJ, I'm full of 'em.

I didn't say it was a good one

I wonder if we need to cull the list of XMPP servers at http://xmpp.org/xmpp-software/servers/

Works, amazing

stpeter, email them all, if they don't respond - remove them? :)

stpeter - I was thinking of suggesting that after N rounds of interops we could start making active/inactive categories

stpeter, It might be interesting, if we can get these interop sessions to happen reasonably frequently, so say that in order to be listed to need to at least particpate in interop.

MattJ: even better, ask them to participate in interop, if they don't participate then remove 'em

Heh

heh

GMTA

and I thought I was being harsh

steve.kille, Fools seldom differ.

quarterly interop week

stpeter, rather.

Didn't look at what "st<TAB>" gave me.

brb

or we make it a requirement to run a server at *.interop.xmpp.org :)

xmpptest.com also

In the Prosody early days we had a test script that pinged each server there daily

MattJ, I'm not mad keen on constantly running an interop test server, to be honest. Unused/unwatched servers tend to develop embarrassing failures at the worst moment.

bear, just point xmpptest.com at prosody.im, thanks ;)

I'm inclined to leave the DNS in place ready for next event, and to have the CA kept around ready to run up, but I don't think it's very valuable to have them up between events.

Anyway, the server would be watched by me

Plus it increases the value of the interop events :)

kev +1

Interop events are inconvenient, there's little reason I need all of you here to do what I'm doing right now

MattJ, It's a social thing. We're all going out to drink beer afterward, right?

Orange juice for me please

MattJ, Sure. Pay no attention to this bottle of vodka.

I wish Gajim would let you inspect the server cert

as a client

Bouncing prosody8

mlinktrunk: OK

mlinkrelease: OK

ejabberd21: OK

pscyed-db: OK

pscyed-sasl: FAIL

Fail?

psyced-dwd: FAIL

Did you disable your cert (or TLS)?

Going to check

verify result 34

ah... that critical extension thing

Looks like they hung up on me

Ah - MattJ, you'll need to make yourself a new cert.

Aha

How could they?

they're evil

Natch.

Can someone confirm whether I've screwed up DNS for notls.xmpptest.com, please?

It looks to me like I have.

Oh.

;; AUTHORITY SECTION: xmpptest.com. 3600 IN SOA xmpp.org. hostmaster.xmpp.org. 2010120803 14400 3600 604800 43200

notls.xmpptest.com. 0 IN A 67.215.65.132

That means it's using the serial that's two older than the current (05)

zero-TTL?

The intention was 1hour

Oh, no, that's opendns being crap.

SOA serial : 2010120803

Bouncing prosody8

Dave Cridland, why did M-Link not fail?

Also direct to Athena.

MattJ, Not configured to mandate TLS or strong-auth, so it'll have done dialback.

Now my client can't log in - "no shared cipher" :(

Hmm

Key/cert mismatch I think

Dec 08 15:32:12 s2smanager debug pscyed-dwd.xmpptest.com has no SRV records, falling back to A

Grr

o_O

MattJ, It seems to...

$ host -t srv _xmpp-server.psyced-dwd.xmpptest.com Host _xmpp-server.psyced-dwd.xmpptest.com not found: 3(NXDOMAIN)

_tcp

oops

Ok

and you pinged pscyed, not psyced

Ah, yes...

Grr

All work

Ok, DNS is confusing me.

Why?

We're up to 2010120806, but I'm still getting 2010120803 from athena.

Isn't it reassuring if your software works better then you do :)

Have your reloaded bind, and, if so, is there anything in its logs about why it's refusing to load the zone?

Florob, :)

I'm not even sure where bind logs.

daemon.log for me, as named

IIRC it's the default syslog output - /var/log/messages or somesuch

Ta.

Ah.

no.such IN A . Isn't a valid line.

wiki updated

but the other servers accept it?

Wait - shouldn't that be SRV?

I was just asked to put a line with '.' in for 'no.such.xmpptest.com', so I assumed it was A that was wanter.

s/wanter/wanted/

No, SRV, sorry

Kev: the one that fippo mentioned was a SRV record IIRC

the target is just .

Ok, working fine now, ta.

Council in 15?

So I can get onto setting up the invalid TLS domains now :)

Yep.

jup

expiredcert, mismatchcert and revokedcert are all up - albeit without the certs they claim to have.

i've installed the cert in ejabberd21, enabled TLS in c2s and s2s, it connected with TLS to all the other 7 Interop servers except mlinkrelease.xmpptest.com, which apparently couldn't setup TLS

badlop: Is that with TLS required, or simply allowed?

badlop, Oh. Curious. One sec.

allowed, becayse ejabberd first attempts TLS, if anything fails it attempts non-TLS

I see it working, which is confusing. One sec, let me bounce my server and we'll have another go - it's mlink release, not trunk, right?

12/ 8 19:20:37 xmppd 07463 (root ) N-MBOX-Notice Peer ejabberd21.xmpptest.com authenticates via TLS. 12/ 8 19:20:37 xmppd 07463 (root ) I-MBOX-Info successful setup originating db connection from mlinkrelease.xmpptest.com to ejabberd21.xmpptest.com

And I'm getting all that kind of stuff on mlinkrelease, which looks like it should be working.

And I can indeed ping ejabberd21 after a restart, too, from mlinkrelease.

and do you get the exact same report with mlinktrunk?

Ah. No. CRL failure. But, it still sets up a session.

Yup, pings there too.

badlop, When you say "connected with TLS", and "couldn't setup TLS", do you mean TLS itself, or EXTERNAL?

the logs don't explicit, so i imagine it's TLS

i'll check the source now

so, don't worry yet about what ejabberd reports

badlop, Well, we're seeing TLS setup but the CRL fail.

Looking into that, it seems the CRL DP has a PEM-encoded CRL, whereas the standard mandates a DER-encoded one. Our software is being picky. I'll figure out some instructions for MattJ

No, indeed, the PEM one does crl.pem in PEM, and the DER one does crl.crl in DER.

Ooops. Wrong window.

Although right conversation, bewilderingly.

:)

I figured you were just continuing your outloud debugging

MattJ, Can you export the CRL in DER format - that'll generate a crl.crl for you to put on that website.

Overwrite the PEM one?

Yes. Standards says DER.

Try now

Dave Cridland: right now, ejabberd -- mlinkrelease: s2s with TLS works

umm, ejabberd -> tigase doesn't work with TLS, because tigase response doesn't include stream:features: 192.168.001.011.36481-094.023.164.209.05269: <?xml version='1.0'?> <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' to='tigase.me' version='1.0'> </stream:stream> 094.023.164.209.05269-192.168.001.011.36481: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='f1cf3e1a-8405-4146-82d7-454d3cfb2105'> </stream:stream>

badlop, Right, Tigase doesn't do TLS over S2S.

That's not just not doing TLS, though - that's not doing XMPP 1.0, is it?

(Yes, I realise TLS is a requirement for XMPP 1.0 as well)

well, tigase doesn't advertise supporting xmpp 1.0, so tigase doesn't lie

Heh, true enough.

RIght, so something's up with the CRL checking code at the moment, so I've disabled that in mlinktrunk. :-(

Dave Cridland: I did hear back from some folks at Coversant

Excellent.

Whatsaythey?

they said they'll check into it :)

BTW, as to the 6-month schedule, perhaps it would be good to schedule the interop weeks something like mid-way between Summits

e.g., April/May and then October/November

just a thought

Yes, we could do. Or could do it in the lead up to summits, both have merit.

true

well, one interop week at a time :)

the lead-up makes quite a bit of sense -- raise issues that need to be hammered out

This is our first interop week, and it's showing things that need doing next time around, etc, so I think these will be iterative.

that's good

Some responsibilities were clear in advance, some not so.

That the iteam should sort out certs and dns was decided, and obvious.

Who should be responsible for cajoling vendors into participating was left somewhat in the air, as was who should be deciding on what gets tested.

I've appointed myself the latter, as Council Chair makes some sense.

In the absense of any group decision.

Next time around it'd be good to have DNS/Certs/Test plans in advance :)

nice: https://support.process-one.net/browse/EJAB-495

yes, agreed

MattJ, You about?

Or alternately, can anyone get me the certificate off ejabberd21.xmpptest.com? openssl's s_client isn't quite clever enough to grab it.

dave: I told you to get my patched version :-)

fippo, We have starttls xmpp, but it sends the hostname not the domain.

dave: so your patch is similar to the crippled one the openssl people accepted for c2s :-p (shall I start a rant about openssl and how to get a feature patch accepted?)

there's xmpp starttls support in openssl?

There is

there is - c2s, without support for servers that actually use srv records

handy

fippo, Your patch is better?

In, 0.9.8g and above IIRC

dave: you can specify starttls to+from indepently on the commandline

no, later

fippo, Oh, cool. Where is it again?

oh, *without* srv

zash, Not later. Now!

Dave Cridland: Later version of openssl :/

zash, Oh... Right.

badlop: do you see any hints why a host named 'fippo.testing.openssl' is not offered tls (or version 1.0) from ejabberd21.xmpptest.com?

typically, that tool works with ejabberd

fippo, Ah, yes, same for me. (With that tool, nice).

dave: it works with -connect jabberd.jabber.ccc.de -starttls_to jabber.ccc.de

fippo, WOrks against mlinktrunk, too.

fippo: how can i reproduce that problem myself?

badlop, Can you send me the certificate?

dave: already gave you a link

Dave Cridland: if that link doesn't help, ask me again the cert

badlop, No, I missed the link.

badlop, All sorted now.