18 Aug
2021
18 Aug
'21
8:49 a.m.
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