Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PermissionHandler to ServerConfig #134

Closed
Sean-Der opened this issue Apr 7, 2020 · 1 comment
Closed

Add PermissionHandler to ServerConfig #134

Sean-Der opened this issue Apr 7, 2020 · 1 comment

Comments

@Sean-Der
Copy link
Member

Sean-Der commented Apr 7, 2020

Right now users have no way to filter/log what permissions are being created. An attacker could be using the TURN server as a bastion box into NAT.

https://www.rtcsec.com/2020/04/01-slack-webrtc-turn-compromise/

rg0now added a commit to l7mp/turn that referenced this issue Jan 18, 2023
Another attempt to address pion#134, see an earlier attempt in pion#222. pion#222
introduces the DeniedPeerRange stanza into the ServerConfig to
implement peer address blacklisting. This approach has a couple of
issues: (1) it implements only peer blacklists, but does not allow
whiletelisting or filtering based on DNS, etc.;(2) it handles only the
ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.
rg0now added a commit to l7mp/turn that referenced this issue Jan 18, 2023
Another attempt to address pion#134, see an earlier attempt in
pion#222. pion#222 introduces the DeniedPeerRange stanza into the
ServerConfig to implement peer address blacklisting. This approach has
a couple of issues: (1) it implements only peer blacklists, but does
not allow whiletelisting or filtering based on DNS, etc.;(2) it handles
only the ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.
stv0g pushed a commit that referenced this issue Jan 18, 2023
Another attempt to address #134, see an earlier attempt in
#222. #222 introduces the DeniedPeerRange stanza into the
ServerConfig to implement peer address blacklisting. This approach has
a couple of issues: (1) it implements only peer blacklists, but does
not allow whiletelisting or filtering based on DNS, etc.;(2) it handles
only the ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.
@stv0g
Copy link
Member

stv0g commented Jan 18, 2023

Solved by #267

@stv0g stv0g closed this as completed Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants