[14:35:32]<Simon> Kev, how's Doomsong's cert fixing going?[14:36:05]<Simon> Or are you gunning for DNSSEC being widespread enough that you can drop it? :)[14:36:09]<kevin.> yeah, only one kev smith. and i'm not that[14:37:43]<Kev> Simon: I need to sort this out, thanks for reminding me[14:37:46]*Kev puts into todo[14:38:25]<Kev> Conveniently, I'm in the middle of capturing todos at the moment :)

[15:33:00]<fippo> sure. nobody seemed to care back then[15:34:36]<fippo> 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[15:34:54]<fippo> and 51% are most likely non-mitmable

[15:35:16]<fippo> which is not bad[15:36:09]<Simon> how many of that 8.5% are also doing certificate auth?[15:36:59]<fippo> I don't think many people are requiring certificate auth[15:37:14]<Simon> so still mitm-able then.[15:37:20]<fippo> sure.[15:37:39]<fippo> but manifesto is not about changing that[15:38:19]<Simon> I'm going to log a check for that on https://bitbucket.org/xnyhps/xmppoke/issues?status=new&status=open[15:39:37]<fippo> there is no safe way to tell if a remote server enforces your cert

[16:27:24]<Kev> fippo: There is for C2S, mind.[16:27:49]<Simon> kev: cert checking or Jingle?[16:28:06]<Kev> A way to check that the other end's connection to you isn't MITMable.[16:28:44]<Simon> yeah - imho this is important. (ref: one of DWD's speeches on certs and authenticity etc etc)[16:29:04]<Kev> Simon: So, do you use -PLUS? :)[16:29:14]<Kev> fippo: So, ready for a revote on Wednesday, then?[16:29:14]<Simon> g+?[16:29:22]<fippo> kev: yes please[16:29:36]<Kev> Simon: No, SCRAM-SHA-1-PLUS. [16:29:45]<Kev> That's the only way the server can check that the client's not going to be MITMd.[16:30:00]<Simon> kev - yes. [16:30:06]<Kev> And even that's not perfect.[16:30:09]<Simon> I'm more concerned about s2s in this case.[16:30:38]<fippo> 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?)[16:31:02]<Kev> fippo: -PLUS doesn't help with S2S, but it helps greatly with C2S.[16:31:30]<Kev> But only if a client doesn't allow a downgrade to PLAIN.[16:31:35]<Kev> Which ~=everyone does.

[17:28:47]<MattJ> I've been considering taking a client and making it "totally secure", and re-releasing it[17:28:55]<Kev> Yet, indeed.[17:28:57]<MattJ> Swift is obviously a good candidate[17:29:16]<Kev> There are a number of sensible things to do there, and motivation to do them.[17:29:27]<MattJ> I'm talking about removing support for anything but TLS 1.2, SCRAM-PLUS, etc.[17:29:46]<MattJ> No certificate validation bypass[17:29:59]<Kev> This doesn't sound like fun[17:30:06]<MattJ> For whom? :)[17:30:30]<Kev> Well - what's the motivation?[17:30:54]<Kev> Protection against downgrades is very sensible, and doesn't stop users using the client.[17:31:10]<Kev> But stripping out widely used things because they're not deemed to be maximally secure doesn't seem altogether helpful.

[17:31:20]<Kev> How many TLS 1.1 vulnerabilities are we seeing?[17:31:44]<MattJ> Just because we aren't seeing them doesn't mean they aren't there[17:31:48]<Kev> And there's no point forking Swift for this, BTW. We have a mechanism for enforcing policies by sysadmins.[17:32:00]<MattJ> Everyone should realise that by now :)[17:32:22]<MattJ> Kev, then I'd repackage it at least

[17:32:48]<Kev> Why?[17:32:49]<MattJ> and you probably wouldn't want me calling it just "Swift" at that point[17:33:01]<MattJ> then how do I configure it?[17:33:17]<MattJ> brb[17:33:36]<Kev> 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.[17:34:17]<Simon> the node-XMPP guys are doing some good work to move their code to nicely support TLSv.1.2

