XMPP Service Operators - 2021-04-30


  1. patasca has joined
  2. patasca has left
  3. patasca has joined
  4. millesimus has left
  5. Geofferey has joined
  6. millesimus has joined
  7. Geofferey has left
  8. patasca has left
  9. patasca has joined
  10. kryptos has left
  11. kryptos has joined
  12. patasca has left
  13. octagon has left
  14. ross has left
  15. ross has joined
  16. octagon has joined
  17. patasca has joined
  18. kousu has joined
  19. Samir Allioui has left
  20. Samir Allioui has joined
  21. patasca has left
  22. patasca has joined
  23. mss_cyclist has joined
  24. alacer has left
  25. alacer has joined
  26. steven has left
  27. patasca has left
  28. Mel has left
  29. patasca has joined
  30. Mel has joined
  31. mss_cyclist has left
  32. patasca has left
  33. mss_cyclist has joined
  34. patasca has joined
  35. Douglas Terabyte has left
  36. iramaro has left
  37. iramaro has joined
  38. Ge0rG has left
  39. Ge0rG has joined
  40. Douglas Terabyte has joined
  41. patasca has left
  42. patasca has joined
  43. Maranda has left
  44. adrian@kiess.onl has left
  45. ross has left
  46. ross has joined
  47. adrian@kiess.onl has joined
  48. patasca has left
  49. patasca has joined
  50. Link Mauve has left
  51. octagon has left
  52. octagon has joined
  53. Ge0rG has left
  54. Ge0rG has joined
  55. Maranda has joined
  56. Licaon_Kter has left
  57. derventio has joined
  58. octagon has left
  59. patasca has left
  60. Steven Roose has left
  61. octagon has joined
  62. shaarad has joined
  63. octagon has left
  64. kryptos has left
  65. octagon has joined
  66. quantumwings has left
  67. mjk has left
  68. mjk has joined
  69. dinosaurdynasty has left
  70. patasca has joined
  71. menel has joined
  72. lorddavidiii has joined
  73. patasca has left
  74. patasca has joined
  75. octagon has left
  76. ernst.on.tour has left
  77. iramaro has left
  78. quantumwings has joined
  79. guus.der.kinderen has left
  80. ernst.on.tour has joined
  81. x187x has left
  82. x187x has joined
  83. patasca has left
  84. dinosaurdynasty has joined
  85. ibikk has joined
  86. patasca has joined
  87. pod has joined
  88. patasca has left
  89. patasca has joined
  90. quantumwings has left
  91. quantumwings has joined
  92. mjk has left
  93. mjk has joined
  94. octagon has joined
  95. sol has left
  96. abidal3 has joined
  97. sol has joined
  98. patasca has left
  99. octagon has left
  100. octagon has joined
  101. DebXWoody has left
  102. DebXWoody has joined
  103. DebXWoody has left
  104. DebXWoody has joined
  105. alberto has joined
  106. Huxx has joined
  107. derventio has left
  108. patasca has joined
  109. raghavgururajan has joined
  110. mjk has left
  111. rom1dep has left
  112. x51 has left
  113. abidal3 has left
  114. menel has left
  115. Wiktor moparisthebest, didn't see SRV in the linked draft so how is the port discovery being done in QUIC?
  116. mjk has joined
  117. jl4 has joined
  118. guus.der.kinderen has joined
  119. jonas’ how is port discovery done in TCP?
  120. jonas’ moparisthebest, are you confuslating QUIC and HTTP/3 there?
  121. Mel has left
  122. patasca has left
  123. patasca has joined
  124. guus.der.kinderen has left
  125. lorddavidiii has left
  126. lorddavidiii has joined
  127. ross has left
  128. Mel has joined
  129. ross has joined
  130. christian nmap?
  131. jayteeuk has left
  132. jayteeuk has joined
  133. jonas’ christian, no offense, but I’d really appreciate it if you could read more than the last two lines of backlog before replying. Thanks! :)
  134. christian jonas’: today are only two.
  135. octagon has left
  136. jonas’ christian, maybe use a client with MUC-MAM support then
  137. marc has joined
  138. jonas’ or check the logs online at https://logs.xmpp.org/operators/ if that’s not an option
  139. jonas’ re-winding the conversation context of the past day is exhasutign
  140. jonas’ re-winding the conversation context of the past day is exhausting
  141. christian jonas’: okay. Sorry for disturbing.
  142. jonas’ christian, thanks!
  143. menel has joined
  144. sonny has left
  145. patasca has left
  146. Licaon_Kter has joined
  147. schäfchen726 has joined
  148. sonny has joined
  149. Douglas Terabyte has left
  150. abidal3 has joined
  151. ernst.on.tour has left
  152. ernst.on.tour has joined
  153. Douglas Terabyte has joined
  154. jl4 has left
  155. jl4 has joined
  156. madmalkav has joined
  157. jl4 has left
  158. jl4 has joined
  159. octagon has joined
  160. jl4 has left
  161. jl4 has joined
  162. jl4 has left
  163. jl4 has joined
  164. menel has left
  165. abidal3 has left
  166. jl4 has left
  167. jl4 has joined
  168. abidal3 has joined
  169. jl4 has left
  170. jl4 has joined
  171. jl4 has left
  172. jl4 has joined
  173. ernst.on.tour has left
  174. ernst.on.tour has joined
  175. p55s has left
  176. Steven Roose has joined
  177. madmalkav has left
  178. madmalkav has joined
  179. nickomemo has joined
  180. menel has joined
  181. kahlb Are there actually ddos attacks using STUN services as a reflector or only the theoretical possibility? I've never seen one an there are way "better" opportunities.
  182. abidal3 has left
  183. Ge0rG kahlb: there are actual attacks
  184. kahlb Are there any resources about it? Analysis? I'm really interested.
  185. christian there are some script kiddies who discovered "ping -f" and some security guys who feel important :)))
  186. jonas’ kahlb, tcpdump -enni any port 3478 ;)
  187. mss_cyclist has left
  188. kahlb jonas’, the theoretical possibility is out of question. But is there a real danger, like booter services actually doing this? I see no reason why they should as long as there are so many highly efficient reflectors out there.
  189. kahlb on my system there is no suspicios traffic. Exploiting a reflectro always requires a scan in advance, so maybe i'm safe. But in ddos traffic from larger attacks I've seen lately I never saw anything stun related
  190. mss_cyclist has joined
  191. tom Is that what these are: » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:57 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974814: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:58 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:59 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:59 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:59 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » Apr 30 00:45:59 web turnserver: 974815: session 001000000000133270: realm <> user <>: incoming packet BINDING processed, success » (END) »
  192. tom It's creating like a gigabyte of logs per day
  193. christian I am no logging at all stun.
  194. creep.im has left
  195. kahlb jonas’, Okay, but that's rather ddosing yourself rather than anybody else. What is the target of the attack?
  196. kahlb s/ddosing/dosing
  197. jonas’ tom, yess, that looks relevant
  198. jonas’ kahlb, we don’t know what the goal is.
  199. jonas’ just that it is happening in practice
  200. tom Is there a way to actually filter this
  201. abidal3 has joined
  202. tom Because i'm not going to do security by obscurity by changing port numbers
  203. tom If there's some way to definitively tell what is attack traffic and what's not
  204. tom Either an nftables rule or some kind of logging+fail2ban I'm all for that and will implement fixes
  205. tom Otherwise I don't really care
  206. tom Who is being ddosed anyways?
  207. kahlb jonas’, the target of a reflector attack is alway the (spoofed) source ip, so you shoud see it in your tcpdump. If it's alway the same, just filter it.
  208. tom Techniclly you can reflection attack someone with TCP RST
  209. tom What am I to do, stop sending TCP resets?
  210. nickomemo has left
  211. jonas’ kahlb, been there it’s not that easy
  212. maxwell has left
  213. creep.im has joined
  214. neox has joined
  215. tom Btw, I'm showing 52.113.61.170 being attacked
  216. abidal3 has left
  217. tom Which is Microsoft Corporation
  218. alien has joined
  219. ralphm Like Azure hosting?
  220. tom I'm not really in a rush to do any favors to a corporation who I spent the last 2/3 decades protesting the war against open standards and protocols
  221. tom *their
  222. jl4 has left
  223. tom Or a corporation who patent trolls
  224. jonas’ ralphm, I don’t know if azure is a separate AS, the whois of that IP only points at MSFT :/
  225. jonas’ I also wish I knew
  226. tom Or is a member of the PRISM mass surveillance program
  227. tom You all remember skype? Or internet explorer
  228. Licaon_Kter tcpdump says continously :( ``` 07:55:21.376197 In MAC ethertype IPv4 (0x0800), length 64: SOMEIP.3479 > MYLANIP.3478: UDP, length 20 07:55:21.377734 Out MAC ethertype IPv4 (0x0800), length 96: MYLANIP.3478 > SOMEIP.3479: UDP, length 52 ``` ...have I got the disease?
  229. tom Or outlook blocking your mail server
  230. jonas’ Licaon_Kter, likely
  231. jonas’ though, that looks more fun
  232. Licaon_Kter tom: saw the same IP too iirc
  233. jl4 has joined
  234. jonas’ because it’s source port 3479
  235. kahlb 52.113.61.170 is MS Azure.
  236. Licaon_Kter Now it's 137.74.0.162
  237. jonas’ kahlb, how do you know?
  238. jonas’ Licaon_Kter, hm, OVH, haven’t seen that yet.
  239. Licaon_Kter Some reverse ip online tools yielded nothing, but one mentined ns1.azure though
  240. ralphm You can download the IP ranges Azure uses
  241. Licaon_Kter Now it stopped...
  242. kahlb 137.74.0.162 is a TS3 Server. Actually a potential target for DDoS
  243. Licaon_Kter .162 used port 9987
  244. jl4 has left
  245. jl4 has joined
  246. Licaon_Kter And...it's back .162:9987
  247. ralphm kahlb: so it may be part of a botnet
  248. Ge0rG I've changed the STUN/TURN port to a random one two weeks ago, and I'm still receiving ingress traffic on 3478
  249. Licaon_Kter 20 in 52 out means >2x
  250. tom Yeah just got that change to
  251. sol has left
  252. tom 137.74.0.162
  253. jl4 has left
  254. jl4 has joined
  255. tom It's weird that the sourceport is always the same
  256. tom 9987
  257. tom They are hitting my server with 9987 as well
  258. jonas’ ralphm, I don’t think that the .162 is the true source
  259. Licaon_Kter Looks like I'll change the port then, daaaammit
  260. jonas’ Licaon_Kter, tcpdump does not count IP headers, you have to add 44 bytes to that IIRC.
  261. tom No it's not that just the attack target
  262. jonas’ Licaon_Kter, tcpdump does not count IP and UDP headers, you have to add 44 bytes to that IIRC.
  263. kahlb Ge0rG, because the attackers only scan once or every few months. They don't get an idea if your IP is still a usable reflector, only if they scan again.
  264. tom This happens because ISPs don't implement BCP38, so you can spoof the ip address of anybody
  265. jonas’ Licaon_Kter, tcpdump does not count IP and UDP headers, you have to add ~44 bytes~ 28 bytes(?)
  266. jonas’ kahlb, we changed ports >2w back.
  267. jonas’ IIRC.
  268. tom redacted.3478 > 137.74.0.162.9987: [bad udp cksum 0x979f -> 0x4ff1!] UDP, length 108
  269. tom Hey
  270. tom Half these packets have bad checksums too
  271. jonas’ tom, that’s not ral
  272. jonas’ tom, that’s not real
  273. tom Whoever the ddoser is they aren't very skilled
  274. rom1dep has joined
  275. jl4 has left
  276. jl4 has joined
  277. kahlb Here is some really good literature for those who want to dig in: https://christian-rossow.de/publications/amplification-ndss2014.pdf
  278. jonas’ that is the packet your server sends, and depending on offloading settings, checksums are not correct (yet) when tcpdump sees tem
  279. tom Bad checksums and using the same source port continuously
  280. jonas’ so you are "sending" a bad checksum in that line, not them
  281. kahlb Rossow has a few more publications about it, all are worth reading.
  282. tom The only problem is, there's a bug in linux's nft where it blocks some needed ipv6 multicast if you enable bogon filtering
  283. tom Oh my bad your right
  284. tom That's my packet
  285. jl4 has left
  286. jl4 has joined
  287. tom Hey it stopped
  288. tom Did it stop for anyone else as well ?
  289. christian Isn't dnssec making the spoofing harder?
  290. jl4 has left
  291. jl4 has joined
  292. kahlb christian, no, dns has nothing to do with this.
  293. jl4 has left
  294. tom The problem is ISPs are too lazy to implement https://tools.ietf.org/html/bcp38 on their core router
  295. tom Which makes ip spoofing impossible
  296. tom Oh, they are back
  297. Licaon_Kter > Did it stop for anyone else as well ? It's on and off Changed ports so it's quiet for now That being said, it means all A/V is now forced through TURN, right?
  298. Licaon_Kter > Did it stop for anyone else as well ? It's on and off Changed ports so it's quiet for now 215 to the rescue
  299. octagon has left
  300. menel has left
  301. mjk has left
  302. tom Here's an idea
  303. tom Log every binding request along with a timestamp and auto-ban ips that do over 120 binding requests /minute
  304. patasca has joined
  305. tom I can't think if a scenario where there would be that many binding requests from the same ip per minute
  306. tom *of
  307. tom What do you think?
  308. alberto has left
  309. tom Now if i can see how to configure coturn to log the info
  310. Holger `verbose`
  311. Ge0rG tom: this approach has a problem where the attackers will still see your server as a reflector on their scans, and then still abuse you.
  312. tom Sure some packets will sneak through, but they can't use your server for very long
  313. tom At least
  314. tom They'd have to keep changing source ips
  315. jonas’ tom, 120 / minute is hard to measure.
  316. tom Fail2ban could do that
  317. jonas’ that’s 2/second
  318. tom Which they are exceeding
  319. tom I'm showing ~15/second
  320. jonas’ problem with 2/second is, a legitimate call can produce that
  321. jonas’ also, gentle reminder that this is a public place and the attacker(s) may be listening in
  322. mjk has joined
  323. jonas’ be careful which countermeasures and details you share publicly
  324. abidal3 has joined
  325. tom » problem with 2/second is, a legitimate call can produce that 2 binding requests per second for 1 minute?
  326. tom That's why i said per minute not per second
  327. octagon has joined
  328. jonas’ no, not for one minute. just saying that measuring this correctly is fun
  329. tom Ok
  330. menel has joined
  331. tom I just want to say that coturn's configuration file options and syntax is terrible
  332. tom Wish there was a better turn server I could use
  333. jonas’ eturnal? :)
  334. jonas’ also, run your coturn with --prod to shave 20 bytes off the response :)
  335. tom I'll check that out
  336. kahlb The best thing would be: identify the scanner IP and blacklist it. Additionally take some of the countermeasures you just mentioned. As long as the scanner IP doesn't change it'd stop considering your system as vulnerable and the attacks would stop. But it's difficult to find these IPs. Best: Find systems *without* stun, search their firewall logs for UDP attempts on port 3478 and look wher they're coming from, since that can't be legit traffic. Hopefully there aren't so many, when in doubt just block em all. Maybe we should consider a public blacklist, though that could lead to countermeasures from attackers.
  337. tom kahlb: idk
  338. tom Trying to stop scanning on the internet seems like a fool's errand
  339. kahlb you can't stop scanning. But you can stop your system being identified as a reflector. At least up to some point.
  340. tom » --secure-stun » Require authentication of the STUN Binding request. By default, the clients are allowed anonymous access to the STUN Binding functionality. »
  341. patasca has left
  342. Maranda has left
  343. Maranda has joined
  344. sss has left
  345. sss has joined
  346. lorddavidiii has left
  347. *IM* has left
  348. lorddavidiii has joined
  349. Martin Makes it worse as the reply gets larger afaik.
  350. croax When media session between 2 contacts on different servers, does each contact use its own STUN/TURN or only caller one?
  351. octagon has left
  352. patasca has joined
  353. tom Ge0rG: jonas’ you should definitely turn on secure-turn first
  354. tom That way, all your legit users of your turn server will be differentiated from ddos spoof users
  355. tom Then it will be much easier to instead of block on n binding requests per minute, block on n 401 UNAUTHORIZEDs per minute
  356. kikuchiyo has left
  357. Holger croax, both might or might not be used. It doesn't depend on who is the caller.
  358. tom However, coturn has an absolute garbage logging syntax where things will need to be matched on multiple lines
  359. sss has left
  360. sss has joined
  361. Holger tom, I'm slightly biased but do believe eturnal's logging is way better.
  362. Holger And config 🙂
  363. rom1dep has left
  364. tom Thanks. I will be checking that out, I just can't change turn/stun servers today
  365. Pingu from Woodquarter has left
  366. Holger tom, main downside I see is, no official distro packages (yet).
  367. Holger croax, basically if your client isn't reachable directly by your peer, your TURN server is used.
  368. Holger croax, so if neither your nor your peer's client is directly reachable, both TURN servers are used.
  369. Bjarkan has joined
  370. croax Holger: thanks for clarification.
  371. jonas’ tom, except that this is about STUN, not TURN
  372. tom jonas’: still applicable
  373. jonas’ tom, question is: is the Not Authorized reply even larger? (IIRC the answer is "yes")
  374. jonas’ and as I understand the curent state of STUN/TURN/WebRTC affairs (and as we discussed yesterday), (legitimate) clients *have to* first fail authentication before they can authenticate because of challenge/response nonsense
  375. kikuchiyo has joined
  376. Holger Yes.
  377. Holger First auth step is to receive an UNAUTHORIZED response from the server.
  378. steven has joined
  379. Holger tom: > --secure-stun Do you use that? I would've been unsure whether e.g. libwebrtc copes with that.
  380. tom It does
  381. tom Nextcloud works with that too
  382. Holger Interesting. (I wonder what the point is though.)
  383. jonas’ more traffic, of course
  384. Bjarkan has left
  385. tom Do you wanna test it yourself?
  386. Bjarkan has joined
  387. tom Send some p2p file transfer with jingle
  388. Holger I asked a random guy on the Internet specifically because I've always been too lazy to test myself :-P
  389. Holger Because I didn't see any point anyway. Until we had that short-term-auth idea yesterday: If libwebrtc supports short-term _and_ has a code path for authenticated STUN, maybe things would just work. Maybe.
  390. patasca has left
  391. jonas’ and we get the STUN servers to STFU on authentication failure.
  392. jonas’ or maybe it doesn’t matter anymore then because the proper request packet is already large enough
  393. Holger I'd be way more afraid of submitting libwebrtc patches than of patching STUN servers.
  394. jonas’ worth a shot I guess
  395. Bjarkan has left
  396. tom Good
  397. 404.city has joined
  398. patasca has joined
  399. 404.city has left
  400. jonas’ except that it needs someone to write the code
  401. Holger I mean the Coturn guy is quite responsive, but who knows how easy it is to convince Google to merge some functionality eveyone else considers outdated.
  402. jonas’ Holger, did you already talk to coturn about short-term-auth?
  403. jonas’ I mean worst case we have to go through IETF to convince folks
  404. Link Mauve has joined
  405. Bjarkan has joined
  406. alberto has joined
  407. Holger jonas': No I didn't talk to him but I mean you could look at the old code for the short-term-auth support, and I guess an option to drop other traffic is trivial.
  408. jonas’ question is why it was removed
  409. jonas’ if they would be interested in readding it
  410. Holger As I said nobody uses it.
  411. jonas’ is that why it was dropped or is that your guess why it was dropped?
  412. Holger But Coturn is a bloated monster, I doubt he'll strongly oppose re-adding it if you use it.
  413. Holger My guess.
  414. jonas’ :)
  415. Holger Why else would it be dropped.
  416. jonas’ undisclosed security issue; impossibility to integrate with the remaining architecture; ...
  417. Holger I could add it to eturnal, you post an issue that Coturn is missing that feature in comparison and he'll add the code himself :-)
  418. Holger Nah.
  419. Holger And I don't think you need the IETF for a `drop-other-traffic` option.
  420. jonas’ but for a PoC we can easily go ahead with just eturnal
  421. Holger Yes. I'm just trying to explain why I think the real question is whether libwebrtc supports it.
  422. Holger https://webrtc.googlesource.com/src/
  423. Holger I'll have a look
  424. jonas’ -EATWORK, otherwise I’d look too
  425. steven has left
  426. Holger I keep re-cloning that into /tmp once every three months. Because this is the very last time I'm interested in it ...
  427. jonas’ I think you need to accept your fate that you’re now a webrtc person ;)
  428. octagon has joined
  429. steven has joined
  430. *IM* has joined
  431. seantodd has left
  432. seantodd has joined
  433. octagon has left
  434. Holger Doesn't look like libwebrtc supports short-term.
  435. tom Ah yes
  436. tom Goolag Korporation
  437. jonas’ Holger, any clue how a client using libwebrtc would indicate to it that it is supposed to use short term instead of long term?
  438. jonas’ could libwebrtc just *try* short term and then fall back to long term based on the response to short term, or does that not work in stun?
  439. Holger And now I remember that the TURN RFC has strong language towards long-term auth. (I had a discussion on whether to interpret it as long-term being mandatory last year or so. Why didn't I remember any of that yesterday? My brain is useless.)
  440. Holger The idea as per the STUN RFC is that client and server know what auth mechanism to expect before-hand. I.e. I'd imagine the libwebrtc user (Conversations) to specify a "do short-term" flag.
  441. Holger You obviously can't signal the desired mechanism without adding a round-trip, which is precisely the thing we'd like to avoid.
  442. alberto has left
  443. Holger From the TURN RFC: ``` The server MUST require that the request be authenticated. This authentication MUST be done using the long-term credential mechanism of [RFC5389] unless the client and server agree to use another mechanism through some procedure outside the scope of this document. ```
  444. Holger So there *is* a bit of room for an out-of-scope procedure :-)
  445. Holger ``` [RFC5389] specifies an authentication mechanism called the long-term credential mechanism. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used. ```
  446. Holger Those sentences won't make it easier to convince Google I guess ...
  447. Holger Maybe just change ports, call it a day, and spend your time on MIX :-P
  448. Holger I'm not _that_ concerned about the actual problem, but it _is_ a little annoying how the specs basically have exactly the thing that would make sense for our use case. And generally for the WebRTC use case.
  449. jonas’ yeah
  450. jonas’ annoying
  451. jonas’ > Why didn't I remember any of that yesterday? page faults take a while to service also in human brains ;)
  452. balabol.im has left
  453. balabol.im has joined
  454. patasca has left
  455. sol has joined
  456. kahlb has left
  457. mjk has left
  458. maxwell has joined
  459. mjk has joined
  460. octagon has joined
  461. mjk has left
  462. mjk has joined
  463. octagon has left
  464. neox has left
  465. neox has joined
  466. ricky has left
  467. Ge0rG has left
  468. Ge0rG has joined
  469. Maranda has left
  470. Maranda has joined
  471. Martin has left
  472. Martin has joined
  473. ross has left
  474. ross has joined
  475. p55s has joined
  476. menel has left
  477. menel has joined
  478. Ge0rG has left
  479. Ge0rG has joined
  480. patasca has joined
  481. christian has left
  482. kusoneko has left
  483. alberto has joined
  484. belove has left
  485. anu2019 has left
  486. x187x has left
  487. x187x has joined
  488. belove has joined
  489. kahlb has joined
  490. moparisthebest That RFC text is odd no? "You MUST do X, unless you don't want to"
  491. Pingu from Woodquarter has joined
  492. moparisthebest Sounds like a SHOULD
  493. patasca has left
  494. christian has joined
  495. kousu has left
  496. kousu has joined
  497. croax There _must_ be an auth mechanism. Long-term or equivalent/stronger. But no weaker/none. _Should_ would allow _none_ AFAIK
  498. amolith has left
  499. ricky has joined
  500. patasca has joined
  501. Holger The first of my above two quotes doesn't contain the "stronger" part though.
  502. Holger Which makes no sense for a protocol spec anyway.
  503. Holger And saying "client and server can agree on breaking the spec in arbitrary ways" is stating the obvious.
  504. Holger So effectively this does work like a proper MUST. A TURN client can assume the TURN server to support long-term auth, no need to check/negotiate that in any way.
  505. kryptos has joined
  506. ross has left
  507. ross has joined
  508. sonny has left
  509. sonny has joined
  510. sonny has left
  511. sonny has joined
  512. patasca has left
  513. anu2019 has joined
  514. lorddavidiii has left
  515. lorddavidiii has joined
  516. madmalkav has left
  517. octagon has joined
  518. balabol.im has left
  519. henrik has left
  520. henrik has joined
  521. balabol.im has joined
  522. kousu has left
  523. kousu has joined
  524. kryptos has left
  525. steven has left
  526. patasca has joined
  527. perflyst has joined
  528. kryptos has joined
  529. *IM* has left
  530. patasca has left
  531. alien has left
  532. octagon has left
  533. *IM* has joined
  534. undefined has left
  535. octagon has joined
  536. madmalkav has joined
  537. madmalkav has left
  538. madmalkav has joined
  539. undefined has joined
  540. alacer has left
  541. mjk has left
  542. kryptos has left
  543. Ge0rG has left
  544. patasca has joined
  545. Ge0rG has joined
  546. rom1dep has joined
  547. perflyst has left
  548. mjk has joined
  549. patasca has left
  550. patasca has joined
  551. madmalkav has left
  552. madmalkav has joined
  553. Mel has left
  554. Bjarkan has left
  555. alacer has joined
  556. rom1dep has left
  557. Bjarkan has joined
  558. Mel has joined
  559. inky has joined
  560. patasca has left
  561. steven has joined
  562. Bjarkan has left
  563. ernst.on.tour has left
  564. ernst.on.tour has joined
  565. Bjarkan has joined
  566. ross has left
  567. ross has joined
  568. ross has left
  569. ross has joined
  570. Ge0rG has left
  571. Ge0rG has joined
  572. ross has left
  573. ross has joined
  574. ross has left
  575. ross has joined
  576. Bjarkan has left
  577. menel has left
  578. menel has joined
  579. patasca has joined
  580. amolith has joined
  581. amolith has left
  582. guus.der.kinderen has joined
  583. iramaro has joined
  584. Bjarkan has joined
  585. patasca has left
  586. Bjarkan has left
  587. guus.der.kinderen has left
  588. undefined has left
  589. SouL has left
  590. x51 has joined
  591. kryptos has joined
  592. undefined has joined
  593. kusoneko has joined
  594. kusoneko has left
  595. kusoneko has joined
  596. SouL has joined
  597. Bjarkan has joined
  598. jayteeuk has left
  599. jayteeuk has joined
  600. Bjarkan has left
  601. Bjarkan has joined
  602. x187x has left
  603. schäfchen726 has left
  604. Bjarkan has left
  605. schäfchen726 has joined
  606. neox has left
  607. Lyn has left
  608. Lyn has joined
  609. menel has left
  610. menel has joined
  611. Lyn has left
  612. Lyn has joined
  613. kryptos has left
  614. menel has left
  615. menel has joined
  616. undefined has left
  617. patasca has joined
  618. patasca has left
  619. patasca has joined
  620. mjk has left
  621. mjk has joined
  622. Ge0rG has left
  623. Ge0rG has joined
  624. Bjarkan has joined
  625. undefined has joined
  626. patasca has left
  627. patasca has joined
  628. ricky has left
  629. rob Just scored colloquy.ca 🤓 now I have a generic donation for friends
  630. *IM* has left
  631. Maranda has left
  632. ricky has joined
  633. undefined has left
  634. *IM* has joined
  635. patasca has left
  636. patasca has joined
  637. neox has joined
  638. sonny has left
  639. sonny has joined
  640. octagon has left
  641. patasca has left
  642. patasca has joined
  643. Marzanna has left
  644. Marzanna has joined
  645. edhelas has left
  646. steven has left
  647. edhelas has joined
  648. octagon has joined
  649. schäfchen726 has left
  650. schäfchen726 has joined
  651. undefined has joined
  652. Lyn has left
  653. schäfchen726 has left
  654. schäfchen726 has joined
  655. Samir Allioui has left
  656. Samir Allioui has joined
  657. patasca has left
  658. patasca has joined
  659. schäfchen726 has left
  660. schäfchen726 has joined
  661. jl4 has joined
  662. schäfchen726 has left
  663. schäfchen726 has joined
  664. schäfchen726 has left
  665. Ge0rG has left
  666. Ge0rG has joined
  667. schäfchen726 has joined
  668. octagon Hmm, I changed my port yesterday but am still seeing many requests a second to 3478
  669. abidal3 has left
  670. Samir Allioui has left
  671. Samir Allioui has joined
  672. schäfchen726 has left
  673. secret.gombino2nd has joined
  674. patasca has left
  675. patasca has joined
  676. menel That's because of what what someone else postet > because the attackers only scan once or every few months. They don't get an idea if your IP is still a usable reflector, only if they scan again.
  677. schäfchen726 has joined
  678. octagon has left
  679. menel Until you are out of every list they collected it will continue
  680. Bjarkan has left
  681. menel So now you are doing your part in diluting the attack 😀
  682. alex-a-soto has left
  683. menel Wasting resources of the attackers
  684. moparisthebest so with normal STUN usage is it request> response > request > response ? or just a single request > response ?
  685. patasca has left
  686. patasca has joined
  687. alex-a-soto has joined
  688. Bjarkan has joined
  689. sonny has left
  690. sonny has joined
  691. Licaon_Kter I don't see why they can't request continously...
  692. moparisthebest Licaon_Kter, because if the protocol expects a second response, you can identify clients that don't do this and ignore them (preventing spoofing)
  693. jonas’ moparisthebest, with *un*authenticated *STUN*, it is request > response; with authenticated STUN it is request > response > request > response.
  694. jonas’ but AIUI authenticated STUN response on missing auth is (a) required for legitimate clients to work and (b) larger.
  695. Bjarkan has left
  696. lorddavidiii has left
  697. Bjarkan has joined
  698. rob Just scored colloquy.ca 🤓 now I have a generic domain for friends
  699. undefined has left
  700. schäfchen726 has left
  701. lorddavidiii has joined
  702. lorddavidiii has left
  703. alex-a-soto has left
  704. alex-a-soto has joined
  705. schäfchen726 has joined
  706. lorddavidiii has joined
  707. undefined has joined
  708. Ge0rG has left
  709. Ge0rG has joined
  710. patasca has left
  711. patasca has joined
  712. Pingu from Woodquarter has left
  713. schäfchen726 has left
  714. schäfchen726 has joined
  715. Pingu from Woodquarter has joined
  716. Marzanna has left
  717. Marzanna has joined
  718. patasca has left
  719. patasca has joined
  720. x187x has joined
  721. octagon has joined
  722. patasca has left
  723. Bjarkan has left
  724. patasca has joined
  725. iramaro has left
  726. iramaro has joined
  727. patasca has left
  728. patasca has joined
  729. jl4 has left
  730. Bjarkan has joined
  731. octagon slightly offtopic: loading a large ipset on fedora/rh causes each cidr insert to be checked against the selinux policy and not completely inserted. a list with a few thousand cidr's quickly ends up using 20+GB of ram. anyone have any insight about htis?
  732. octagon the same script works on debian, and only uses <200MB ram
  733. schäfchen726 has left
  734. Bjarkan has left
  735. Marzanna has left
  736. Marzanna has joined
  737. secret.gombino2nd has left
  738. lorddavidiii has left
  739. Bjarkan has joined
  740. mjk has left
  741. schäfchen726 has joined
  742. patasca has left
  743. patasca has joined
  744. Samir Allioui has left
  745. Samir Allioui has joined
  746. mjk has joined
  747. Bjarkan has left
  748. Bjarkan has joined
  749. moparisthebest at least that has an easy solution: turn off selinux
  750. moparisthebest runs
  751. patasca has left
  752. patasca has joined
  753. octagon has left
  754. patasca has left
  755. patasca has joined
  756. Bjarkan has left
  757. Bjarkan has joined
  758. patasca has left
  759. rom1dep has joined
  760. abidal3 has joined
  761. kryptos has joined
  762. octagon has joined
  763. perflyst has joined
  764. x51 has left
  765. Ivan A. has left
  766. rom1dep has left
  767. rom1dep has joined
  768. Ivan A. has joined
  769. Bjarkan has left
  770. Bjarkan has joined
  771. Bjarkan has left
  772. Bjarkan has joined
  773. patasca has joined
  774. patasca has left
  775. patasca has joined
  776. Bjarkan has left
  777. abidal3 has left
  778. abidal3 has joined
  779. Bjarkan has joined
  780. patasca has left
  781. patasca has joined
  782. Bjarkan has left
  783. Bjarkan has joined
  784. abidal3 has left
  785. abidal3 has joined
  786. perflyst has left
  787. Bjarkan has left
  788. Bjarkan has joined
  789. derventio has joined
  790. alien has joined
  791. x187x has left
  792. x187x has joined
  793. patasca has left
  794. x51 has joined
  795. patasca has joined
  796. maxwell has left
  797. ibikk has left
  798. maxwell has joined
  799. patasca has left
  800. mjk has left
  801. pod has left
  802. Maranda has joined
  803. kryptos has left
  804. patasca has joined
  805. mjk has joined
  806. patasca has left
  807. patasca has joined
  808. dinosaurdynasty has left
  809. patasca has left
  810. patasca has joined
  811. karme has left
  812. alberto has left
  813. Ge0rG has left
  814. Ge0rG has joined
  815. Mel has left
  816. Mel has joined
  817. patasca has left
  818. patasca has joined
  819. dinosaurdynasty has joined
  820. ross has left
  821. ross has joined
  822. patasca has left
  823. patasca has joined
  824. derventio has left
  825. schäfchen726 has left
  826. madmalkav has left
  827. derventio has joined
  828. Suren has left
  829. patasca has left
  830. patasca has joined
  831. Ge0rG has left
  832. Ge0rG has joined
  833. Steven Roose has left
  834. menel has left
  835. patasca has left
  836. ross has left
  837. ross has joined
  838. marc has left
  839. schäfchen726 has joined
  840. ross has left
  841. ross has joined
  842. henrik has left
  843. henrik has joined
  844. Ge0rG has left
  845. Ge0rG has joined
  846. mjk has left
  847. Maranda has left
  848. henrik has left
  849. 4223 has left
  850. kikuchiyo has left
  851. 4223 has joined
  852. mjk has joined
  853. schäfchen726 has left
  854. schäfchen726 has joined
  855. henrik has joined
  856. kikuchiyo has joined
  857. schäfchen726 has left
  858. abidal3 has left