-
Notifications
You must be signed in to change notification settings - Fork 326
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
Comments
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.
Solved by #267 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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/
The text was updated successfully, but these errors were encountered: