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
Thanks for the reply Bill
But you coma back again a software solution to a networking problem.
People need to see the whole possibility of the road a packet can take. Your exemple is possible only if you view the world as a point to point thing. But that is not the situation we live in. Of course as a user point of view they connect to a network and they enter an IP or domain name and the connection is done. what is between the 2 machine is totally uninportant. That is IF the network is working as it should and no one made some rules to prevent x or y type of data to pass.
Now let see the world as the network carying people. We will have parts of our global high speed network that will at first be part "internet" (pop) and part RF. Most user will conect to the POP to have access to the network. But as RF links will develop people will connect to the net with RF. In some country they will use the ISM band without any care about encryption cause ISM can be encrypted. Now let say a part of the RF net drop to 900 MHZ hm band cause there is a large gap that a 5.8GHZ cannot pass for what ever reason. Encryption wont do. How do we manage to rules that kind of stuff? Cause some country will not even use ham band at all, some part of the US already do that. Hamnet is doing that. But on the other side of the border a group will want to connect to the 44net from let say Germany to Poland, and after connecting a short 10 KM link they go on a ham band and they start repeating the signal from germany that do transport some encryption. WHere do we draw the lines?
What we need to do is make 2 sand box to have people playing with encryption and the whole world. And another sand box where people cannot encrypt anything and that box need to be totally unavailable to the rest of the ordinary internet user for 2 reason, First we need to be sure the signal come from a ham and that network will be so unprotected that we need to make sure the rest of the world even see anything on it as it would be an easy pray.
That way we "fix" the encryption problem without breaking any route. We dont filter anything BUT at the end user level. That is the normal way a network works.
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Bill Buhler via 44Net 44net@mailman.ampr.org Envoyé : 18 août 2021 09:49 À : 44net@mailman.ampr.org Cc : Bill Buhler Objet : Re: [44net] 44Net Digest, Vol 10, Issue 112
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
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Bill Buhler -
pete M