Thanks, MC_SEQUOIA for the explanation. My assumption was that HTTPS encrypts the messages between the client browser and server, so one cannot just eavesdrop on the messages back and forth to generate a map of how to intercept and change the messages. Of course, one would have to gain access to the private WiFi network created with the AP, protected by a 16 character password and MAC filter, first.
My security strategy was to put up multiple barriers to make it an annoying project for the nefarious types. Aslo, our launches are 2-4 hours long at most, and then the passwords change for the next launch, and no Internet connection. If someone is good enough to get through 3 randomly generated 16 character passwords and a MAC white list in 3 hours with a laptop within 300 feet of the launch site, he/she deserves the honor of launching all the rockets! Good idea to check the DHCP client list periodically during the launch. The AP provides that as well as a way to deny an unknown connected device, if needed. Mark On Fri, Dec 29, 2023 at 2:38 PM MC_Sequoia <mcsequ...@protonmail.com> wrote: > > > > "I want to set up some sort of secure connection between the cell phone > > > and the web site running on the Pi." > > > > > > This should be doable via a vpn client/server. A quick google search on > > > "raspberry pi cell phone vpn" returned this: > > > > > > Are you saying a VPN is needed along with the SSL, or as a replacement? > Why > > both, or why as a replacement? > > An SSL certificate enables a web site to use HTTPS and it also verifies > the website's domain authenticity through a certificate authority. This is > all more for end-user security and privacy. Self-signed certs are for > non-production enviros. > > This does provide end to end security for any and every connected device, > but with a VPN, you can restrict which ip addr(s) can connect only via the > vpn. But since, "It is not accessible to the Internet, as the AP is not > connected to the Internet this is all happening on a private ip network", > all of this is secure connection concern is irrelevant as no one outside of > the private ip net can access the launch web site. > > Yes, it's possible to spoof a mac address, forge ip packets, etc. And > curious tech savvy kids will be curious tech savvy kids, but you're talking > about a fairly serious amount of time, effort, knowledge, skill and tools > to pull this off. > > I'd suggest there are far more interesting internet things for those > curious tech savvy kids to hack & crack on and/or into. > > I walked away from a lucrative cybersecurity career a few decades ago > because my experience was that the whole industry was built on the idea of > scaring people to buy security products and services. Yes, there are very > real vulnerabilities, exploits, security concerns and bad actor > hacker/crackers but people fail to correctly asses the real risks, threats > and targets. > > If you setup a reasonably secure launch situation and some black hat > genius kid cracks it and launches the rocket on you, they gotta be close > enough to get onto the WiFi and not in mom's basement over the internet. > > You should also be able to monitor the devices in real time that are > connecting to the WiFi AP. If you're not familiar with this, either poke > around on the AP mmgmt. web site or look through the instruction manual for > mac table, ip table, arp table, connected devices, or the like. If you see > a new device that you don't know connect to the AP before the launch, don't > launch until you figure out what's going on and/or disconnect/block that > device. > > I hope that gives you a better understanding of this whole secure launch > concern and gives you some peace of mind. Cheers! >
