I'm a little confused on how captive portal authentication works. In some implementations, after a user is authenticated with a login page, their IP and MAC address are whitelisted and allowed to connect through the gateway. Obviously this has the problem of people spoofing MAC addresses to gain access. If the portal sets up a session between itself and the client, does that mean that every piece of traffic that the client requests from the internet must go through the portal's server?
Generally, security in a captive portal is not considered particularly important. However, there are solutions that lock a MAC to the first port to use it and disallow the use of that MAC on any additional port. Similar techniques can be used wirelessly, where the AP will refuse to pair with an additional client using the same MAC address as an existing client. This requires enterprise authentication where a unique key is negotiated for each attached device.
It's not clear to me what you mean by "the portal's server". But generally, once a MAC address is authorized and the wired port is configured or the wireless connection is established, nothing further needs to be done by the portal. The traffic for authenticated connections is just routed/NATted normally.
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
I have a problem with insecure SSL certificates. My proyect consist on two parts:
ESP32 iot device with a https server
VUE2 + Vuetify PWA web app deployed to firebase hosting.
Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net.
The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials.
The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem...
Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...
How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...
Thanks everyone!!
It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:
Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.
Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.
Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.
Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.
However, I would really recommend not doing this. You'll have three major issues to contend with:
The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.
The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.
If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.
Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.
An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.
Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.
I have gone through RFC 5766 which explains TURN protocol in detail. However, I have some fundamental questions that I am not able to figure after downloading and installing COTURN the opensource TURN server.
What is a client for a TURN server? Is it the first browser that initiates a WebRTC call? TURN servers create an allocation for the client, targeted for a specific peer. Now in WebRTC, we talk about peer to peer communication. In the RFC it talks about client-server-peer communication. All requests/responses between the client and the server are TURN-driven while those between the peer and the TURN server are just UDP data messages relayed to/from the client.
My second question is more specific to COTURN. What is the "value" field in "turn_secret" table and where/when is it used? Does the "credential" property of iceservers correspond to hmackey in the turnusers_lt table by using HMAC over (credentials, realm and username)? Where does the "value" field of "turn_secret" table figure in all this?
tl;dr: TURN secret is used to restrict the leakage of TURN credentials, it is part of TURN authentication using REST api(doc)
from coturn docs:
In WebRTC, the browser obtains the TURN connection information from the web server. This information is a secure information - because it contains the necessary TURN credentials. As these credentials are transmitted over the public networks, we have a potential security problem.
If we have to transmit a valuable information over the public network, then this information has to have a limited lifetime. Then the guy who obtains this information without permission will be able to perform only limited damage.
This is how the idea of time-limited TURN credentials appeared. This security mechanism is based upon the long-term credentials mechanism. The main idea is that the web server provides the credentials to the client, but those credentials can be used only limited time by an application that has to create a TURN server connection.
you can take a look at this answer TURN secret usage example.
I have an API controller in a Rails 3 application that is used to communicate with other applications on the same machine and remote servers.
Remote servers use HTTP basic authentication to gain access to the API. Requests originating from the same server should be allowed by default.
Is is safe to trust request.local? that requests are really coming from the same machine? I am thinking of IP spoofing etc.
Btw "protect_from_forgery" is deactivated in the API controller.
For a moderate level of security, yes. This requires that you trust all processes that may run on the same system by any user. It also requires the servers TCP/IP stack, routes, and network filters/internal firewall be configured in a sane way that doesn't allow packets originating from outside the server to be masqueraded as a local IP address (specifically 127.0.0.1). And it assumes that the LOCALHOST constant in Rails be set to 127.0.0.1.
By the way, protect_from_forgery protects from cross-site request forgery (CSRF) and does not and cannot protect against IP address spoofing. And ensuring that a request is coming from an authorized IP and user does not protect against CSRF.
i'm trying to improve the security of our network by disabling our legacy WPA wifi aps. All account are on the network so computers needs network connection to authenticate users.we have now only EAP-MSCHAP V2 scure Wifi (user/password auth), so laptop are not on network when user is not logged in... Our policy is to avoid storing auth information on the computer (pass). So my question is : is there a way to authenticate user on the EAP wifi and then on the domain ?
Laptop are Macs (10.6 to 10.8) and Windows (XP/7).
Thanking by advance!
Cheers
what you would like to achieve is usually done by using 802.1X: http://en.wikipedia.org/wiki/IEEE_802.1X.
A possible solution could look like this:
Each client/notebook (not the user) has a certificate from a common trsuted source (a PKI)
The client request a connection on your 802.1X Access Point who forwards the Request to a defined authentication service (usually a wireless controller and subsequently a radius server). This can be done by EAP protocol for example.
Depending on the authentication result, the client can connect.
In this scenario a certificate is used so that the client/notebook can connect before any windows login happened.
Hope this helps to get you started.