Sorry, I just realized that I broke threading when I replied to you Pierre,
Now we really are getting to where there should be layer4 and Layer5 firewalls. Looking at this your proposal actually gives a false sense of security by segregating. Why do I say that? Modern web browsers will attempt to use https first if not explicitly told to. This was determined by their coders to be a good thing because it encourages privacy on the Internet, and few places of the world limit encryption. Of course most if not all amateur radio operators are prohibited from "obscuring the meaning" and therefore using encryption. We could walk down that rabbit hole, but lets not.
Instead lets walk down the handshaking rabbit hole. If I want to do SSL with a website I access it at port 443. If I don't I access it at port 80. Therefore if I do a L4 firewall rule at the gateway that feeds rf link that rejects any traffic to or from port 443 I've prevented the handshake and no encryption will follow.
SMTP can be a little trickier if I have enabled the libraries on my device for SSL, it's possible that it could issue a start tls command and negotiate a encrypted feed over what would normally be a unencrypted port.
There are two solutions to this. One is to install a application aware next generation firewall (Palo Alto makes the one I use), which looks inside the packets at the actual data flows and classifies what the actual protocol being used is rather than just the port (socket address) that is being passed. With a Palo Alto I can drop or reject all traffic that uses encrypted protocols. Once dropped I'm safe.
But many don't have these firewalls, and that's understandable. Instead, as the licensed radio operator, who knows the rules, they should learn how to disable the encrypted protocols running on their devices that will be problematic for these reasons.
There is no universal solution, because if I just say "oh this network is unencrypted" doesn't mean that if I have setup a web server with a ssl port that someone else on the network won't access it over chrome and accidentally end up with a encrypted feed.
Being on the network is only the first step, administrating our devices to comply with the rules is a ongoing and important thing.
Fortunately, most devices either have limited packet filtering built in, or can have features like SSL/TLS disabled in their settings. Which makes this a moot point.
For my RF devices I make sure that their backhaul link blocks known points of encryption. Because that is the purpose of a firewall, and proper network stewardship.
Just like I filter Bogons and known bad actors at the edge of my network connections.
Sorry for the novel, but I believe in trying for a universal solution, many are missing why the solution won't cure the problems.
Best regards,
Bill Buhler - AF7SJ
On 8/17/2021 12:30 PM, pete M wrote:
Bill, yes making rules like you just told will get rid of all the traffic that is not 44.
But it does not fix some issue that ham will have with the normal ham to the world exchange of data.
There are 2 use case that we seen. One being ham talking to ham and the world and earing from ham and the world.
The second use case is ham talking to ham, end ham earing from ham only.
In the explanation you gave this would fit only the first use case and the local guys would firewall what he want or not.
But when we come to the ham to ham only use case we fall short. On many network we cannot allow to have encryption on RF. Now let's say someone put a web site on a 44 address and enable https. The ham on RF want to connect to it. He open his browser and he is now actively passing encrypted data over the air.
What will the 44.128/10 segment will provide is to make sure that everyone on that segment won't encrypt anything and won't put someone else into a bad situation
Pierre VE2PF