I don't know much about proxies, reverse-proxies, etc. Is there a way to use them to allow non-encrypted http traffic over AREDN to encrypted https sites on the public Internet like Facebook, Gmail, etc? Essentially, I'm looking for a "black box" at the perimeter of our AREDN network that can translate http traffic into https traffic. The goal being to comply with FCC rules on the AREDN network while still allowing access to public internet servers. I realize there are security/privacy issues, but for our purposes, that may be an acceptable tradeoff. We have been using VNC to remote control a computer on the perimeter, but that is cumbersome and slow.
Ideally, this solution would be something that we could run on a Raspberry Pi 4, and perhaps limit which public internet sites are accessible. If the basic concept is workable, please suggest specific software.
Thanks
Dave
Ideally, this solution would be something that we could run on a Raspberry Pi 4, and perhaps limit which public internet sites are accessible. If the basic concept is workable, please suggest specific software.
Thanks
Dave
I have tested this configuration: A "base station" connected to the internet and an AREDN node, with an Apache web proxy server running on the laptop, and a "remote station" with laptops running browsers configured to use the web proxy. The plus of this configuration is that the amount of routing configuration fiddling is minimal, and you can control what websites the laptops can get to with the Apache config file. The downside is that not all web browsers support web proxy servers anymore, particularly Android mobile devices, and you ae going to have to fiddle with configuring each of the client browsers.
A quicker, dirtier, and better workaround is to run a VNC server for each remote client on the base laptop, and let remote clients connect to them.
The best solution if all you need is a point to point connection is to just revert the devices to their factory software and use them as range extenders. My devices are TPLink CPE510s. AREDN software can't increase the transmit power of them so the range is the same either way. The advantages of the AREDN software over factory is the ability to use ham band channels, and mesh. The advantage of factory over AREDN is you can transmit whatever you want.
I'd be curios to know more about compatibility issues. You mention some browsers don't support proxy servers. Is that a problem limited to Android (and iOS?) based mobile devices? So far, we have just been using Windows laptops. Normally they are going to have at least a couple different browsers to chose from, if not three or four. But it isn't hard to imagine wanting to use tablets at some point, so good to know about any compatibility issues there.
Dave
I disagree with ruling out the VNC method just because of bandwidth consumption.
Before high speed connections were common at homes (we're talking early 2000's when a 1MB connection was about all you could get at home), I would often connect to a remote server via RDP or VNC if I needed to do any serious data movement (you know, important stuff like music from Napster). Those servers were connected to the Internet backbone with at least 10 MBps but more often 100 Mbps. I could transfer large amounts of data remotely and when I got to the office where the servers were physically housed, I would bust out my handy dandy Iomega 250 MB Disk Drive and sneaker transfer it all home. It operated just as well as me being physically in the same building as those servers on my very limited home cable Internet connection.
Yes, every time there's a change on a remote connection's display, information is exchanged. But it's not the entire screen. Only the changed frames are sent back. If you look at how web pages are built these days, they are HUGE compared to 20 years ago. Whenever you load up a high bandwidth website, you're gonna get all that stuff coming over the AREDN network. Services like Gmail are heavy on the content side even without any images - that's how they can have a fancy web interface.
The simplicity of connecting to a box (with encryption turned off via AREDN of course) which has a 2nd network card to connect to the Internet is way easier than trying to figure out some complicated reverse proxy encryption / decryption scheme. I don't see RDP or VNC as a huge bandwidth draws unless people are watching movies or playing video games via their remote connections.
Just my 2 cents.
Mark, KM6ZPO
I think kf6iiu's solution would be much much easier to pull off, but I'll take a stab. :)
The first trick is working around the client web browser wanting to request https connections. Forward proxy servers handle encrypted traffic differently -- it's mostly a pass-through affair. Since encryption starts at the browser, this would violate fcc's encryption rule. Also, since the proxy doesn't terminate the connection, I don't think the proxy can enforce things like a null cipher during the negotiation phase it would have with the destination server and most destination servers have that cipher disabled anyway. Of course you'd also have to deal with somehow configuring the client web browsers to use your proxy in the first place.
I think that leaves us with a reverse proxy. The way I would see this working would be to set up a reverse proxy at your node that would sit before the web service that comes with the node.
Lets say the node fqdn is callsign.local.mesh
If a web client attempted to connect to http://callsign.local.mesh, it would hit your reverse proxy, and you'd configure it to then connect to your local node's web service internally. That keeps your existing setup working the same.
However, if a web client attempted to connect to http://www.google.com.callsign.local.mesh, your reverse proxy could be configured to take that url apart and go to the destination that was appended to your fqdn.
But here's where I think things start to fall apart -- that initial request is going to go out and come back to the browser just fine, however that content is just the beginning -- each of the dependencies in that html still needs to be retrieved too -- images, javascript, css, etc -- your browser isn't going to know it needs to do that callsign append trick for those additional requests, so each will fail and the site won't properly load. The reverse proxy could attempt to re-write the html content to do this appending trick for you, however it's going to trip up on any client side code (javascript) that generates addresses on the fly. If you've ever used The Wayback Machine, you know what I'm talking about.
But lets say you somehow get past that hurdle -- say there's a browser plugin that waits until all the javascript has executed and then does the url translations. The next problem is how you'd deal with restricting to particular sites -- most sites don't host all of their own content -- images at yimg.com, or javascript at cloudfront, or stuff hosted through amazon load balancers. This would be a nightmare to get right for each permitted site, and you'll end up just opening vast areas of the internet just to get things working right.
In my mind, a further requirement is how to block all the advertising that pops up with almost every commercial site out there now.
I would think that firmly qualifies as commercial traffic...