Can any one do Middle man attack in a Wifi network with WPA2 PSK security
I mean for example.
There is a free wifi network. where i connected 2 devices and i am transfering data between those 2 devices through that network with sockets. with out any encryption like SSL.
Is this data is encrypted with WPA2 PSK.
If it is,can anyone in network make sense of it.
If it's also possible can he transmit data as my device
And if its not Encrypted by WPA2 then, anyone outside the network also an make the middle-man attack right?
As far as i searched it seems WPA2 does some encryption on data. But some others are saying the reason Https Protocol exist because of these kind of issues in wifi. So it seems to be a complicated question. so i came here.
Related
I tried to configure a bonding pincode on my Movesense 2.0.0 sensor and I was expecting being asked for it when trying to connect to the sensor with MDS or apps like nRF Connect.
But what I got looks identical to Just Works mode, and the bonding PIN is being asked only if I try to pair the device through system's Bluetooth settings. Does it happen because in the first case there's only connection and no pairing? What are the pros/use cases for having the sensor paired at system-level?
I'm looking for a way to prevent unauthorized access (connections, API requests) to sensors from devices not knowing a secret access code (like a PIN). Do BLE/Movesense provide such a mechanism?
Neither Bluetooth nor Movesense offer a way to securely "log in with a secret password". The passkey bonding mechanism that is present in Bluetooth, is only designed with the purpose of avoiding man in the middle attacks, and the passkey must be random everytime since the protocol reveals the key after each attempt. A static passkey which some people use is not allowed per the specification. It might keep away your grandmother from accessing the device, but is not secure at all at a protocol level.
If you bond the device at a system level, the further communication will be secure (encrypted and authenticated) and will for example prevent spoofing attacks. It will also result in quicker device connection setup since GATT caching can be used.
You are not saying what "system" you are using so this is just a general answer.
I think I have a fundamental misunderstanding of how networking and peer-to-peer applications work, I would be really appreciative if someone could help clear things up for me.
I am designing a small peer-to-peer file sharing application, and it seems like I can't connect to a device on another network without forwarding a port from the router to that device. This seems rather tedious; if everyone using the application has to forward a port to their device it would make the application unpractical. Is there some way that p2p apps communicate with each other directly, or are p2p applications actually just a set of server and client applications working together to form a network?
In other words, do I need to forward a port on one machine and use it as a server initially, then as the network grows larger just hope that others will do the same? Or is there something I don't know / don't understand about how p2p communication works?
I want to connect multiple devices through socket without any server implementation.I will use that only for getting the IP addresses of the devices that will register.
There are two major problems to peer-to-peer communications: discovery, and reachability.
First, you need to know the IP address of the other peers to connect to them. Once you're connected to a mesh of peers, they can all keep each other updated on the state of the network, suggesting better peers to each other, passing around notifications of new peers who've joined and left, etc. But you have to design and implement a mechanism for trading that information. More importantly, you need to jumpstart things in some way, because when a new peer starts up, it's in a mesh of just itself, and it has no information to give itself.
One possibility is to have a handful of well-known "superpeers" (that you run) that are always connected, and bake their addresses into the app. Or you can have "introduction servers" instead of peers, serving much the same function. Or you can have some external way of trading addresses (the simplest is that users trade them on a web forum or an IRC channel or in person and type them in manually), which can be automated to various degrees. There are also shortcuts that can help—Bonjour can get other peers onto the mesh as long as one peer on the LAN is already there; GameCenter/GameKit can be used as an automated external trading network; etc.
Once you've solved the discovery problem, you still have the reachability problem. Most iOS devices usually don't have publicly-accessible IP addresses; instead, they're behind routers that do Network Address Translation, whether they be a home WiFi router or a cell carrier's 3G network. This means you need some way to do NAT Hole Punching to get two iPhones talking to each other. Somebody who knows both the public address and the internal address of each device can arrange for them to set up a connection to each other. You can have either normal peers do this (although that makes the jumpstart problem even bigger) or have your superpeers/introduction servers/etc. do it.
If you want to build all of this yourself, you probably want to look at other implementations. BitTorrent (including trackers and DHT) is well-understood and documented at a continuum of levels ranging from "lies-to-children" for curious end users to detailed protocol specs and open source implementations. And then look at some other P2P networks, because BitTorrent is not perfect, and doesn't try to do everything that everyone's come up with.
You can use GameKit. It has the matchmaking api that can help you.
It can be used for non game apps.
I've been working on something similar and it's a giant pain in the ass. There are 3 considerations: 1) Reachability 2) Discovery 3) The connection itself.
1) Don't even consider using 3g/4g, it just won't work well for keeping an open socket connection.
2) I'd use some sort of broker service between the two on the internet to connect the two. For discovery, you can just list what devices are available on the service.
3) For the connection, I find the IOS socket libraries to be rather painful to use, but if you go down to the BSD socket level it's not as bad. I think it'd be very interesting to use zmq sockets; that might simplify writing the broker service.
You can't. If the device is all online with wifi, it maybe possible and rely on the router setting just like pc connect. If some device is connected with 3g or gprs protocal , they may have no ip address at all.
I have try to make chat application with socket programing and I am using Chatty source code and its working perfect on same network. But not work for different network.
Is chatty work for different network iPhone?
I have tried chatty for different network in iPhone but no success.
Any idea about chatty for different network for iPhone?
From looking at the source code for Chatty, it seems that it just uses an IP and port number to connect to a different device, and that's the reason why you can't connect when users are in a different network. Being able to connect or not will depend a lot on the network configuration you both of your devices have.
For example: it works if you're in the same wifi, because there's no firewall between the devices, and the IP is reachable (192.168.x.x, for example). If you take one of the phones to a 3G network, it won't be able to reach the other one in the wifi, but the one in the wifi might still be able to reach the one on the 3G, depending on your career and port number, and if the network stack is on in the phone. So, conclusion is: this will be highly unreliable.
Usually, for this kind of communication, apps rely on a third party, so both of your phones connect first to a webserver, that is always available on the internet, and the web server sends the messages to each of the apps. This also solves the problem of one app going off the network (when you take an elevator, for example).
i am developing an app for iphone, it is a client side application. and i found the 3g network is very slow, should I change the server host to a mobile network friendly host?
any suggestions?
Mobile networks are typically high-latency networks, and if you (or your users) are in a bad area, then yeah the network could just suck.
However, its not clear what exactly a "mobile network friendly host" is - I doubt such a thing exists. A bad connection on the client side is just that - you aren't going to be able to overcome that with a server-side change.