jdev - 2020-03-07


  1. Жокир has left

  2. Жокир has joined

  3. strar has left

  4. strar has joined

  5. debacle has left

  6. paul has left

  7. Жокир has left

  8. Жокир has joined

  9. Жокир has left

  10. Жокир has joined

  11. larma has left

  12. larma has joined

  13. Жокир has left

  14. Жокир has joined

  15. gav has left

  16. Жокир has left

  17. Жокир has joined

  18. lovetox has joined

  19. Жокир has left

  20. Жокир has joined

  21. lovetox has left

  22. DebXWoody has joined

  23. Жокир has left

  24. Жокир has joined

  25. Sam Whited has joined

  26. lovetox has joined

  27. DebXWoody has left

  28. DebXWoody has joined

  29. DebXWoody has left

  30. paul has joined

  31. Syndace has left

  32. Syndace has joined

  33. DebXWoody has joined

  34. Жокир has left

  35. Жокир has joined

  36. Jeybe has joined

  37. Жокир has left

  38. Жокир has joined

  39. Bartek has joined

  40. Bartek has left

  41. asterix has joined

  42. Жокир has left

  43. Жокир has joined

  44. asterix has left

  45. asterix has joined

  46. Alex has left

  47. Alex has joined

  48. asterix has left

  49. asterix has joined

  50. pulkomandy has left

  51. Жокир has left

  52. Жокир has joined

  53. pulkomandy has joined

  54. Жокир has left

  55. Жокир has joined

  56. pulkomandy has left

  57. paul has left

  58. paul has joined

  59. pulkomandy has joined

  60. Martin has left

  61. Martin has joined

  62. paul has left

  63. paul has joined

  64. Жокир has left

  65. Жокир has joined

  66. asterix has left

  67. asterix has joined

  68. Martin has left

  69. Martin has joined

  70. Жокир has left

  71. Жокир has joined

  72. pulkomandy has left

  73. pulkomandy has joined

  74. asterix has left

  75. asterix has joined

  76. paul has left

  77. paul has joined

  78. Jeybe has left

  79. Jeybe has joined

  80. asterix has left

  81. asterix has joined

  82. asterix has left

  83. Жокир has left

  84. Жокир has joined

  85. debacle has joined

  86. Жокир has left

  87. Жокир has joined

  88. asterix has joined

  89. Jeybe has left

  90. pulkomandy has left

  91. pulkomandy has joined

  92. pulkomandy has left

  93. Жокир has left

  94. Жокир has joined

  95. pulkomandy has joined

  96. Jeybe has joined

  97. pulkomandy has left

  98. lovetox has left

  99. Marc has left

  100. Marc has joined

  101. Martin has left

  102. Martin has joined

  103. pulkomandy has joined

  104. asterix has left

  105. asterix has joined

  106. pulkomandy has left

  107. Jeybe has left

  108. pulkomandy has joined

  109. asterix has left

  110. asterix has joined

  111. asterix has left

  112. asterix has joined

  113. asterix has left

  114. asterix has joined

  115. pulkomandy has left

  116. pulkomandy has joined

  117. lovetox has joined

  118. asterix has left

  119. asterix has joined

  120. pulkomandy has left

  121. pulkomandy has joined

  122. jeybe has joined

  123. asterix has left

  124. asterix has joined

  125. asterix has left

  126. asterix has joined

  127. asterix has left

  128. asterix has joined

  129. jeybe has left

  130. Jeybe has joined

  131. Жокир has left

  132. Жокир has joined

  133. pulkomandy has left

  134. Жокир has left

  135. Жокир has joined

  136. lovetox has left

  137. Жокир has left

  138. Жокир has joined

  139. Жокир has left

  140. Жокир has joined

  141. pulkomandy has joined

  142. Жокир has left

  143. Жокир has joined

  144. lovetox has joined

  145. pulkomandy has left

  146. asterix has left

  147. pulkomandy has joined

  148. asterix has joined

  149. lovetox has left

  150. asterix has left

  151. asterix has joined

  152. sonny has left

  153. Marc has left

  154. Marc has joined

  155. Jeybe has left

  156. lovetox has joined

  157. lovetox

    if i end a stream correctly, does the server send unavailable presences out?

  158. lovetox

    or do i have to do this myself befor i end the stream

  159. Zash

    Server sends unavailable when the session ends, if it's still available at that point.

  160. Жокир has left

  161. Жокир has joined

  162. lovetox

    hm not sure this answers my question

  163. pep.

    "yes, if the server is not down"?

  164. lovetox

    i send </stream> and end my stream

  165. Zash

    lovetox: the answer is yes

  166. lovetox

    ok thanks :)

  167. Zash

    the server will send unavailable if you don't

  168. lovetox

    ok and its not considered bad by the client to not send it themself

  169. Kev

    I'd consider it daft to do so.

  170. Jeybe has joined

  171. lovetox

    Kev, its daft to send presence themself as client?

  172. lovetox

    or not?

  173. Kev

    Yeah. The server's going to do it for you, so I think it's daft for a client to maintain code to duplicate that.

  174. lovetox

    great, i thought so too :)

  175. pulkomandy has left

  176. Zash

    In theory you can set a status message while you're offline, but I don't think the server is required to keep that.

  177. Zash

    Probably made more sense before always-on mobile clients

  178. pep.

    "always-on"

  179. asterix

    Except if you want to set a good bye status message.

  180. lovetox

    hm yeah true we actually have a good bye message feautre

  181. lovetox

    and im pretty sure servers keep that

  182. Zash

    I'm reminded of the disussions around having status messages in PEP instead of presence

  183. lovetox

    i see that all the time if people leave a muc

  184. lovetox

    and going offline

  185. pep.

    Zash: a "bye message" in PEP?

  186. lovetox

    and of course they have to keep it

  187. lovetox

    its a presence i send, the server does not know that im going to go offline in a sec

  188. Zash

    lovetox: no, they just have to broadcast it

  189. lovetox

    i thought thats what keeping it means

  190. lovetox

    or do you send a second unavailable presence after i send mine and end the stream

  191. lovetox

    i think not

  192. Zash

    Prosody does not keep unavailable presence around after broadcasting them

  193. lovetox

    why would i need the server to store the message?

  194. Zash

    and after that there's no point of generating unavailable on disconect

  195. lovetox

    i told everyone that is online that im going offline

  196. Zash

    I'm not sure I follow what you're saying

  197. Sam Whited

    What if I'm offline when you send that message, you go offline, then I come online? I might also want your status message (which is why it should be in PEP in my opinion).

  198. lovetox

    yeah thats not possible

  199. Kev

    Sam Whited: I have a TODO from the Summit to write presence-over-PEP, BTW.

  200. lovetox

    but thats not a reason to not tell the people who are online and are able to receive it, to not tell them

  201. Zash

    I believe there's a hint in one of the RFCs that the server could keep the last unavailable presence of the last resource and send in response to probes later, but I'm pretty sure it's optional and at least Prosody doesn't do this.

  202. Sam Whited

    Kev: oh that's interesting, I was just thinking about specifics like a status messages being a new thing in PEP, not presence in general and all the other information it conveys. I'll be curious to see that

  203. Kev

    Sam Whited: I mean status/show, really.

  204. Kev

    So <presence/> becomes device information, and PEP becomes user information.

  205. Zash

    https://xmpp.org/rfcs/rfc6121.html#presence-probe-inbound

  206. Zash

    point 3 there has the text I was thinking of

  207. Zash

    PEP is better tho

  208. lovetox

    its just much much more traffic for nearly no gain

  209. lovetox

    previously it was 100 presences on coming online, then its doubled because everybody puts status and show in pep

  210. lovetox

    also its probably fine to have a account wide status

  211. lovetox

    but show?

  212. lovetox

    if i come online i get the last pep info, show = online

  213. lovetox

    but no presence means offline

  214. lovetox

    also there is an information loss, if i see a work pc as away, but the smartphone as online

  215. lovetox

    i can assume a person is not at his workplace right now

  216. Sam Whited

    I'd be okay with that; personally I prefer to treat status as an account thing. You can either reply to messages or not and I shouldn't have to think about what clients are busy and online and away.

  217. Sam Whited

    With carbons and MAM it becomes way less important to have each individual device have more granular status than online and offline.

  218. Kev

    lovetox: I don't think you can assume that at all.

  219. Kev

    I frequently have my phone with me when I'm in the office, but have stepped away from my desk.

  220. lovetox

    thats what i meant with not at your workplace

  221. lovetox

    the desk

  222. Sam Whited

    lovetox: but why would it be marked as away? I suspect most people don't change their status every time they step away from their desk for a few minutes, and they still have their phone on them so it's not like they're going to miss your message if you send them one?

  223. lovetox

    Point is, right now we have the possibility to maintain a show value per client, this is a feature, for some people this is useless, others find it veryuseful, it depends on the circumstances

  224. lovetox

    you want to take this away, and i simply ask, what for, what is the gain we have from that?

  225. lovetox

    Sam Whited, auto away is a thing

  226. Sam Whited

    A much simpler system for users.

  227. lovetox

    If you want to make it simple for YOUR users, nobody forces you to display the show value from each device

  228. Sam Whited

    Who finds it very useful? Are people still sending messages to individual clients?

  229. lovetox

    Sam Whited, its about the information, not about sending messages

  230. lovetox

    A device is autoaway for 20 minutes

  231. lovetox

    thats a device status, and a device show

  232. Sam Whited

    lovetox: I don't understand what people are doing with this information then.

  233. lovetox

    this information is useufl

  234. Sam Whited

    It seems like an anti-feature to me.

  235. jonas’

    it becomes useful once you have to deal with device-to-device communication

  236. lovetox

    you dont have to, point is xmpp offers that information

  237. jonas’

    like jingle file transfers and calls

  238. lovetox

    if you dont want to show it to your users, dont

  239. lovetox

    you dont need a show in pep, to reduce to presence shows to one

  240. lovetox

    you dont need a show in pep, to reduce two presence shows to one

  241. jonas’

    having an account-wide show is also a useful thing though

  242. Sam Whited

    lovetox: it's not just about showing it, it's about setting it. I already do only show one to my users

  243. jonas’

    having a user-controlled account-wide show is also a useful thing though

  244. lovetox

    like all other clients

  245. lovetox

    so i dont see any gain for the user here

  246. Sam Whited

    IMO anything that involves individual clients we should be fixing or getting rid of; eg. Jingle too. If someone sends me a file I should pick what device to receive it on, not them.

  247. lovetox

    now its one, afterwards its one

  248. pulkomandy has joined

  249. serge90 has left

  250. lovetox

    i see XMPP can deal with multiple devices as a feature

  251. lovetox

    yes its tricky sometimes

  252. lovetox

    yes its not easy for devs to make this easy for users

  253. lovetox

    but its nevertheless a big feautre, that other messengers like whatsapp never had for years

  254. lovetox

    and still to this day its not even near XMPP

  255. lovetox

    i think todays users can be trusted to get the gist of a system with multiple devices

  256. lovetox

    we dont have to treat them as super dumb

  257. jonas’

    I’m not sure that’s true

  258. Sam Whited

    I still really don't see the use case, "having more features than WhatsApp" isn't a usecase, and may not even be a good thing.

  259. Kev

    I'm not sure providing features that make sense is about user being stupid.

  260. lovetox

    im now a few years in very near contact with users of Gajim, and never had even one asked what it means that there are 2 devices listed with different show

  261. lovetox

    and status

  262. lovetox

    Kev what is the feature you are talking about

  263. lovetox

    as we already said, all clients show ONE show value already

  264. lovetox

    moving this into pep, and afterwards showing ONE show value

  265. lovetox

    makes 0 difference for any user

  266. Kev

    Allowing a user to set a status message applicable for themselves, rather than a device.

  267. lovetox

    we talk since 10 minutes about show

  268. lovetox

    not status

  269. lovetox

    but yes i agree, account wide status can be useful

  270. Kev

    And to be able to say that they're "Do Not Disturb" and not have that change because a client that had disconnected suddenly gets a connection again.

  271. Sam Whited

    I probably confused that, I always call that status but I meant online/away/busy not the status message

  272. Sam Whited

    And if you're just asking your users who already use XMPP that's a very self-selecting sample set. We're trying to make the network make sense and be easier for everyone, not just existing XMPP users.

  273. pulkomandy has left

  274. lovetox

    you make it easier in one department, and loss stuff in the other

  275. Sam Whited

    What are we losing? I still don't see any use case for per-device show values. The Jingle one makes sense, but we need to fix jingle not keep this weird state where show is per-device.

  276. lovetox

    obviously the show from each device, if you only have one

  277. jonas’

    > If someone sends me a file I should pick what device to receive it on, not them. how are you going to do that if you’re AFK?

  278. Sam Whited

    Again: what is the use case? I understand *technically* what information is being lost, I don't understand why we care about that information.

  279. lovetox

    but lets leave this for now, i see you dont find it useful so it has to go

  280. jonas’

    will the transfer be stuck until you "accept the call" on one device?

  281. lovetox

    what about the PEP spam?

  282. jonas’

    will you configure a default preference?

  283. lovetox

    how much more info you want to put in different PEP nodes?

  284. Sam Whited

    jonas’: I dunno, we can figure that out later. Completely different discussion

  285. jonas’

    Sam Whited, I find this not completely different, but ok

  286. lovetox

    when i come online, how many MB data do i have to download from the server, just so im up to date with everyone

  287. lovetox

    ?

  288. jonas’

    lovetox, good question!

  289. lovetox

    Put it into PEP, is not a scaleable solution

  290. lovetox

    and we/you should think rather sooner about how to solve this

  291. jonas’

    it’d be more scalable if PEP updates from a single contact were aggregated in a single stanza

  292. Sam Whited

    Oh, is the argument changing to scalability now? The goalposts appear to be moving.

  293. lovetox

    Sam Whited, why is a goalpost moving, if i have multiple points why this is bad?

  294. asterix has left

  295. pulkomandy has joined

  296. lovetox

    i respect that you dont share my opinion about show per device is useful

  297. Sam Whited

    The points are changing without actual answers to the previous questions. I agree, we should talk about scalability too though, but I'm less concerned about the technical side of things, we can solve that when we write the XEP.

  298. Kev

    lovetox: The proposal isn't that per-device presence payloads become illegal. Just that they're not used if what you're trying to convey is the status of the user rather than a device.

  299. lovetox

    you cant solve pep scalability by writing another UserStatus xep

  300. Sam Whited

    lovetox: do we know that it's not scalable before we write the XEP? How do we know it doesn't save us a lot of stanzas?

  301. Sam Whited

    For example, let's say we have a system like the original we were describing where status messages work even if the user is offline. If we did that in the current presence based system, every time the user is online they have to do a presence probe for all of their offline contacts. In PEP they just get that pushed down only for contacts that have actually pushed a presence. That probably saves a lot of round trips.

  302. Jeybe has left

  303. lovetox

    You compare something, nobody actually does, and nobody will ever do (probing offline users) against your PEP proposal

  304. lovetox

    but yeah that would save roundtrips

  305. Kev

    Offline users do get probed when you come online, all your contacts do.

  306. Kev

    That's how you find out that they're offline (or not)

  307. Sam Whited

    Sure, the point is that there are ways it could save us stanzas and we won't know until we figure out how it's used and write the XEPs.

  308. Sam Whited

    Let's take the show example (I'm not suggesting this is how we should do it, I'm just saying that your assumption that it's more traffic isn't necessarily true): if we move show into PEP we could imagine a system where after we come online we get a single presence for only online devices like we get today. That contains the accout status value then *after* that we start getting updates from PEP. Now we have the niceties of device/account information being separated, but still get the same number of stanzas on login

  309. Sam Whited

    Or we could get show from PEP on login and not get presences at all, then probe accounts for devices only if/when we need them lazily. This would likely drastically reduce the amount of traffic on login (I think? Maybe we always need caps right away so this wouldn't work). Again, not suggesting we should do these things, just that "it will increase traffic" isn't something we know yet.

  310. pulkomandy has left

  311. lovetox

    Sam Whited, really you are talking about changing stuff in the whole eco system

  312. lovetox

    we just talked about putting show into PEP

  313. lovetox

    and yes this would double traffic, given all ccontact use this

  314. Sam Whited

    Yes, these are the things putting show in PEP eventually could allow us to do. I'm not suggesting we do them right away or that they're even possible necessarily, just that they're good examples of why "it will increase traffic" isn't a good argument.

  315. Sam Whited

    It might double traffic, or it might make it lesser overall once we start moving more things into PEP.

  316. lovetox

    are we talking about the same thing? you know how PEP works or?

  317. Sam Whited

    We won't know until we think about it a lot more, write the XEP, maybe start getting implementation experience.

  318. lovetox

    PEP says, on +notify, it pushes the last node of every contact, for every node you subscribe to

  319. lovetox

    so yes this is not scaleable

  320. lovetox

    unless you fundementally change PEP / Pubsub, putting more stuff in PEP will increase traffic

  321. Sam Whited

    Maybe "account info" is a node that contains lots of things in one big payload that previously would have been sent by many different presence/message/IQs.

  322. Sam Whited

    Maybe offline nodes are removed and the deletion signals offline (unless we have a feature where we keep a status message around or something). Now we stop getting updates from those and it's basically the same as presence was. There are all kinds of ways this could reduce the amount of traffic sent.

  323. lovetox

    yeah thats thinking about scaleability

  324. pulkomandy has joined

  325. debacle has left

  326. lovetox

    and that what we should do before adding more things into PEP

  327. Sam Whited

    Right, which is why I think we can't just say "it will double traffic" without an XEP and possibly implementation experience.

  328. Sam Whited

    I dunno, maybe it's not enough traffic to matter what happens before moving more things to PEP. Or maybe it is. The point is we don't know right now.

  329. lovetox

    i know, Gajim implements every UserPEP Xep there is

  330. lovetox

    and believe me even on accounts with 20 users, this means endless stanzas

  331. Sam Whited

    You're wanting me to argue that it absolutely will reduce traffic, and I'm not arguing that. I'm just arguing that your assertion that it will double traffic may or may not be true and it's not a good argument for why we shouldn't bother to move show/status into PEP.

  332. lovetox

    my assertion was it will double traffic, if you copy UserPEP XEP XY and do the same with status and show

  333. lovetox

    and that was definitly on the mind of everybody when this discussion started

  334. Sam Whited

    Why are you thinking that's what would happen when you haven't read Kevs theoretical XEP?

  335. lovetox

    now we moved the goalpost to, oh yeah that XEP would have to keep scalability in mind

  336. lovetox

    and im fine with that :)

  337. lovetox

    Kev can share it and prove me wrong, im happy if we have good solutions for problems

  338. Sam Whited

    Anyways, I shouldn't have let myself be drawn into pivoting this into a technical discussion. We're not there yet. My argument is that we need to think about use cases and users, and I don't see one for how the existing system works.

  339. lovetox

    also MUC incompatibility with PEP is a problem since a longer time, dont know if we have the same problem with MIX

  340. Sam Whited

    I sometimes think that we need to treat the public network as a service when we're writing XEPs. Maybe we need a Jabber product manager (or product mangaer committee) who puts together a cohesive vision for what the Jabber Service should look like in the future, and then decides if XEPs guide us towards or away from that.

  341. Sam Whited

    Yah, MUC would definitely have to be thought about, that's always tricky. Still though, that's all a ways out and isn't an argument for why we shouldn't write the XEP. It's definitely worth thinking about while writing it.

  342. Sam Whited

    Anyways, I need to step out now and get ready to leave. Please think about use cases. I'd really like to know if there actually is one for the current system.

  343. sonny has joined

  344. pulkomandy has left

  345. DebXWoody has left

  346. DebXWoody has joined

  347. Jeybe has joined

  348. pulkomandy has joined

  349. pulkomandy has left

  350. pulkomandy has joined

  351. Jeybe has left

  352. debacle has joined

  353. serge90 has joined

  354. Martin has left

  355. asterix has joined

  356. Martin has joined

  357. Marc has left

  358. pulkomandy has left

  359. pulkomandy has joined

  360. Marc has joined

  361. raucao has left

  362. pulkomandy has left

  363. pulkomandy has joined

  364. pulkomandy has left

  365. pulkomandy has joined

  366. asterix has left

  367. asterix has joined

  368. Жокир has left

  369. Жокир has joined

  370. moparisthebest has left

  371. lovetox

    is it possible from the outside to see that a websocket connection is a xmpp connection?

  372. Zash

    Based on looking at the TLS connection? Probably not easily.

  373. lovetox

    as i understand websocket, first a normal HTTPS connection is made

  374. Zash

    Timeing information might leak that it's not following the common request-response pattern of HTTP

  375. lovetox

    then within that the protocol is upgraded to websocket

  376. Zash

    Yeah

  377. lovetox

    ok so if i want to conceil the fact that its an xmpp connection, this is probably a safer bet than xep0368

  378. lovetox

    we announce a protocol xmpp-client with 0368

  379. lovetox

    is this transfered in plaintext, within the tls negotiation

  380. lovetox

    or afterwards is the question

  381. Zash

    ALPN is sent in plain text in the beginning of the TLS handshake

  382. lovetox

    yep so trivial to see that its an xmpp connection

  383. goffi has joined

  384. DebXWoody has left

  385. DebXWoody has joined

  386. moparisthebest has joined

  387. asterix has left

  388. asterix has joined

  389. moparisthebest

    Unless you don't send it, it's not mandatory, if you need to conceal this you should not send it

  390. moparisthebest

    Same with SNI

  391. Zash

    Can't get around the certificate being returned in the clear tho.

  392. moparisthebest

    Though encrypted SNI is almost here, I expect encrypted alpn to follow shortly

  393. moparisthebest

    Zash: iirc that's fixed already in TLS 1.3 ?

  394. Zash

    Dunno

  395. lovetox

    hm if i dont send the protocol than a webserver also running on 443 will not know that i want to talk to the xmpp server or?

  396. lovetox

    i think i ran into that problem early in my implementation

  397. moparisthebest

    > The difference is that in TLS 1.3, a lot less is in the clear. For example, in TLS version 1.2 you were able to witness the disclosure of the Subject Alternative Name (SAN) in the Certificate but in 1.3, this is encrypted and not made available for inspection by any intermediate system.

  398. moparisthebest

    From our favorite company https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back

  399. moparisthebest

    lovetox: depends on how the server is set up, maybe, maybe not, that's why it's important you keep trying all the SRV records

  400. moparisthebest

    Unless you must not be detected of course, in which case you abort

  401. lovetox

    hm problem is when connection succeeds i will not try others

  402. lovetox

    maybe i should wait for the first <stream> to make that decision

  403. moparisthebest

    Yep absolutely

  404. moparisthebest

    Also if TLS verification fails you should keep trying

  405. lovetox

    eh actually im in the camp to not shadow a badley setup server with various workarounds

  406. moparisthebest

    I haven't had problems with gajim, but dino won't connect to my server unless I patch out their xep 368 module because of that error

  407. moparisthebest

    You aren't, you are allowing easy DOS

  408. lovetox

    if a cert verify fails, why would it not fail on a other connection method?

  409. lovetox

    can you give me the address of your xmpp server so i can try if it works in my new code?

  410. moparisthebest

    Any mitm can accept a TCP connection

  411. moparisthebest

    lovetox: mitm ?

  412. lovetox

    a mitm that only mitm on one connection method?

  413. moparisthebest

    burtrum.org , feel free to poke, so if you don't send alpn over ipv4 you'll end up taking to nginx

  414. moparisthebest

    lovetox: absolutely? Plenty of ways, v4 vs v6, servers in different datacenters

  415. moparisthebest

    Maybe captive wifi is only set to mitm 443 not 5223

  416. moparisthebest

    Basically your code should never stop trying based on anything an attacker could cause

  417. lovetox

    but this is too complex

  418. lovetox

    cert on my server is expired

  419. lovetox

    i dont care, gajim shows me the error, i tell it to connect anyway

  420. lovetox

    trying everything first and remembering the first cert fail, then if everything fails coming back to that and offer the user to connect anyway

  421. lovetox

    really dont want to implement that

  422. lovetox

    also if you assume every cert fail is an attacker

  423. lovetox

    then you simply cant connect to a server anymore that has no valid cert

  424. lovetox

    which is also a choice i want to give to the user

  425. lovetox

    i can connect fine to your server btw

  426. lovetox

    also i dont see it as my responsibility to make Gajim into a tool that can withstand a DOS

  427. lovetox

    attack

  428. pep.

    lovetox: if you remember the cert you might allow the user for some more time.. I always find this weird tbh, this expiry thing. Tge cert expired but you're still connected so you don't care, even if it's been a week already, and when you reconnect you (the client) is like "omg the world is burning"

  429. asterix has left

  430. asterix has joined

  431. lovetox

    yeah i also fail to see how a expired cert is suddenly insecure

  432. lovetox

    if its expired for 2 years

  433. lovetox

    ok an attacker had plenty of time to attack that cert

  434. lovetox

    but a week? ..

  435. pep.

    I guess it mostly shows how much the admin is active :p

  436. pep.

    or how skilled in cron they are!

  437. pulkomandy has left

  438. pulkomandy has joined

  439. asterix has left

  440. asterix has joined

  441. moparisthebest

    Right but I want gajim to connect from sleazy free WiFi if possible, not give up on first mitm or blocked port

  442. moparisthebest

    That entirely defeats the purpose of srv

  443. pulkomandy has left

  444. pulkomandy has joined

  445. Zash

    I don't think SRV was invented as a way to avoid MITM or blocks

  446. kikuchiyo has left

  447. kikuchiyo has joined

  448. DebXWoody has left

  449. kikuchiyo has left

  450. lovetox

    wait, blocked port is different story

  451. lovetox

    Gajim will try until it has a successful connection with the host and port gathered via SRV

  452. moparisthebest

    A mitm can accept a TCP connection though

  453. moparisthebest

    You shouldn't give up until you have cryptographic proof you can't successfully connect to the server

  454. pulkomandy has left

  455. Zash

    prove a negative?

  456. pulkomandy has joined

  457. moparisthebest

    Like, they provide a proper cert and then reject you with bad password, for instance

  458. moparisthebest

    And srv explicitly was invented to prevent dos, one service is down or unreachable or misconfigured, try the others

  459. Zash

    Where does it say that?

  460. lovetox has left

  461. moparisthebest

    What other purpose could it possibly have? Otherwise just use a well known port like http

  462. lovetox has joined

  463. Zash

    RFC says it's for moving services and designate backup servers. There's one mention of "denial of service", in the context of SRV being used *for* it.

  464. moparisthebest

    Don't need backup servers if nothing can go wrong at your primary

  465. moparisthebest

    If something can go wrong though, why not try the backup

  466. Жокир has left

  467. Жокир has joined

  468. Жокир has left

  469. Жокир has joined

  470. Жокир has left

  471. Жокир has joined

  472. Marc has left

  473. Жокир has left

  474. Жокир has joined

  475. Жокир has left

  476. Жокир has joined

  477. Жокир has left

  478. Жокир has joined

  479. Syndace has left

  480. Syndace has joined

  481. pulkomandy has left

  482. pulkomandy has joined

  483. lovetox has left

  484. pulkomandy has left

  485. pulkomandy has joined

  486. asterix has left

  487. goffi has left

  488. defanor

    FWIW, that's the thing that bothered me about both "happy eyeballs" and looping through SRV records too: there can be scenarios in which a connection is possible, yet a client would fail to connect while following those. But fighting potential DOS via an unknown MITM (or poor connectivity) seems like a rabbit hole: even if you succeed in establishing a TLS connection, a MITM or a poor network could simply start dropping packets after

  489. defanor

    passing a few.

  490. Жокир has left

  491. Жокир has joined

  492. moparisthebest

    That's fine, xmpp works fine over those kind of networks