[Feature request] Auth and HTTPS to prevent misuse on peer discovery affecting data provider and monitor

[ametial]

Peer discovery on 3000 can be exploitable if a firewall not properly configured.

Tested on a test machine:

nmap -p3000 -Pn ip5b135217.dynamic.kabel-deutschland.de
Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-06 12:08 CET
Nmap scan report for ip5b135217.dynamic.kabel-deutschland.de (91.61.13.22)
Host is up (0.0028s latency).

PORT     STATE SERVICE
3000/tcp open  ppp

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

This exposes data provider's peerId in the wild.

Is it possible to implement SSL encryption at least locally on the docker container and maybe land on a login prompt on the browser rather than directly on the peer discovery?

[krhougs]

The 3000 port is exposed by the monitor which is listened on 0.0.0.0 by default.

pRB is designed to run in a managed network where the pRB setup is connected within a LAN instead of connected to the internet directly. This makes it safe for components of pRB to use mDNS to discover each other by default within the connected broadcast range.

If you need HTTPS and Basic Auth for the monitor, consider wrapping it with a reverse proxy like Nginx and Caddy.

[ametial]

Thanks for the input @krhougs!

I will try to set up a test environment to play around. Indeed, it was more of a "feature request" rather than an issue. So, i tagged it.

After further research and tests, i realized that this behavior is only relevant when independent port forwarding is configured which requires an explicit user intervention on a home router (behind the one set by ISP, which will anyway filter incoming traffic to the NAT IP on port 3000).

Anyway, i will try to play with reverse proxy on a dummy machine.
May I ask you if you can share any considerations or links that you might find useful in this use case?

if it turns succesfull, I will create a wiki on the forum.phala.network for whom is interested.