From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1609185594; bh=YUm2keAuLLXsRKCb1qHRpLkH7MljpFUR7IsydMdZcn0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ja2UpItGJUirGlHmnXU4ihrxDzmZ7UGrggYC/ARgfrJUGXIpXlLboLN9JfoKmOUwf To3TChlilCyn7B/GMVS64UoxGVRK7qhOIEc2jaCOhk39lvfRZzacGxgTljZX5Hao/G N9W8y7FsBjjjjgDkB+gagZ6+ruyzjEiwEQqbfZwMBK5A+q+EHL6w0r2EHjZ/3jt69m 62qjRKlqJ1k17cyL/DSAZ2SSErjr9wIOT7m2f63pOd16wnOtfa19mQeUTVRruEJkJU KrmPfVi+Rs1/Ny8Cqh+n5uuA1rH8w/JEqA5HwSoymM0GLRNn5+FdefXrDY3CI2Xh3U 3yUP2YVC/zpjg== To: Juliusz Chroboczek In-Reply-To: <87a6tx7olm.wl-jch@irif.fr> References: <1082cfcde178ddb72b51bcd03ee6770a@kn1ght.org> <87zh1zt6ip.wl-jch@irif.fr> <87y2hjt5fx.wl-jch@irif.fr> <87y2hjxa64.fsf@toke.dk> <87r1nau8v0.wl-jch@irif.fr> <87sg7qyaj2.fsf@toke.dk> <87a6tx7olm.wl-jch@irif.fr> Date: Mon, 28 Dec 2020 20:59:53 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8735zpya4m.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 37Y5EERFTLUAKED3776AYHIYL467SGSO X-Message-ID-Hash: 37Y5EERFTLUAKED3776AYHIYL467SGSO X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Cell , galene@lists.galene.org X-Mailman-Version: 3.3.2 Precedence: list Subject: [Galene] Re: coturn config List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Juliusz Chroboczek writes: >>> In Gal=C3=A8ne, authentication only happens when you join a group, so t= hat >>> would mean communicating the ICE configuration together with the "joine= d" >>> message that carries the client's permissions. > >> Yup, that makes sense! > > I've made the protocol change in the master branch, and made it so the > TURN configuration can change at any time and Gal=C3=A8ne will notice wit= hin > 5 minutes at most. We're not changing the configuration of previously > joined clients yet, but the protocol could support it quite easily. > > (We'd simply need to send a "type=3Djoined, kind=3Dchange" message to all= the > clients when we detect a change, and the clients will switch to the new > TURN credentials at the next ICE restart.) > >> I look forward to your implementation :) > > I've put an implementation into the branch "tokes-folly". It's completely > untested, please let me know if it works. > > I'm a little hesitant to merge it, since it is just as easily done by > writing a five-line Python or Lua script that fetches the new > configuration and dumps it into Gal=C3=A8nes data directory. Heh, I see what you mean. And indeed when looking at this I failed to actually get coturn to return anything via any REST interface, so I went and looked at what Nextcloud Talk is actually doing... ...And it turns out that I completely misunderstood how this is supposed to work: there's not supposed to be any communication between the WebRTC server and Coturn. Rather, there's a configured shared secret that the WebRTC server can use to generate as many ephemeral credentials as it wants. In Nextcloud Talk, the relevant code is just this: $timestamp =3D $this->timeFactory->getTime() + 86400; $rnd =3D $this->secureRandom->generate(16); $username =3D $timestamp . ':' . $rnd; $password =3D base64_encode(hash_hmac('sha1', $username, $se= rver['secret'], true)); where $server['secret'] is the value configured as 'static-auth-secret' in coturn. The resulting username and password is then communicated to the client. I didn't dig any further, so not sure if a separate set of credentials is generated for every user in a call; but I suppose they could be? The actual username could also be used in place of (or together with) the random value above? Not sure what makes the most sense for Galene. TBH I'm less concerned about the security aspects of this, and more about compatibility with other software (i.e., being able to use static-auth-secret at all). My apologies for the misunderstanding! Hope the above makes (more) sense :) -Toke