I was looking at the code here from xamarin training here and as I'm going through the code (for my own educational purposes), I noticed this line (line 42)
public async virtual Task Sync()
{
var connected = await Plugin.Connectivity.CrossConnectivity.Current.IsReachable("google.com");
if (connected == false)
return;
I could be wrong..but to me, it looks like the only purpose of it to test connectivity. Is there a better way to do this than hard-code google.com just to see if there is a connection? Is there a flag somewhere that one can test for that? What if google is down (ignore the tear in space-time continuum)?
If you are testing connectivity so that you can test that your Azure Mobile App is up, replace google.com with the URL of the service. It seems that is really want you want to be testing.
It's not uncommon. For instance, iOS and Mac will make a connection to http://www.apple.com/library/test/success.html or http://captive.apple.com/hotspot-detect.html or some other URL on behalf of the user when joining a Wi-Fi network to see if the network has Internet connectivity and also to detect captive portals. Microsoft and Android devices do something similar, just with a different known URL.
It's probably best to try and connect to a service you control, since in general if your app is useless if it can't make a connection to yourapp.com, it's best to make sure you can connect to yourapp.com.
Doing the test to see if google.com is available is a reasonable fallback to see if the device has 'connectivity', though.
Related
This has taken me about a year to understand and get to, but I am the limit of my capability so reaching out to a StackOverflow guru please...
I would like to, if possible, secure my network model. The model is as shown in the diagram. To explain:-
All the aspects I have control of, is within the green shaded area. I cannot change anything outside this.
I run a simple application web server which is the VPN IPsec/L2tpd client. Static IP.
My router is ISP provided. It receives a DHCP Dynamic IP from the ISP.
My Digital Ocean Virtual Private Server has a static IP. It runs an NGINX reverse proxy that channels traffic through the VPN tunnel. It also runs the IPsec/L2tpd server.
A IPsec/L2TPD VPN tunnel is established and working.
A working VPN tunnel.
A cellphone that runs an app that communicates with my application server app. My cellphone receives a dynamic IP from my Network Operator.
I have three IP camera feeds served by my application server. Not a great speed but watchable in real-time.
I cannot change my ISP, or bandwidth/download/upload speed.
I cannot install VPN clients on the cellphone and I may want to access my app server through another cellphone provided by work so cannot install apps on it but does have unfettered web access through a browser.
Everything is now working, can't believe I've done it !
Anyway, my question is:-
Is there any way to secure the network so that only traffic from my mobile reaches - or rather is accepted - by my application server.
I accept IPsec/L2tpd is not great, but it is fast and I use this because I have tried OpenVPN, SoftEther and key based OpenSwan. These are waaaay to slow. The camera feeds are unwatchable and update one frame about every 5 seconds.
So with the limitations above, what can I do, what is possible? Please may I respectfully ask that you refrain from suggestions and concerns requiring a change to that which I cannot control, i accept all critique but that is not what I need here. I am asking for advice on how to secure , that which I can influence. Thank you
I cannot install VPN clients on the cellphone and I may want to access
my app server through another cellphone provided by work so cannot
install apps on it but does have unfettered web access through a
browser.
Due to the limitation that at the end, even a phone where you are not allowed to change anything but use the web, i suggest to configure proxy authentication on the nginx reverse proxy. I don't have experience with setting this up with nginx in particular but that's what should do the trick according to the network architecture and description you provided.
An example configuration on how to configure nginx for basic / client certificate auth can be found at: https://www.cloudsavvyit.com/1355/how-to-setup-basic-http-authentication-on-nginx/
I've build a Web-App that is displayed in an Electron-App with Nativefier. That already works great, but now i need to send requests from the website to the local network to talk with some local devices which are (with it's ip-address) configured in the Web-App.
I had the idea to use the Electron-App as a "proxy" to the local network by using a javascript callback from the Website to the Electron-App (don't know if this is possible, just an idea), which then makes the local request because it's running on a computer in the same network.
The reason for this post is that i need ideas/tips to secure this and prevent allowing to talk to other than the desired Web-App (available under a certain domain) by developing something protective like checking or validating the Server, validating the request by sending it's hash back to the server or other methods.
So my questions are: is it generally a good idea to do something like this or is this a huge security problem and have anyone any tips to secure the communication and only allowing the communication to in the web-app configured devices in the local network?
Trying to create an action on Google that communicates with devices in my local network.
So my question is, is that even possible, to perform an operation directly through google home, without a need to have a webhook in a server somewhere??
and if so, and i will need to have a webhook, what is the best way to make the webhook communicate with my phone, other than push notifications.
If you want to control anything on your home network then you will have to run the fulfillment server in your house or let an external fulfillment server connect to something in your house. Either way you will need to poke a hole on your home firewall or use something like ngrok or bst proxy.
Then you will be in your home network and you can do your things on your local devices.
You should be more specific about the communication with your phone. What exactly are you trying to accomplish?
Building my own authentification system at the moment and stumbled upon one idea:
How do schools/universities etc can restrict pages to only be accessible while being on the School's Wifi? What's the technique behind it? Basically: How can I make some pages only accessible while being on a specific WiFi?
Thanks! :)
They build their own network using own server which is not public facing which means it is not accessible through internet.
To access that network, you need to be connected to their server directly or using VPN(virtual private network).
If you want to make some pages only accessible while being on specific wifi(router). You need to create one of your computers as server and create a local network and other machines can join your network using password you will provide them. Other machines which will be clients have to be connected to same wifi
They usually run on a server on the network behind a firewall so inaccessible from outside. I've built a few intranets for companies like this.
Clint.
Log-in to your router admin page and look for URL filters in setup options. Now, add the pages/sites you want to block.
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.