[20:03:38]<Simon> That's really nice MattJ[20:04:28]<Simon> In terms of the text - it might put it in context to describe the problem/why at the start.[20:04:56]<MattJ> It's configurable by the admin, but this is the default message - I'm happy to take suggested amendments[20:05:07]<MattJ> I don't want it t o get too verbose[20:05:17]<Simon> yes.

[20:09:29]<MattJ> I should clarify that the list is completely automated - it is only sent to users who have contacts on unencrypted s2s links[20:09:51]<Simon> I'd expect nothing less from the Prosody team.[20:10:39]<MattJ> 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[20:11:02]<MattJ> which also means I'm aiming for UTC...[20:11:10]<MattJ> unless people think that's a bad idea[20:11:56]<Simon> TZ of least confusion.

[20:12:40]<waqas> MattJ: Do we have good error responses on lack of TLS?[20:13:04]<MattJ> waqas, as good as could be expected[20:13:10]<waqas> Both for local users, and for remote[20:13:18]<MattJ> I'm thinking of having mod_manifesto rewrite them for the test day though[20:13:44]<MattJ> waqas, yes, the error message says that the delivery failure was due to lack of encryption[20:13:53]<waqas> The folks we probably want to make the most aware of this are the people on servers without good encryption[20:14:05]<waqas> Not the local users, who are already on a good server[20:14:08]<MattJ> Yep[20:14:15]<MattJ> I considered spamming them, but... ;)[20:14:15]*Simon is impressed with Prosody's preparedness.

[20:23:03]<fippo> kev: i think it would be good to have jabber.org reject non-tls connection[20:23:10]<Simon> https://xmpp.net/result.php?domain=jabber.org&type=server[20:23:15]<fippo> otherwise "but it works with jabber.org!!!!" is true[20:23:19]<Simon> and fix it's cipherlist[20:23:38]<Kev> Simon: Nothing on that page looks incompatible with servers participating in the event.[20:23:44]<Kev> To me.[20:24:00]<Kev> fippo: Yes, I expect we will.

[20:25:18]<fippo> i wonder why jabber.orgs pubkey score is sooo low[20:25:52]<Kev> Because it bundles the root (Which is a pretty sensible thing to do)?[20:26:19]<MattJ> Why is it a sensible thing to do?[20:26:39]<Kev> MattJ: Because if you're going to do leap of faith, having the root gives you a better basis for future upgrades.[20:27:00]<Simon> Presumably the root should come from outside the connections / OS /Browser.

[20:27:10] *** Alex shows as "away" and his status message is "Auto-Status (untätig)"

[20:28:03]<Simon> also the cert is for conference.jabber.org.[20:28:24]<Kev> The cname is c.j.o, which isn't the same thing.[20:28:50]<Kev> It has the right SANs in it as far as I know.[20:29:08]<fippo> there is a bug for xmpp.net that it should show SANs[20:29:46]<fippo> i even have code for it but can't get the tool itself to work for me[20:31:00]<Simon> fippo: this one https://bitbucket.org/xnyhps/xmppoke/issue/3/show-certificate-subjectalternativenames ?[20:31:25]<fippo> simon: yeah

[22:06:36]<MattJ> I know what the issue is, there is a '.' at the end of the hostname[22:07:01]<Simon> the cert or the contact?[22:07:21]<MattJ> Someone is trying to send something to "jabber.org."[22:07:36]<Simon> right[22:07:36]<MattJ> I vaguely recall something about this in the RFC

[22:10:09]<MattJ> 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]. "

[22:10:39]<MattJ> So it's a client bug for allowing it and a server bug for not stripping it either I suppose[22:11:03]<Simon> server bug for storing it in the roster table too?[22:11:30]<MattJ> Not necessarily storing it[22:11:46]<MattJ> I don't know if roster entries must be in normalized form