XMPP Service Operators - 2021-04-29

  1. mjk has left
  2. Douglas Terabyte has joined
  3. mjk has joined
  4. Mel has left
  5. octagon has left
  6. neox has left
  7. abidal3 has left
  8. Samir Allioui has left
  9. Samir Allioui has joined
  10. iramaro has left
  11. octagon has joined
  12. Mel has joined
  13. Marzanna has left
  14. Lyn has joined
  15. Marzanna has joined
  16. octagon has left
  17. sol has left
  18. octagon has joined
  19. stpeter has left
  20. Samir Allioui has left
  21. Samir Allioui has joined
  22. stpeter has joined
  23. Mel has left
  24. patasca has left
  25. patasca has joined
  26. patasca has left
  27. patasca has joined
  28. tom has left
  29. patasca has left
  30. patasca has joined
  31. patasca has left
  32. patasca has joined
  33. sol has joined
  34. kryptos has joined
  35. Mel has joined
  36. stpeter has left
  37. ross has left
  38. ross has joined
  39. octagon has left
  40. mjk has left
  41. patasca has left
  42. patasca has joined
  43. octagon has joined
  44. patasca has left
  45. patasca has joined
  46. Samir Allioui has left
  47. Samir Allioui has joined
  48. Licaon_Kter has left
  49. bakunin1848 has joined
  50. bakunin1848 has left
  51. Mel has left
  52. patasca has left
  53. patasca has joined
  54. Mel has joined
  55. Lyn has left
  56. Lyn has joined
  57. Samir Allioui has left
  58. kryptos has left
  59. kryptos has joined
  60. patasca has left
  61. patasca has joined
  62. tom has joined
  63. patasca has left
  64. patasca has joined
  65. patasca has left
  66. patasca has joined
  67. Maranda has left
  68. Mel has left
  69. Mel has joined
  70. patasca has left
  71. patasca has joined
  72. Maranda has joined
  73. Lyn has left
  74. Lyn has joined
  75. Lyn has left
  76. Lyn has joined
  77. patasca has left
  78. patasca has joined
  79. kryptos has left
  80. Lyn has left
  81. Mel has left
  82. Mel has joined
  83. patasca has left
  84. menel has joined
  85. pod has joined
  86. patasca has joined
  87. lorddavidiii has joined
  88. Huxx has joined
  89. ibikk has joined
  90. ernst.on.tour has left
  91. patasca has left
  92. ernst.on.tour has joined
  93. Mel has left
  94. Mel has joined
  95. balabol.im has joined
  96. mimi89999 has left
  97. mimi89999 has joined
  98. neox has joined
  99. octagon has left
  100. patasca has joined
  101. Licaon_Kter has joined
  102. maxwell has joined
  103. Sam has left
  104. alberto has joined
  105. Mel has left
  106. patasca has left
  107. Mel has joined
  108. Pingu from Woodquarter has left
  109. abidal3 has joined
  110. abidal3 has left
  111. abidal3 has joined
  112. octagon has joined
  113. balabol.im has left
  114. Sam has joined
  115. balabol.im has joined
  116. Douglas Terabyte has left
  117. madmalkav has joined
  118. Django has left
  119. Django has joined
  120. menel has left
  121. Lyn has joined
  122. alberto has left
  123. Mel has left
  124. Mel has joined
  125. Douglas Terabyte has joined
  126. alberto has joined
  127. Martin WTF Melinda Thompson?
  128. raghavgururajan has left
  129. jonas’ I, too, have questions.
  130. octagon has left
  131. ricky has left
  132. Maranda Poor jonas’... Being sued for talking about STUN/TURN security implications on a mailing list
  133. [czar] has left
  134. Maranda 🐈
  135. marc has joined
  136. Diego has left
  137. Licaon_Kter Maranda: links...links c'mon
  138. jonas’ Licaon_Kter, https://mail.jabber.org/pipermail/operators/2021-April/003135.html
  139. Licaon_Kter 10x
  140. schäfchen726 has joined
  141. Licaon_Kter Nothing says real person more than `"Jane Doe" <evesmith3413@gmail.com>` ¯\_(ツ)_/¯
  142. Sam has left
  143. Sam has joined
  144. octagon has joined
  145. Lyn has left
  146. Lyn has joined
  147. p55s has left
  148. pepta.net Relaying e-mail to the police? Sounds like a compromised STUN over SMTP
  149. pepta.net Relaying e-mail to the police? Sounds like a compromised TURN over SMTP
  150. abidal3 has left
  151. octagon has left
  152. ricky has joined
  153. menel has joined
  154. menel Anonymus threats is not the same as "beeing sued" That mail is laughable.
  155. jonas’ very true. I’m not taking this in any way serious, esp. because there’s nothing I’ve done wrong under any jurisdiction affecting me.
  156. octagon has joined
  157. Martin just wonders what's wrong with that person.
  158. jonas’ could be a translation issue or maybe they didn’t realize that the mail came from a mailing list or maybe google flagged it because DKIM and that made it look suspicious or whatever
  159. pepta.net Or this is very serious and sooner or later you'll receive an injonction from tribunal not to ask for people to randomize their STUN/TURN ports xD (joke)
  160. madmalkav has left
  161. anu2019 has left
  162. anu2019 has joined
  163. menel has left
  164. madmalkav has joined
  165. Steven Roose has joined
  166. balabol.im has left
  167. balabol.im has joined
  168. Martin has left
  169. Martin has joined
  170. steven has joined
  171. Pingu from Woodquarter has joined
  172. octagon has left
  173. octagon has joined
  174. mjk has joined
  175. abidal3 has joined
  176. Bjarkan has joined
  177. octagon has left
  178. patasca has joined
  179. quantumwings has left
  180. quantumwings has joined
  181. balabol.im has left
  182. [czar] has joined
  183. balabol.im has joined
  184. p55s has joined
  185. schäfchen726 has left
  186. schäfchen726 has joined
  187. alberto has left
  188. mjk has left
  189. mjk has joined
  190. sonny has left
  191. sonny has joined
  192. madmalkav has left
  193. perflyst has joined
  194. alberto has joined
  195. mjk has left
  196. x187x has left
  197. mjk has joined
  198. secret.gombino2nd has joined
  199. patasca has left
  200. madmalkav has joined
  201. octagon has joined
  202. perflyst has left
  203. anu2019 has left
  204. menel has joined
  205. secret.gombino2nd has left
  206. octagon has left
  207. alberto has left
  208. Samir Allioui has joined
  209. x51 has joined
  210. Bjarkan has left
  211. menel has left
  212. menel has joined
  213. rom1dep has joined
  214. alberto has joined
  215. balabol.im has left
  216. steven has left
  217. sonny has left
  218. sonny has joined
  219. octagon has joined
  220. Licaon_Kter What a difference an year makes 2020: OMG https://nitter.fdn.fr/HCornflower/status/1254003453011034112#m & https://nitter.fdn.fr/HCornflower/status/1254068862158614529#m VS 2021: MEH https://mail.jabber.org/pipermail/operators/2021-April/003131.html
  221. abidal3 has left
  222. balabol.im has joined
  223. menel has left
  224. perflyst has joined
  225. Wiktor lol didn't know the guy so closely follows xmpp 😀
  226. octagon Is simply changing port number really that effective? Even if an enterprising attacker can port scan or lookup SRV records?
  227. Martin I don't have srv records for stun/turn
  228. jonas’ Wiktor, you are aware that Philipp Hancke is fippo, who has a huge part in the authorship of Jingle?
  229. jonas’ octagon, scanning all UDP ports + all IPv4 addresses is much more expensive (by a factor of 65535) than just scanning all IPv4 addresses on a well-known port. and yes, the STUN/TURN port is not advertised via SRV typically
  230. Wiktor jonas’, yeah, but I didn't know he's still interested in that in context of xmpp, I thought it's part of the disconnect of google from xmpp and just using jingle for other purposes (webrtc)
  231. jonas’ he’s sometimes to be seen on the xeps github as well as standards@
  232. Wiktor oh, I see
  233. jonas’ and, apparently, operators@
  234. Wiktor always criticizing... I get it 🙂
  235. jonas’ and Licaon_Kter, I don’t blame him for questioning this... I am also fairly certain that the email has to be read as "are you sure this is being attacked? if so... we need to ask critically why, because it does no seem to be the amplification factor alone which makes this interesting".
  236. neox has left
  237. jonas’ Wiktor, I’d call it "asking the hard questions nobody wants to think about" especially in the linked context
  238. Licaon_Kter Ofcourse, it just pinged when I saw his name and remembered those remarks on Conversations A/V launch.
  239. 404.city has joined
  240. Licaon_Kter Yes, I want to see the links to the attacks too...as I don't see any random stun/turn connections here. But whenwI hosted SIP I had >1000 connections on 5060/5061, no visible impact but they were there in my router
  241. 404.city has left
  242. Licaon_Kter Yes, I want to see the links to the attacks too...as I don't see any random stun/turn connections here. But when I hosted SIP I had >1000 connections on 5060/5061, no visible impact but they were there in my router
  243. jonas’ Licaon_Kter, how are you measuring your STUN/TURN "connections"?
  244. Samir Allioui has left
  245. Samir Allioui has joined
  246. Bjarkan has joined
  247. Licaon_Kter I see them in ejabberd logs, but was expecting activity on the router/firewall
  248. hotaru has left
  249. hotaru has joined
  250. Licaon_Kter I'm not measuring, actively, but RPi's are rather sensible to load :)
  251. jonas’ Licaon_Kter, maybe do a tcpdump on udp port 3478
  252. perflyst has left
  253. Bjarkan has left
  254. ross has left
  255. ross has joined
  256. abidal3 has joined
  257. tom has left
  258. rom1dep has left
  259. Bjarkan has joined
  260. abidal3 has left
  261. octagon has left
  262. octagon has joined
  263. sonny has left
  264. sonny has joined
  265. Bjarkan has left
  266. Ivan A. has left
  267. iramaro has joined
  268. Samir Allioui has left
  269. Bjarkan has joined
  270. Samir Allioui has joined
  271. Bjarkan has left
  272. Bjarkan has joined
  273. Andy Smith has joined
  274. jl4 has joined
  275. Ivan A. has joined
  276. pepta.net What a mess nowadays to allow two peers to exchange data... STUN/TURNS/other protocols, server ressources... all because of ipv4 is still alive. Internet failure.
  277. menel has joined
  278. Andy Smith has left
  279. Licaon_Kter All because ipv6 was just born we should do what? pepta.net
  280. mjk has left
  281. pepta.net Us: nothing. But ICANN could have speed up things mandating every ISP to provide IPv6 everywhere and deprecate ipv4 with deadlines.
  282. pepta.net Us: nothing. But ICANN could have speed up things mandating every ISP to provide IPv6 everywhere and deprecate (and kill) ipv4 with deadlines.
  283. mjk has joined
  284. pepta.net Dual stack seems more now forever than a temporary transitional situation. Making everyone to suffer from ipv4 cons.
  285. Ge0rG BWAHAHAHA
  286. octagon has left
  287. steven has joined
  288. patasca has joined
  289. octagon has joined
  290. anu2019 has joined
  291. patasca has left
  292. octagon has left
  293. octagon has joined
  294. pepta.net Except we can provide IPv6 compatible services whenever possible.
  295. pepta.net Except we can provide IPv6 compatible services whenever possible. To make things evolve step-by-step.
  296. Licaon_Kter Who's this we? How can I provide anything where there's no 6 here?
  297. patasca has joined
  298. pepta.net We = service providers. If no 6 available, can't ask for the impossible. Maybe consider ISP/hosting switching, or any action to manifest your disappointment to your providers.
  299. jl4 has left
  300. jl4 has joined
  301. Ge0rG has left
  302. Ge0rG has joined
  303. Licaon_Kter No 6 in sight... But see, they announced 6 back in '15 so PR side all is well
  304. moparisthebest Couldn't you filter the IPs you accept connections to your stun server on based on the IPs of clients currently connected to your XMPP server?
  305. jonas’ moparisthebest, no, you also need to accept packets from their peers
  306. jonas’ AIUI
  307. jonas’ at least once the channel is established
  308. jonas’ though possibly that is only after the initial STUN phase
  309. jonas’ and the initial STUN phase is the problme
  310. jonas’ moparisthebest, but with CGNATs, you can never know whether they always end up with the same egress IP for the same flow
  311. jonas’ and CGNATs is where you need it most :(
  312. moparisthebest So we need our own stun protocol replacement with an auth secret ? :/
  313. jonas’ and of course it requires a live channel between your xmppd and the stun server… which people wanted to avoid with REST mode
  314. octagon has left
  315. jonas’ moparisthebest, I don’t even know at this point what the attackers want to achieve
  316. sol has left
  317. jonas’ so I refrain from making improvement suggestions at this ponit
  318. moparisthebest Or between your xmppd and the firewall in front of your stun server
  319. jonas’ same thing really :)
  320. jonas’ also I’m not sure how well that scales…
  321. moparisthebest So if you accidentally blocked stun for unfortunate cgnat people, they'd just use turn right?
  322. jonas’ no, you need STUN before you TURN AFAIK
  323. moparisthebest If so, I think they'd have to do that anyway
  324. jonas’ I need to dig deeper into ICE
  325. jonas’ however, at this point, moving ports has mitigated the traffic 100%, so I’m not going to worry about that until the abuse alert triggers on the new port ;)
  326. moparisthebest It tries stun before turn before, the question is if no stun response will it go to turn
  327. henrik has left
  328. moparisthebest Moving ports is at most a temporary fix, scanning the entire ipv4 internet is easy
  329. jonas’ scanning IPv4 + all UDP ports is not that easy
  330. moparisthebest Likely shodan would already tell you about all stun ports
  331. jonas’ if you need one day to scan the entire IPv4 range, you need 2^16 days for that on all UDP ports.
  332. mjk has left
  333. patasca has left
  334. patasca has joined
  335. jonas’ even if we’re going to assume that only half of the port range is used and that you only need to scan every other port because of the alt port mechanic, that’s still 16kdays
  336. moparisthebest I guess it'd be easy to test what no stun, only turn, looks like in practice, just turn it off/block the port and see if calls go through
  337. moparisthebest https://github.com/robertdavidgraham/masscan can scan the entire internet in <5 minutes so I wouldn't count on numbers saving you here
  338. Ge0rG has left
  339. Holger moparisthebest, jonas', yes only the initial phase is the problem, a peer port is only allocated after successful TURN authentication (and can't be used for such an attack then either).
  340. Ge0rG has joined
  341. octagon has joined
  342. Holger And yes you could avoid the issue by having some integration with the XMPP server.
  343. moparisthebest as far as scaling goes, ipset https://wiki.archlinux.org/index.php/Ipset can easily whitelist more IPs than your XMPP server can handle, doing this on not-linux is left as an exercise for the user
  344. lorddavidiii has left
  345. mjk has joined
  346. jonas’ ipset is dead tho? but I suppose nft has the same mechanism.
  347. Holger Dual stack foo will be fun again though.
  348. pepta.net > https://github.com/robertdavidgraham/masscan can scan the entire internet in <5 minutes so I wouldn't count on numbers saving you here Read full README before trying ;-) > Scanning the entire Internet is bad. For one thing, parts of the Internet react badly to being scanned. For another thing, some sites track scans and add you to a ban list, which will get you firewalled from useful parts of the Internet.
  349. jonas’ moparisthebest, oh yes. challenge: a client is connected via IPv6, but its peer is connected via IPv4. Thus ICE can only succeed via v4, meaning that the STUN server needs to be reached over v4, but the v4 address of the client is not goign to be whitelisted
  350. Holger Yes that's what I mean (or vice-versa).
  351. jonas’ moparisthebest, oh yes. challenge: a client is connected via IPv6, but its peer is connected via IPv4. Thus ICE can only succeed via v4, meaning that the STUN server needs to be reached over v4, but the v4 address of the client is not known by the xmppd and thus not allowlisted in the firewall.
  352. moparisthebest and in theory, it can't reach STUN and falls back to TURN, no problem
  353. jonas’ moparisthebest, but then you’re using TURN which sucks.
  354. jonas’ for no good reason, too
  355. jonas’ &
  356. moparisthebest the good reason is avoiding STUN amplification attacks I guess
  357. Holger It may well try to reach TURN via v4 and v6.
  358. Holger You don't want one of those to fail.
  359. moparisthebest you don't need to ip-whitelist the TURN ports
  360. Holger Huh?
  361. Holger There's no such thing as a TURN-only port.
  362. Holger Protocol-wise, TURN is a STUN extension.
  363. moparisthebest then you can't do this with iptables/firewall (unless it can tell the difference between STUN and TURN) and it needs done in the STUN/TURN server itself ?
  364. moparisthebest so that you can ip-whitelist STUN but allow-all with TURN ?
  365. Holger I understand nothing.
  366. Licaon_Kter moparisthebest: wherem do you get the ip's to whitelist exactly?
  367. Holger The entire idea only works if you handle STUN and TURN the same way. Regardless of whether you involce the STUN/TURN server or just the firewall.
  368. Licaon_Kter moparisthebest: where do you get the ip's to whitelist exactly?
  369. moparisthebest Licaon_Kter, the client IPs currently connected to your XMPP server
  370. Holger Right. I would think this could work (for STUN and TURN), modulo dual-stack foo (as usual).
  371. moparisthebest Holger, pseudo-code, in the turn server accept packet bit: if packet.is_stun() && packet.ip_is_whitelisted() { packet.respond(); } else if packet.is_turn() { packet.respond(); } // otherwise no response to packet
  372. Holger moparisthebest: As I said, that's not how it works.
  373. moparisthebest since stun isn't authenticated, you only respond if the IP is whitelisted, turn is authenticated so no need to whitelist there
  374. moparisthebest but it *can* work that way, no ?
  375. Holger That's not how it works.
  376. Holger No.
  377. moparisthebest why not ?
  378. Holger Only by changing the protocol.
  379. Holger If it worked that way, you could just enforce authentication for STUN as well.
  380. Bjarkan has left
  381. Holger It doesn't work because the attack happens in the pre-auth phase.
  382. Holger And authentication is challenge-response.
  383. Holger No way to avoid sending the challenge to the spoofed address.
  384. moparisthebest so the server talks first even in the auth/turn scenario? :/
  385. Holger And at this point there's no difference between STUN and TURN.
  386. lorddavidiii has joined
  387. kryptos has joined
  388. Holger The server sends an "auth required, here's your challenge" in the auth/TURN scenario, yes.
  389. Holger The server *responds* with that "auth required, here's your challenge" packet to the initial client query.
  390. patasca has left
  391. Holger But it's not obvious to me anyway how the idea depends on handling TURN in different ways.
  392. patasca has joined
  393. moparisthebest ugh, so yea, I guess it's: 1. fix STUN/TURN protocol 2. XEP so client sends all IPs it might use to the server after login for whitelisting :'(
  394. Holger 2. alone would do the trick I guess.
  395. mjk has left
  396. moparisthebest if the initial TURN packet from the client was "hi start a TURN session and this is my authentication key: stnhaoeunsth" that could be let through without whitelisting
  397. moparisthebest but, apparently that's not how it works
  398. pepta.net moparisthebest: AFAIK you cannot rely on ip src to be the same for two separate connexions because of CGNAT.
  399. Holger Right, if we had a way to negotiate that key outside of TURN.
  400. moparisthebest yep it's either 1 or 2, but 2 is the only thing I think the XMPP community alone can reasonable do ?
  401. moparisthebest pepta.net, yep jonas’ said as much, I don't have a solution there
  402. Holger Indeed.
  403. sol has joined
  404. moparisthebest what about... kinda port knocking ?
  405. moparisthebest you get a secret from the XMPP server, send it to the STUN port, and that IP is whitelisted for the real STUN request that comes later ?
  406. jonas’ you can’t do (2) though
  407. jonas’ a client doesn’t know it’s IP … it needs STUN for that ;D
  408. moparisthebest right, so you have a pre-STUN reverse-STUN that whitelists the client's IP for the real STUN ? :P
  409. Holger Ah indeed :-)
  410. jonas’ "well"
  411. pepta.net https://xmpp.org/extensions/inbox/sic.html needed ?
  412. jonas’ moparisthebest, as I also said on-list… there are much more lucrative amplification attack targets than STUN servers out there.
  413. jonas’ It makes absolutely no sense to abuse stun for that
  414. moparisthebest I don't think expecting sense from attackers will work very well
  415. maxwell has left
  416. jonas’ oh I think it does
  417. jonas’ and I think we must
  418. jonas’ otherwise we might be fixing the wrong thing
  419. pepta.net has left
  420. moparisthebest if we fix it so our STUN servers can't be used for amplification at all, it doesn't matter what the attackers do ?
  421. jonas’ no
  422. jonas’ that’s not true
  423. patasca has left
  424. jonas’ ITYM can’t be used for reflection, in which case it might indeed be true
  425. patasca has joined
  426. jonas’ because not all amplification fixes (such as requiring a minimum inbound payload of 100 bytes, e.g. padding) may fix other aspects of the attack
  427. moparisthebest I was just talking about adding authentication, so an authenticated XMPP client can do what they want
  428. jonas’ we have that in theory… for TURN anyway (and leaving out the fact that the not authorized message is, again, larger than the request)
  429. Holger We don't.
  430. Holger I mean.
  431. jonas’ we don’t?
  432. Holger The point would be accepting an auth token/password rather than doing challenge/response.
  433. Holger We do have 0215 to communicate a token to the client.
  434. jonas’ isn’t that how it’s used?
  435. Holger But STUN/TURN doesn't have a way of checking that in the initial request.
  436. jonas’ do I need to read the TURN RFC?
  437. moparisthebest so my hack proposal was a new auth'd protocol to whitelist the client's IP, and then proceed with regular STUN/TURN
  438. Holger I keep repeating myself on this point as well but people keep ignoring me until Philipp Hanck pops up 😂️
  439. maxwell has joined
  440. jonas’ I start regretting bringing this up
  441. Holger > he server sends an "auth required, here's your challenge" in the auth/TURN scenario, yes.
  442. Licaon_Kter moparisthebest: > the client IPs currently connected to your XMPP server Wait...but... > you also need to accept packets from their peers ...
  443. moparisthebest I mean literally something that listens for a single UDP packet with "auth my IP please, auth code: XXXX", and it only responds with "ok" if the auth code is correct
  444. moparisthebest then regular STUN/TURN takes over
  445. Holger Because back then people like Neustradamus explained how PLAIN auth is the end of the world and all we can allow is MD5-based challenge-response.
  446. Holger So now all we have to check a temporary token is MD5-based challenge-response.
  447. Holger moparisthebest, and you'd add that to what spec?
  448. patasca has left
  449. octagon Can't we just rate limit the port with iptables?
  450. patasca has joined
  451. moparisthebest Holger, I guess a XEP specifies sending the auth code, and maybe the UDP packet ? :/
  452. croax octagon, would make it easy DOS?
  453. jonas’ octagon, rate limiting, even by IP subnet, was surprisingly tricky. Tried that.
  454. jonas’ not tricky to set up, but tricky to get right
  455. jonas’ call attempts cause packet bursts, and if you have to retry within a given time frame because of an unrelated error, this will make it harder for you to succeed at having a call
  456. jonas’ might be better if you also filter for specific STUN packet types, not sure if I went that far before moving on to changing the port
  457. jonas’ moparisthebest, currently, my hypothesis is that we’re already golden if we change ports because reasons.
  458. Bjarkan has joined
  459. jonas’ even if the stun servers are rediscovered, they may not be useful for the type of attack
  460. ross has left
  461. ross has joined
  462. moparisthebest changing ports is good, causes no harm, we should do it, I'm just uncomfortable with that being the final solution
  463. jonas’ moparisthebest, I would do that and reconsider more drastic measures when the attacks come back
  464. Holger Actually!!
  465. croax and you can randomize ports within a time-limited window, to enhance the proposed work-around.
  466. moparisthebest takes too long to actually do something else though, I'd rather start now
  467. jonas’ croax, you can indeed
  468. Holger I totally forgot about the Short-Term Credential Mechanism (which is completely unused AFAIK): https://tools.ietf.org/html/rfc5389#section-10.1
  469. Holger But possibly precisely what we'd need.
  470. jonas’ moparisthebest, yep if we have the time we should do the proper fix and go ahead and fix STUN/TURN themselves where necessary
  471. Holger I.e. my "all we have is challenge-response" claims were incorrect 🙂
  472. jonas’ Holger, ehh, I was always assuming that that’s exactly what clients do?!
  473. Holger No they always do long-term.
  474. moparisthebest that does seem exactly what is needed Holger , what are the chances libwebrtc has support :/
  475. Holger Not sure e.g. libwebrtc will even implement short-term.
  476. Holger moparisthebest, right, that's the question.
  477. jonas’ well, libwebrtc is on github, isn’t it?
  478. jonas’ shouldn’t be that hard to implement support?
  479. jonas’ add it to libnice and be golden
  480. moparisthebest it's google's
  481. jonas’ worth trying I guess
  482. Holger Either way maybe that's the proper solution.
  483. moparisthebest if it was any other company, I'd be more optimistic
  484. Ge0rG has left
  485. Holger And then add to 0215 that we do short-term (unlike the rest of the world).
  486. Holger Well, good enough to recommend that.
  487. Ge0rG has joined
  488. Holger Does Coturn support it?
  489. Holger (eturnal doesn't ...)
  490. jonas’ I am happy to implement it there if it helps
  491. jonas’ should be just a bit of C++ I guess
  492. Holger Just curious.
  493. henrik has joined
  494. moparisthebest "should be just a bit of C++" famous last words 🤣️
  495. jonas’ Holger, it caims to support 5389
  496. Holger Well I claim that as well 😂️
  497. Holger But yes may well be supported of course.
  498. jonas’ ``` -a, --lt-cred-mech Use long-term credentials mechanism (this one you need for WebRTC usage). ```
  499. jonas’ so I guess the default is short term?
  500. jonas’ I don’t set that though
  501. Holger Would sound weird to me but either way "WebRTC usage" is exactly what we're doing.
  502. Holger ``` 1/24/2015 Oleg Moskalenko <mom040267@gmail.com> Version 'Ardee West': - https admin server; - SSLv2 support cancelled (security concern fixed); - The server-side short-term credentials mechanism support cancelled; ```
  503. jonas’ "oh no"
  504. Holger So maybe it's a simple `git revert` 🙂
  505. moparisthebest Revert revert!
  506. Bjarkan has left
  507. Bjarkan has joined
  508. Holger ``` both modified: ChangeLog both modified: INSTALL both modified: README.turnserver both modified: examples/etc/turnserver.conf both modified: examples/var/db/turndb both modified: man/man1/turnserver.1 both modified: rpm/build.settings.sh both modified: rpm/turnserver.spec both modified: src/apps/relay/dbdrivers/dbd_mongo.c both modified: src/apps/relay/dbdrivers/dbd_mysql.c both modified: src/apps/relay/dbdrivers/dbd_pgsql.c both modified: src/apps/relay/dbdrivers/dbd_redis.c both modified: src/apps/relay/dbdrivers/dbd_sqlite.c both modified: src/apps/relay/dbdrivers/dbdriver.h both modified: src/apps/relay/mainrelay.c both modified: src/apps/relay/userdb.c both modified: src/apps/relay/userdb.h both modified: src/apps/uclient/mainuclient.c both modified: src/client/ns_turn_msg.h both modified: src/ns_turn_defs.h both modified: src/server/ns_turn_server.c both modified: turndb/schema.mongo.sh both modified: turndb/testmongosetup.sh ```
  509. Holger A simple `git revert` with a tiny bit of merge work.
  510. moparisthebest I wonder if that means they won't accept it upstream though
  511. jl4 has left
  512. Holger So I have a new secret plan how to sell my eturnal thingy.
  513. Holger Short-term-cred version will be expensive.
  514. moparisthebest Inb4 Holger hired by Google
  515. Holger One question is whether libraries such as libwebrtc support short-term creds, the other is whether they support authenticated STUN.
  516. moparisthebest you'd still need to violate that RFC a bit
  517. moparisthebest o If the message does not contain both a MESSAGE-INTEGRITY and a USERNAME attribute: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 400 (Bad Request).
  518. moparisthebest you'd need to just not respond
  519. patasca has left
  520. moparisthebest same with invalid username/password
  521. patasca has joined
  522. jayteeuk has left
  523. jayteeuk has joined
  524. Bjarkan has left
  525. Holger Yes the TURN server would have to be configurable to work that way.
  526. Bjarkan has joined
  527. sonny has left
  528. sonny has joined
  529. moparisthebest or if the response was smaller it'd be ok but no idea if that's the case here
  530. stpeter has joined
  531. kryptos has left
  532. Holger I still doubt it's about the response size 🙂
  533. sonny has left
  534. sonny has joined
  535. moparisthebest yea you are right, it's less a problem if response is less, but a problem anyway
  536. kikuchiyo has left
  537. Andy Smith has joined
  538. Bjarkan has left
  539. Bjarkan has joined
  540. jl4 has joined
  541. Andy Smith has left
  542. patasca has left
  543. patasca has joined
  544. Bjarkan has left
  545. kryptos has joined
  546. kikuchiyo has joined
  547. alberto has left
  548. ernst.on.tour has left
  549. ernst.on.tour has joined
  550. sonny has left
  551. sonny has joined
  552. patasca has left
  553. patasca has joined
  554. sonny has left
  555. sonny has joined
  556. Bjarkan has joined
  557. neox has joined
  558. neox has left
  559. croax As long as factor is <= 1 it would no more be a problem as attacker are supposed to only exploiting this to the benefit Of data amplification.
  560. croax As long as factor is <= 1 it would no more be a problem as attacker are supposed to only exploit this to the benefit of data amplification.
  561. moparisthebest croax, it stops data amplification, but still allows them to hide their true source IP
  562. croax Yet, their is Windows user for that. :-)
  563. Bjarkan has left
  564. croax Yet, their are Windows user for that. :-)
  565. croax But agree with you.
  566. croax Any UDP service without authentication would be vulnerable the same. Eg NTP ?
  567. croax Any UDP service without authentication would be vulnerable the same. Eg NTP, DNS, ... ?
  568. moparisthebest yep
  569. moparisthebest any that responds without authentication anyway, for example wireguard is not susceptible
  570. patasca has left
  571. patasca has joined
  572. patasca has left
  573. patasca has joined
  574. Bjarkan has joined
  575. patasca has left
  576. patasca has joined
  577. ibikk has left
  578. Bjarkan has left
  579. kryptos has left
  580. alien has left
  581. neox has joined
  582. alien has joined
  583. Bjarkan has joined
  584. ibikk has joined
  585. Bjarkan has left
  586. jonas’ croax, NTP and DNS are prime examples of such offenders, yes
  587. patasca has left
  588. jonas’ moparisthebest, do you know how QUIC does things?
  589. schäfchen726 has left
  590. moparisthebest jonas’: https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-8.1
  591. schäfchen726 has joined
  592. jl4 has left
  593. moparisthebest So QUIC seems to think 3x amplification is ok...
  594. mjk has joined
  595. MattJ You should run it on a different port :)
  596. moparisthebest That is finally supported, though you can just ask DNS where that is
  597. alberto has joined
  598. perflyst has joined
  599. kryptos has joined
  600. balabol.im has left
  601. patasca has joined
  602. kryptos has left
  603. balabol.im has joined
  604. jl4 has joined
  605. patasca has left
  606. patasca has joined
  607. Bjarkan has joined
  608. Bjarkan has left
  609. patasca has left
  610. patasca has joined
  611. ross has left
  612. ross has joined
  613. ross has left
  614. ross has joined
  615. abslimit has left
  616. abslimit has joined
  617. jl4 has left
  618. patasca has left
  619. balabol.im has left
  620. iramaro has left
  621. iramaro has joined
  622. balabol.im has joined
  623. abidal3 has joined
  624. perflyst has left
  625. Bjarkan has joined
  626. Ge0rG has left
  627. Ge0rG has joined
  628. patasca has joined
  629. mjk has left
  630. Bjarkan has left
  631. mjk has joined
  632. patasca has left
  633. Bjarkan has joined
  634. sol has left
  635. Bjarkan has left
  636. iramaro has left
  637. iramaro has joined
  638. alberto has left
  639. patasca has joined
  640. Steven Roose has left
  641. octagon has left
  642. abidal3 has left
  643. abidal3 has joined
  644. balabol.im has left
  645. Ge0rG has left
  646. Ge0rG has joined
  647. balabol.im has joined
  648. patasca has left
  649. perflyst has joined
  650. stpeter has left
  651. patasca has joined
  652. mathieui has left
  653. Bjarkan has joined
  654. sol has joined
  655. alberto has joined
  656. Bjarkan has left
  657. mathieui has joined
  658. alacer has left
  659. stpeter has joined
  660. patasca has left
  661. patasca has joined
  662. octagon has joined
  663. alien has left
  664. perflyst has left
  665. Bjarkan has joined
  666. patasca has left
  667. patasca has joined
  668. stpeter has left
  669. kryptos has joined
  670. alacer has joined
  671. mimi89999 has left
  672. dinosaurdynasty has left
  673. sonny has left
  674. sonny has joined
  675. ricky has left
  676. patasca has left
  677. patasca has joined
  678. mimi89999 has joined
  679. dinosaurdynasty has joined
  680. abidal3 has left
  681. stpeter has joined
  682. ricky has joined
  683. alacer has left
  684. Steven Roose has joined
  685. jl4 has joined
  686. patasca has left
  687. patasca has joined
  688. southerntofu has left
  689. Bjarkan has left
  690. x187x has joined
  691. Bjarkan has joined
  692. perflyst has joined
  693. abidal3 has joined
  694. perflyst has left
  695. jl4 has left
  696. mjk has left
  697. patasca has left
  698. patasca has joined
  699. mjk has joined
  700. perflyst has joined
  701. neox has left
  702. mjk has left
  703. sonny has left
  704. sonny has joined
  705. shaarad has left
  706. Bjarkan has left
  707. mjk has joined
  708. Bjarkan has joined
  709. patasca has left
  710. kryptos has left
  711. Huxx has left
  712. Samir Allioui has left
  713. octagon has left
  714. octagon has joined
  715. lorddavidiii has left
  716. Bjarkan has left
  717. jl4 has joined
  718. jl4 has left
  719. jl4 has joined
  720. Ge0rG has left
  721. mjk has left
  722. jl4 has left
  723. jl4 has joined
  724. jl4 has left
  725. jl4 has joined
  726. jl4 has left
  727. jl4 has joined
  728. jl4 has left
  729. jl4 has joined
  730. kryptos has joined
  731. patasca has joined
  732. jl4 has left
  733. jl4 has joined
  734. Ge0rG has joined
  735. jl4 has left
  736. jl4 has joined
  737. tom has joined
  738. abidal3 has left
  739. abidal3 has joined
  740. mjk has joined
  741. Ivan A. has left
  742. Ivan A. has joined
  743. jl4 has left
  744. jl4 has joined
  745. jl4 has left
  746. jl4 has joined
  747. pod has left
  748. patasca has left
  749. perflyst has left
  750. mjk has left
  751. alacer has joined
  752. Samir Allioui has joined
  753. mjk has joined
  754. Bjarkan has joined
  755. jl4 has left
  756. ibikk has left
  757. mjk has left
  758. mjk has joined
  759. mss_cyclist has left
  760. menel has left
  761. Bjarkan has left
  762. rom1dep has joined
  763. marc has left
  764. patasca has joined
  765. thndrbvr has left
  766. thndrbvr has joined
  767. Bjarkan has joined
  768. abslimit has left
  769. mjk has left
  770. abslimit has joined
  771. x187x has left
  772. Bjarkan has left
  773. ricky has left
  774. moparisthebest has left
  775. patasca has left
  776. Douglas Terabyte has left
  777. nickomemo has left
  778. Ivan A. has left
  779. Ivan A. has joined
  780. Douglas Terabyte has joined
  781. moparisthebest has joined
  782. Mel has left
  783. Mel has joined
  784. abidal3 has left
  785. kousu has left
  786. mjk has joined
  787. patasca has joined
  788. patasca has left
  789. patasca has joined
  790. ricky has joined
  791. patasca has left
  792. Ge0rG has left
  793. patasca has joined
  794. Ge0rG has joined
  795. balabol.im has left
  796. kryptos has left
  797. mjk has left
  798. kousu has joined
  799. balabol.im has joined
  800. mjk has joined
  801. x187x has joined
  802. patasca has left
  803. patasca has joined
  804. schäfchen726 has left
  805. patasca has left
  806. patasca has joined
  807. stpeter has left
  808. Lyn has left
  809. Lyn has joined
  810. mjk has left
  811. insanity has left
  812. alberto has left
  813. patasca has left
  814. patasca has joined
  815. mjk has joined
  816. patasca has left
  817. patasca has joined
  818. insanity has joined
  819. schäfchen726 has joined
  820. patasca has left
  821. patasca has joined
  822. ricky has left
  823. ricky has joined
  824. madmalkav has left
  825. Bjarkan has joined
  826. jayteeuk has left
  827. jayteeuk has joined
  828. kousu has left
  829. patasca has left
  830. insanity has left
  831. Bjarkan has left
  832. schäfchen726 has left
  833. insanity has joined
  834. kryptos has joined
  835. patasca has joined
  836. patasca has left
  837. patasca has joined
  838. Mel has left
  839. Mel has joined
  840. kryptos has left
  841. patasca has left
  842. kryptos has joined