Ge0rGIs it possible to test XEP-0368 Direct TLS without actually creating the DNS records? You can't put SRV into hosts files :(
Guushas left
jonaswGe0rG, test the implementation at the client or at the server?
Ge0rGjonasw: test a server deployment
KevGe0rG: dnsmasq running locally.
jonaswmost clients allow to specify a port
jonaswand a host to connect to explicitly
jonaswso you’d use that
Ge0rGYeah, I once enabled it in Gajim with a dozen clicks or so.
Yagizahas left
Wiktorhas joined
Wiktorhas joined
zinidguys, what string should be put in SNI in the case of IDN domain? original or pynnycoded?
jonaswzinid, interesting question, that I’d like to know too :-)
zinidah, found in RFC6066
zinid"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte
string using ASCII encoding without a trailing dot. This allows the
support of internationalized domain names through the use of A-labels
defined in [RFC5890].
zinidso should be punnycoded
jubalhhas joined
jonaswmhm
danielhas left
Ge0rGI wonder if I should move the yax.im A records to point to the XMPP server instead of the web server, so that clients that fail SRV will still properly connect.
Guushas left
Ge0rGIt looks like 15% of client connections ignore SRV for yax.im
danielhas left
edhelasHi, I'd like to know the state of this PR ? https://github.com/xsf/xeps/pull/500
jonaswedhelas, I think some council votes are pending, I haven’t processed last council meetings minutes yet, sorry
jonaswedhelas, most efficient will be if you ping me on the PR, I’ll take care of it when I get home
edhelasokay
Guushas left
edhelasI'm also planning to do other PR on 0060, maybe today
dwdhas joined
Guushas left
valohas joined
valohas joined
Flowhas joined
Guushas left
goffihas joined
Wiktorhas joined
ralphmhas left
danielhas left
valohas left
Guushas left
valohas joined
Wiktorhas joined
Wiktorhas left
Wiktorhas joined
Wiktorhas left
Wiktorhas left
Wiktorhas left
Wiktorhas left
zinidhas left
Wiktorhas left
danielhas left
dwdhas left
dwdhas joined
Guushas left
Wiktorhas left
stefandxmhas joined
edhelasjonasw what is your github account nickname ?
jonaswedhelas, @horazont
edhelasdanke
jonaswde rien
danielhas left
dwdhas left
dwdhas joined
jubalhhas joined
edhelasI'm also planning to do another PR on 0060, but I'd like to get some feedbacks here before
edhelasI'd like to expose the access_model of the nodes in their metadata
edhelasI'm wondering if this could brings issues
edhelasbasically adding pubsub#access_model there https://xmpp.org/extensions/xep-0060.html#entity-metadata
lovetoxhas joined
danielhas left
stefandxmhas left
Zashhas left
danielhas left
daniel> It looks like 15% of client connections ignore SRV for yax.im
Would be interesting to know what clients those are and whether or not they are using Tor
jjrhhas left
danielconversations.ims numbers are equally high. Maybe even closer to 20%
Wiktorhas left
Wiktorhas joined
danielhas left
lumihas joined
Ge0rGI'll do some version logging for the next days.
jonaswGe0rG, how are you going to track that?
jonaswalso, I’ve seen clients fall back to A/AAAA if they try to connect before DNS is up
Ge0rGjonasw: modified mod_query_client_ver in prosody. Non-SRV connections to yax.im all come through a NAT on the web server
jonaswthe SRV lookup fails (and they cannot necessarily distinguish the reason) and go on with A/AAAA, which may then pass :/
Ge0rGI've had very often "Connection refused" errors from my own yaxim instance for a week or so, and then I realized the NAT rule got reset.
jonaswI think that the A/AAAA fallback may be doing more harm than good
jonaswI’ve had very confusing certificate errors for weeks until I realized that A/AAAA pointed to a test instacne which wasn’t supposed to be live where the certificates had expired. I don’t even want to know what happened *before* the certificates expired ...
Ge0rGjonasw: it's clearly a bug, the question is just _where_.
jonaswthe root cause is probably that applications cannot (do not?) distinguish between "network errors" and "records don’t exist"
Ge0rGYeah.
jonaswwith validating resolvers, you’ll also always rather see a generic validation error in favour of a NXDOMAIN if the backedn experienced network errors
jonaswso that isn’t going to go away
jonaswwell, okay, that actually improves things.
jonaswif the API exposes the difference
tim@boese-ban.dehas joined
Ge0rGIt looks like most Non-SRV connections are from yaxim, followed by Conversations. And then some Pidgin and Cackle.
Ge0rGHowever, the stats are skewed because I query on new connections, and those happen far more often on mobile
tim@boese-ban.dehas joined
jonaswand your userbase is probably also skewed
jonaswtowards yaxim
Ge0rGNo way! I'm a neutral server operator!
jonaswthat may be, but are you also a neutral app developer? ;-)
danielcackle is just a Conversations fork though
danielor theme
Ge0rGThere also was one MAXS.
jonaswMAXS <3
MattJMAXS <3
Flow♥
Ge0rGdaniel: did you change the DNS records for conference.siacs.eu around noon on Saturday? My prosody wasn't able to resolve the server in the morning, then came up with an old(?) IP aroung 11:15, and then failed to resolve again.
winfriedhas joined
fp-testerhas left
fp-testerhas joined
Wiktorhas joined
danielGe0rG, we switched over on friday at ~23:45
danieli don't think i've touched the records since
Ge0rGdaniel: I'm sure this was a weirdness in prosody's DNS code, but I wanted to be 100% sure with that.
Ge0rGdaniel: and 78.47.217.197 was the old IP?
danielsounds about right
Ge0rGdaniel: I'll quote you on https://prosody.im/issues/issue/1001 if that's ok.
la|r|mahas joined
danieli just created srv records. but that doesn't seem to help
tim@boese-ban.dehas joined
winfriedhas left
danielor maybe it did and just takes some time to propagate https://status.conversations.im/reverse/conference.siacs.eu/
daniellet's wait and see what happens
Ge0rGprosody has some strange bugs in handling CNAMEs.
lskdjfhas joined
Wiktorhas left
goffihas left
goffihas joined
xnyhpshas joined
xnyhpshas left
Ge0rGhas left
jcbrandhas joined
andrey.ghas joined
jcbrandhas left
zinidhas left
danielcreating the srv record did in fact fix it
Ge0rGdaniel: ...worked around ;)
Ge0rGhas left
danielsemantics
Ge0rGThe XSF is 90% about semantics.
stefandxmhas joined
tim@boese-ban.dehas joined
Guushas left
sonnyhas left
sonnyhas joined
Wiktorhas left
jabberatdemohas joined
jabberatdemohas left
dwdCNAMEs are really odd. They shouldn't work (but might) in combination with SRV records, for a start.
Ge0rGYeah, but they don't even work without SRV.
dwdGe0rG, Arguably they shouldn't - RFC 6120 § 3.2.2 only says A or AAAA. That probably implies CNAME (and DNAME), though.
jonaswDNAME is entirely DNS-server-side anyways, isn’t it?
dwdGe0rG, You *can* - in principle - use CNAMEs for, say, _xmpp-server._tcp.example.org. Just not for whatever the hostname it looks up to is.
danielhas left
dwdjonasw, There's a fallback to do that, but I think there's an EDNS0 flag for handling them client-side.
Ge0rGdwd: but the service name is a CNAME, and it doesn't resolve
dwdGe0rG, What do you mean by the service name?
Ge0rGdwd:
conference.siacs.eu. 300 IN CNAME xmpp-hosting.conversations.im.
xmpp-hosting.conversations.im. 300 IN A 91.250.85.114
Alexhas joined
dwdSo that only works is the process looking up decides it'll use gethostbyname/getaddrinfo, or else do DNS directly but follow CNAMEs.
dwdNeither is spelt out in RFC 6120 § 3.2.2.
Guushas left
Ge0rGI'm not sure RFC6120 is the right place to define how DNS should work.
Ge0rGHowever, with the wording you referenced, I could blame daniel for not following the RFC, instead of blaming prosody for having a broken CNAME lookup mechanism.
stefandxmhas left
jonaswgiven that we have SRV, I don’t see the reason for CNAMEs in any case.
jonasw(as mentioned earlier, I think the A/AAAA fallback does more harm than good)
stefandxmhas joined
Ge0rGjonasw: SRVs happen to be black magic from the future for many DNS providers.
jonaswwhat
HolgerSo the Prosody people broke their CNAME caching in order to strictly follow RFC 6120?
zinidlol
Ge0rGjonasw: with some DNS operators, you can't add SRV entries.
Guushas left
MattJHolger, just for the record... no :)
jonaswGe0rG, I understood, but I am horrified
jerehas joined
zinidso these providers don't follow RFC6120?
zinidwe need to notify them
Ge0rGzinid: oh, they do.
Ge0rGit's the others that don't.
Holgerjonasw: You might have the CNAME record for other services anyway. Apart from that you might want to maintain the SRV targets in a single record and have multiple CNAMEs pointing to that.
Guushas left
Holgerdwd: I agree with Ge0rG that 6120 sounds like the wrong place to specify such things. But if it's the right place, then missing CNAME support sounds like an obvious 6120 bug to me.
dwdHolger, I don't think it is specifying how DNS works. I do think it ought not to be quite so precise in the lookups involved.
Guushas left
Alexhas left
HolgerJust sounds wrong to me that each and every protocol that uses DNS names should specify "yes we also resolve CNAMEs like everyone else".
HolgerAs opposed to just specifying the parts that are *specific* to this protocol.
Alexhas joined
pep.has left
sonnyhas left
jonaswI bet there’s some wording in the document defining CNAME that resolvers (including stub resolvers) MUST follow CNAMEs transparently or so
Yagizahas joined
Yagizahas joined
danielhas left
danielhas joined
sonnyhas joined
sonnyhas joined
Guushas left
Guushas left
Flow> [14:07:11] jonasw: (as mentioned earlier, I think the A/AAAA fallback does more harm than good)
Given the amount of DNS implementations not supporting SRV RRs, I doubt that this is true
Flowwhat Holger said
zinidjust let's use NAPTR to break things completely :)
jonaswFlow, is there a list of such popular services?
jonaswand IM services hosted there? they should apply some pressure.
Flowjonasw: I'm not only talking about services, more about all things DNS
jonaswthe issue with the fallback is that it forces services using SRV records to also have valid A/AAAA records or at least it constraints what you can do with the A/AAAA of the domain.
Flowjonasw: It doesn't force them
Flowbut yes, for maximum connectivity you want to have your XMPP domain also resolve A/AAAA
jonaswFlow, no, if there are intermittent issues which makes the client believe that the SRV records don’t exist, they fall back to A/AAAA
jcbrandhas left
jonaswand that’s an issue
Flowit's an issue if there are no A/AAAA records
jonaswor if the records point to something which isn’t the XMPP service you wanted to connect to
Flowbut how would not having the A/AAAA fallback improve the situation
jonaswif there are no A/AAAA records, it is more or less obvious to clients that they should re-try later because it’s most likely network
jonasw(or a configuration error)
jonaswbut if end up in the fallback (e.g. on a transparent stream-managmeent reconnect) and the fallback is not the XMPP service you’re looking for, a lot of funny stuff can happen, from certificate errors, over stream errors to authentication failed
jonaswall of which will probably nuke the clients state
jonaswthat’s what I mean by "harm"
jonasw(I had that once with an unfortunately configured A/AAAA record which pointed to another XMPP service)
jonasw(took me weeks to figure out what the reason for those errors were)
SamWhitedhas joined
Valerianhas joined
Ge0rGhas joined
winfriedhas joined
goffihas left
mimi89999has joined
goffihas joined
danielhas left
danielhas joined
waqashas joined
Wiktorhas joined
Flowjonasw: I see, but without the fallback you wouldn't even be able to connect as soon as SRV breaks for some reason
danielhas left
danielhas joined
mimi89999has joined
jjrhhas left
SamWhitedhas joined
jonaswFlow: yes, and treating it as a network error would do the right thing (retry soon)
Flowjonasw: Not if it's your resolver lib not being able to perform SRV lookups
Flowor you home router resolver
jonaswbut you can't distinguish a wrong A/AAAA you should never have seen from incorrect credentials or something
jerehas left
jerehas joined
Flowincorrect credentials should return a well defined error, no?
Flowbut, yes, the situation is not ideal
stefandxmhas left
jonaswFlow: sure it does, but you can get such an error when connecting to the wrong xmpp service due to A/AAAA lookup
jerehas left
jerehas joined
Wiktorhas left
Wiktorhas joined
Wiktorhas joined
Flowi see
Valerianhas left
sonnyhas joined
sonnyhas joined
Guushas left
dwdhas joined
dwdhas joined
Ge0rGWhen I send a MUC join and lose my connection, so that it will be closed by a 0198 timeout, prosody will send error responses to all queued stanzas, including individual MUC participants. Is that good / bad / ugly / all of the above?
la|r|mahas joined
jonaswGe0rG, I think MUCs won’t route error messages back. sending back error presences is the right thing.
Ge0rGExcept that some funny MUC implementation will also kick all my MSNs
Ge0rGor is that NMSs?
jonaswsure, but that are broken MUC implementations then
jonaswnot sending unavailable presence would be desastrous
Ge0rGjonasw: it's okay to send presence-unavailable to my own nickname, but to all the participants?
jonaswoh!
Ge0rGor rather, presence-error.
Guushas left
jonaswto the participants doesn’t seem right to me
dwdGe0rG, I'm not sure I understand what the problem you're describing is.
Ge0rGit's right from the 0198 session destruction context, though.
HolgerWhat's the downside with just dropping all presence stanzas on 0198 timeout?
HolgerHow does the error stanza help anyone?
MattJIf you send presence to someone, do you expect an error if they don't ever receive it?
dwdGe0rG, So you have an existing local session connected to a local MUC, in a 198-detached state, and then this times out?
HolgerMattJ: I don't.
HolgerMattJ: Because how would I handle that error?
dwdHolger, Giant modal dialog box of course.
HolgerHehe.
dwdHolger, I'm surprised you had to ask.
Ge0rGdwd: I'll try again:
1. I send a join presence to a MUC
2. I disappear into the void
3. The MUC sends everything that's sent on join to my 0198 cache
4. my 0198 session gets destroyed, so my server sends an error response for each individual stanza in the cache, including all the participant presences.
dwdGe0rG, Ah, OK. And what's wrong with that?
Ge0rGdwd: the flood of presence errors to MUC participants.
dwdGe0rG, Ah, OK. And what's wrong with *that*?
Ge0rGdwd: that was the point of my question. Is it wrong or just ugly.
HolgerBeing useless?
dwdHolger, Useless is OK, or at least it's nothing bad, surely?
HolgerIt's nothing bad.
jonaswI’m not sure
jonaswsending presences to other MUC participants is at least weird
dwdGe0rG, I think it's right. Although I don't think the MUC should be broadcasting presence errors - it should juts error you out fo the MUC and broadcast that.
jonaswbecause that’s normally how you join/change nicknames
Valerianhas joined
Ge0rGdwd: I don't know what the MUC does with the flood, to be honest
Valerianhas left
dwdGe0rG, If it just absorbs it, that's fine. I think.
Ge0rGdwd: sounds reasonable to me.
dwdGe0rG, The problem is that to stop it, we'd need to track not just the stanzas, but the semantics of those stanzas.
dwdAnd that's really the MUC entity's job, I think.
jonaswshouldn’t all MUC presences have an <x/> in them which makes it easy to find?
dwd(At least, wherever possible)
HolgerNah.
Ge0rGjonasw: and <x/> specific code in 0198 as well, now?
jonaswGe0rG, *shrug*
HolgerMy question was: My not just silently drop *all* presence stanzas on 0198 timeout?
Ge0rGLet's fix 0045 first.
HolgerNo matter whether MUC-related or not?
goffihas left
goffihas joined
HolgerIs there a single use case where the originator of the presence would handle the error message in any other way than ignoring it?
dwdHolger, I don't think that's needed, or desirable. If an error would be generated immediately on session close, then it should be generated on 198-closure.
HolgerIt would not be generated without 0198, no?
jonaswdoes one get presence-errors when sending a presence to an unavailable entity?
HolgerThis is a 0198 (mis)feature.
HolgerNo.
dwdjonasw, Ah, that's a "sort of". You get a presence error if your sending the presence causes an error to be detected.
dwdSpeaking of 198, what are people setting the timeout to these days?
jonaswI have it set at 5 or 10 minutes I think
jonaswI have it set at 10 minutes.
dwdjonasw, Any statistics on hit/miss of resume attempts?
Ge0rGOn my personal server I set it to 2h, because when on bad mobile my data connection might get interrupted for so long due to a phone call
jonaswdwd, I don’t think I have logs with enough detail, also my userbase is approximately 10.
SamWhitedGe0rG: Is that a CDMA thing that your data gets cut off when you're on a call?
Ge0rGSamWhited: no, it's a 2G/LTE thing.
HolgerWhen I looked some years ago, my impression was that most resumptions happen within 5 minutes. Which seems to be a common default.
dwdthinks hit/miss statis would be amazingly interesting.
Ge0rGSamWhited: 3G can route voice and data at the same time, the others can't
HolgerI.e. increasing the timeout significantly won't increase the resumption rate significantly.
Alexhas left
Ge0rGdwd: there might be false negatives due to client restarts (e.g. OOM conditions)
SamWhitedGe0rG: I'm reasonably sure LTE can, no? Maybe my phone is using both or something to get around that restriction. I should look into this.
dwdGe0rG, That wouldn't give a resume attempt, no?
Ge0rGSamWhited: only if you have VoLTE
Ge0rGSamWhited: otherwise, your phone will fall back to 3G or 2G, whatever's there.
SamWhitedOh! Right, forgot that was a thing.
dwdGe0rG, I mean, it would give a resource conflict and killing the original detached session.
Ge0rGdwd: right
jonasw(for now).
Ge0rGuntil people start using random resource IDs.
dwdhas a 198 resumption patch for Openfire, but it's not timing out yet - like, at all.
SamWhitedOr rather, I forgot CSFB was a thing. Ge0rG: You're in the U.S. no? Do some providers not support SVLTE or VoLTE?
Ge0rGSamWhited: I'm in Germany. VoLTE support is rather spotty here, and you need a manually selected "compatible" phone.
Holgerdwd: That's how Cisco Jabber did it initially.
SamWhitedGe0rG: Good to know; thanks. I wrote about this stuff a bit in the mobile considerations XEP, but obviously don't actually know what I'm talking about
Ge0rGunbounded 0198 sessions guarantee awesome UX
dwdGe0rG, But quite high memory usage, I suspect.
Holger(And when the client didn't resume for some reason and tried to open a new session with the same resource, the new session was rejected.)
Ge0rGdwd: memory consumption is something usually not seen by your users. An "online" buddy that doesn't react for days, and where all the messages vanish, does.
Ge0rGHolger: yeah, that's awesome!
SamWhitedDepends who your users are.
jonaswI wonder whether unbounded sessions are indeed possible with some tricks
SamWhitedIf you make an appliance that someone else runs, your users notice high memory usage.
Ge0rGjonasw: possible - maybe. practical - nope.
jonaswlike: instead of storing messages in some memroy buffer, refer to MAM. apply CSI rules to drop messages.
jonaswpresence is trickier, IQs too
dwdjonasw, The problem is what other users see.
jonaswdwd, is it? is presence even a relevant thing anyomre?
dwdjonasw, Although we could do some magic there, even, by triggering unavailable presence but leaving the session open. MUC dies, of course, but MIX would stay live.
dwdjonasw, Yeah, it's relevant. Conversations notwithstanding, there's lots of IM applications where presence is as vital as it always used to be.
jonaswdwd, while I have you here: a friendly reminder that there are still missing votes from you on the last council meeting :)
dwdjonasw, Oh, yeah. Weird bug hit me, so I was in the room but not seeing anything. I need to track that one down.
Ge0rGdwd: maybe you weren't in the room at all then?
Ge0rG0045 has a nice set of desync issues.
ralphmhas left
Guushas left
Ge0rGhas left
Guushas left
blablahas joined
lumihas left
stefandxmhas joined
Guushas left
Alexhas joined
tim@boese-ban.dehas joined
Flowhas joined
tuxhas joined
danielhas left
jjrhhas left
jjrhhas joined
lskdjfhas joined
jerehas joined
jubalhhas left
mimi89999has left
MattJhas left
waqashas left
mimi89999has left
MattJhas joined
jerehas joined
lumihas joined
MattJhas left
MattJhas joined
waqashas joined
blablahas joined
goffihas left
dwdGe0rG, Oh, I was. Got the presence, too. Just not the messages. I've half a feeling I've cocked something up somewhere. I've literally no idea what build I've been running.
Guushas left
jubalhhas joined
Ge0rGhas left
mimi89999has joined
Guushas left
blablahas joined
Guushas left
jubalhhas left
Guushas left
jjrhhas left
jjrhhas joined
jjrhhas left
jjrhhas joined
Guushas left
jjrhhas left
jjrhhas joined
Ge0rGhas left
danielhas left
danielhas joined
jjrhhas left
jjrhhas joined
jerehas left
jerehas joined
danielhas left
mimi89999has left
Guushas left
danielhas joined
ralphmhas left
mimi89999has left
Guushas left
SamWhitedBrand new web client, first field I tried was an XSS and naturally I can't find a security contact.
jonaswSamWhited, excellent!
SamWhitedI give up. I should just go blackhat, it would be way easier.
waqasSamWhited: But it's shiny!
waqasHonestly, I've given up reviewing JS/HTML XMPP clients, and will fail to trust any unless I write one myself
waqasI suppose that's not limited to XMPP clients...
emxphas joined
SamWhitedFor the sake of my sanity I should do the same.
waqasAnd the shinier and fancier they are, typically the worse the lack of even slight thought put into security hardening
jonaswwaqas, that’s my impression, too
jonaswand I haven’t even tried to pentest anything :)
SamWhitedOn the plus side, 3 seconds (if that) from login to XSS might be a new record. I am not happy about this, record, but I guess it's nice to have a new personal record?
waqasSamWhited: I admit, I haven't broken one in 3 seconds yet :)
jonaswSamWhited, is it free or open source software? post to oss-security ;-)
jonaswSamWhited, congrats, too
SamWhitedwaqas: I literally logged in, pasted a stupid simple XSS into the first field I saw, and sure enough it worked.
jonaswhow can you even have such things if you do XML
jonaswthat sounds as if you could also paste raw XML into the XML stream
waqasjonasw: Interpret it as HTML, obviously
SamWhitedjonasw: Probably. In this case that's not what was happening (it was a roster group name being decoded and inserted into the DOM as HTML)
waqasSamWhited: I'd bet it's string concat. blah.innerHTML += "<div>" + text + "<div>";
jonaswSamWhited, sure, but ... but ... I can’t even. so they used innerHTML?!
jonaswthe world is bad
Wiktorhas joined
danielhas left
mimi89999has left
Guushas left
Valerianhas joined
tim@boese-ban.dehas joined
Guushas left
Ge0rGSamWhited: but roster groups are only visible to yourself!1!
moparisthebesthas left
moparisthebesthas joined
SamWhitedhas joined
Valerianhas left
stefandxmhas left
jjrhhas left
jjrhhas joined
blablahas joined
jubalhhas joined
jubalhhas left
jjrhhas left
jjrhhas joined
Guushas left
emxphas joined
Guushas left
valohas joined
valohas joined
danielhas joined
Guushas left
Alexhas left
Alexhas joined
Guushas left
sonnyhas joined
sonnyhas joined
Guushas left
moparisthebesthas joined
moparisthebesthas joined
Guushas left
jubalhhas joined
sonnyhas joined
tim@boese-ban.dehas joined
Guushas left
Ge0rGhas left
Guushas left
stefandxmhas joined
tuxhas joined
jubalhhas left
SamWhitedGe0rG: Yah, that particular one might not be the worst attack vector since they'd have to have access to your client anyways I guess. Either way, it probably means there are others.
Alexhas left
Ge0rGYeah. That's probably true. Sad, but true.
SouLhas left
Guushas left
stefandxmhas left
stefandxmhas joined
Guushas left
tim@boese-ban.dehas joined
valohas joined
lovetoxhas left
jerehas left
jerehas joined
waqashas left
waqashas joined
jabberatdemohas joined
Alexhas joined
blablahas joined
jabberatdemohas left
goffihas joined
valohas joined
waqashas left
zinidhas left
jonaswisn’t there a way to share roster items? ;-)