Hey guys, can you help me write a script that, when a device makes a request using my OpenWrt router, attaches a custom header containing the MAC address of the device? I need the script to handle both HTTP and HTTPS requests. If you have any other ideas, I'm open to suggestions, but the main requirement is that the MAC address of the requesting device must be attached to the request.
I've read about achieving this using HAProxy and TinyProxy, but handling HTTPS requests is quite challenging. One approach that worked for me was writing a script that retrieved the MAC address of the device. Then, when someone logged into my website through my router, I would invoke the script using Axios to get the MAC address, attach it to the request, and send it to my server.
However, the issue with this method is that browsers—specifically Chrome—do not allow my website to be SSL-encrypted with a public key while making requests to a URL using a self-signed certificate.
I modified my wordings with ai to make it easier to understand what am trying to achieve. I appreciate any help thanks
I tried this already, i generated an ssl certificate using acme and pointed it to by subdomain something.example.com, then editted the subdomaims records to point to 192.168.8.1, but chrome is smarter than that, it still blocked my requests
I think you meant generate an ssl certificate for my router, but the best you can do with a router is a self-signed certificate, and chrome blocked that too, that's why i tried to do it with a sub-domain. Or is there something i am missing can you expand please
My goal is not to hack headers, my goal is to get the mac address to my server so that i can automate blocking and unblocking of devices, thats it, it doesn't have to be the header approach.
I think what you are asking is how to make sure that only clients which you have approved will be able to interact with your server.
A MAC address is not a strong way to identify a client for authorization purposes since it is too short to be un-guessable, and exposed publicly in contexts other than authorization on your server. For example, anyone on the local LAN can use ARP determine other client MACs and impersonate the real client. Also MAC addresses only automatically propagate around the local LAN (layer 2). In order to use one to identify a remote client over a layer 3 connection, the client would have to voluntarily send it.
HTTPS client certificates are a standard, but it is seldom implemented in the real world and browser writers have their own opinions about security. Lacking a consistent standard it is better to avoid trying to use them.
Typically instead, "API keys" are used which are simply medium sized (128-256 bit) random numbers which are generated by the service then pre-shared through a secure out of band channel. A sufficiently large crypto-grade random number will be globally unique as well as un-guessable.
Another approach is to wrap the whole system in a VPN so that only client machines which have authenticated on the VPN will be able to reach your server and interact with it. The service itself can then be relatively or completely insecure.
Usually you keep long term cookie and add 2FA like google authenticator to login process. Easier for mobile operator that can figure out your source imei/imsi and send you SMS with random tag.
