I know p2p applications use hole punching for not symmetric NAT, but how Skype or Hamachi connect users with symmetric NAT?
First, the problem exists only if both users are behind symmetric NAT of if one of them has symmetric and the other port-restricted. In both cases is impossible to establish a peer-to-peer connection between them. But if one user is symmetric and the other full cone, then there is not a problem.
The solution with symmetric is to use an intermediarie machine called TURN that is a forwarder that receives packets from Alice and forward them to Bob and viceversa.
Skype uses supernodes (nodes with public IPs) as TURN nodes.
Related
I am thinking about a complicated chat application where two clients can connect to each other directly like in a p2p network. My idea complexity is both about network and the security (authentication).
NETWORK PART
As far as I have read on internet, p2p connection can be achieved by TCP HOLE PUNCHING. In most examples of Hole Punching, I have seen a middle server that helps clients pass their address to each other. Imagine that server goes down. I still want my clients to be able to find each other. A very crazy idea is for them (for example my application users as human not the code) to use any other communication channels to tell each other a code (which is generated from a data). I want this data to contain client {local ip, local port, public ip and public port} (which in all examples of TCP hole punching that I have seen, they were used).
Can this data be found by client itself? and is it enough? (Consider help of extra HTTP REQUESTS from client to find about his PUBLIC IP ADDRESS)
Also, are there any better ideas than using TCP Hole Punching? My clients are mostly behind NATS
AUTHENTICATION AND SECURITY PART
I am trying my best to rely less and less on a middle server for helps. My client applications can perform Diffie Hellman key exchange and encryption after their connection established. But as I want real users to use this application, I need some ways that clients can authenticate each other. I am not looking for this app to be used by wide range of users. So maybe they can actually see each other sometimes (in the real world) and transfer some sort of files with their bluetooth (or other file sharing systems in application layer) that can be their token or authentication token. This token may later be used to authenticate each other later when they want to establish connection in network. Well this is my only idea:
The problem here would be if Jack and Rose meet and they transfer their personal tokens, later Jack has Rose authentication token and can use it to pretend to be Rose when he is talking to Jim.
Unless this token is generated with same value for both of them and somehow means its token for only {Jack and Rose} communication, and token for {Jim and Rose} is different. (I mean its unique token for any conversation or pair of users)
Would there still be any risks? Can any sort of networking attacks or other tricks, break this?
You can refer to WhatsApp end-to-end encryption white paper
https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
I'm working on p2p application intended for LAN. Users are supposed to connect directly to each other without any server. At the moment application works on Linux, but I think about porting it on Windows and Android.
At the moment I simply establish unencrypted TCP connection, which is fine in early development stage. Later I'd like to use secure channels and here's my question - how can I establish secure connection (assuring confidence and authentication like TLS) in distributed, p2p solution for LAN? Is it even possible?
I cannot use TLS, because I will not have any central server working as certificate authority. Moreover my LAN have no internet connection. Anonymous TLS is partial solution (will it work on Android?).
Because users will be in the same LAN, I may assume they will be e.g. sitting next to. Therefore they may "physically" authenticate themselves and e.g. share key or part of key (PIN)?
Suppose there's a WPA2 hotspot with a few stations connected to it, and suppose I know the passphrase to connect to this hotspot. Will it be possible to decrypt everyone's communication by being completely passive? (i.e. just sniffing the packets with a wifi sniffer, and without connecting to the network or sending packets to the air).
For this matter, is there a difference between knowing the alphanumeric passphrase or the hexadecimal PSK?
The passphrase is used to generate a PSK via a password hashing function (PBKDF2) which you can easily do yourself, so knowing either the passphrase or the PSK is sufficient.
Between the AP and any particular station, the PSK is used to create a set of temporal keys that are actually used to encrypt frames.
If you capture the 4-way handshake which takes place after authentication/association between the AP and a station, then you will be able to deduce the temporal keys that were calculated for that session, and use these to decrypt unicast frames between the two, and broadcast frames from the AP.
Wireshark will do this for you if you capture the traffic complete with 4 way handshake, and enter the PSK/passphrase.
So to answer your question - yes, you can theoretically passively decrypt traffic if you know the PSK/passhprase without having to actively inject any extra frames, as long as you capture the initial 4-way handshake.
You only need to start injecting frames if you want to force a station to reauthenticate and perform its 4 way handshake, for example by spoofing a deauth.
As we all know, HTTPS is a way to protect against session hijacking.
Suppose this isn't an option for some application. Further suppose, users connect to the web-application using a strongly encrypted (WPA2) wifi network.
Fact: WPA2 protects against third parties, which didn't connect correctly to the wifi network.
But does WPA2 additionally protected each legitimate user against each other legitimate user? Does each legitimate user has a securely isolated channel to the wifi router?
Or does the wifi router works more like a hub: If the wifi router needs to send data to a wifi client, it broadcasts it to all clients - so that each client can read the data?
Speaking of web application programming: Do we need to use HTTPS in a
WPA2 protected wifi network to protect each wifi client against each
other wifi client?
In Wi-Fi, as the transmission medium is the air, every STA could intercept data from others STA. So, for this point, you can compare a Wi-Fi network to a hub.
In fact, the 802.11 stack take care of the PHY and the MAC/LLC layers.
Moreover, the WPA/WPA2 encryption is just here to protect foreign STA to read your Wi-Fi network frames.
It's very easy to test, use wireshark with two STAs on the same AP. You should be able to see frames form the other STA.
So if you want to protect a web application on a network which use Wi-Fi (and/or hub but not only), the use of HTTPS is strongly recommended.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.