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)?
Related
I need informations about security risks and proof of concepts to work with an local client.
In my option, a user will install two components:
The game client
The client launcher
The launcher is running as an background process all the time. The launcher provides an WebSocket server.
The user will open my website to start the game (with game-server lists and other settings). The Website connects to the game launcher to handle all actions (change configuration, start the game executable)..
Problem:
How realize the communication with the website and the game launcher? Okay, Websockets, yes. But browsers forbid to connect to localhost/127.0.0.1 by security reason.
An fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
Another idea was to provide an NPAPI-Plugin for the browser. But it seems, that the NPAPI is deprecated and useless for the future.
Whats the best practice to communicate between webpages and local installed software?
But browsers forbid to connect to localhost/127.0.0.1 by security reason
This isn't true. Browsers allow you to connect to localhost / 127.0.0.1. I do it all the time on my machine.
The issue is that TLS (wss://localhost, not ws://localhost) requires a certificate and browsers forbid mixed content (you can't have an https website load non-encrypted resources).
fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
As part of your game installer you could create a hosts file entry with a certificate for mygame.localhost (possibly using a local script) and then ask the player to authorize the installation of the certificate using their password. This way your certificate won't be revoked... but you are right that this his suboptimal.
EDIT: also, please note that the domain name must be at the end, not at the beginning (i.e., game.localhost and not localhost.game).
Whats the best practice to communicate between webpages and local installed software?
Generally speaking, if your game is installed on the local machine, there's no need to encrypt the communication between the local browser and the local machine.
You can easily write your local server to accept only connections from the local machine (or, at worst, if need be, accept connections from the local area network - though this adds security risks).
Your webpage and WebSocket data can be sent "in the clear" (ws:// and http://) between the local server and the browser since they are both on the same machine - this way you don't need a browser. The local server would initiate (as a client) any encrypted connection it needs when communicating with an external service (was:// / https://).
EDIT (from the comments):
There are the only 2 solutions I know of:
Installing a self-signed certificate; or
Using http instead of https and having the server handle outside traffic as if it were a client (so all traffic going outside is encrypted).
If I have a router that has a vulnerability that allows an attacker to gain full control it, does using a VPN on the network with the said router prevent an attacker from being able to snoop on the connection?
In other words, does using a VPN secure the connection from a device to a router on the same network? And would a VPS make a difference in this scenario?
No, the whole point of a secure VPN is that the transport doesn't have to be trusted. Obviously a VPN that is not actually secure (is incorrectly implemented, has a design flaw) will not live up to the expectations of a secure VPN. But the whole point of a VPN is to not trust the transport.
Not sure it is the right place to ask this question but still, I'll answer here.
A VPN establishes a secure tunnel between two ends. What's in between does not matter as soon as the VPN was correctly established and the technology used is secured and "flawless".
The only exception (that comes to mind) is if one of the two ends is compromised. Examples:
Your home network has a compromised router which advertises to your machine the wrong DNS hosts (dns poisoning). By doing so, you may end up establishing a VPN connection with a rogue machine (of some malicious guy). Note that this is very unlikely as some more conditions are needed to be successful in this attack, such as stealing or "faking" certificates or bypassing validation.
So, back to your question, using a VPN will fully secure the connection between the two ends (whatever exists in between), as far as you are establishing the connection with the right host/target.
I'm working in a project where we need to connect clients to devices behind LAN networks.
Brief description: there are "devices" connected, in a home for example, under a LAN created by a router. These devices create a full webserver, operating under linux, and using nodejs as the backend implementation language. They also have access to Internet, through the public IP of the router. On the other side, there are clients which can choose to which device to connect to.
The goal is to connect the clients with the webServer created by any device.
Up to now, my idea is to try to implement something similar to how TeamViewer works. As I understand, Teamviewer has a central server, which the agents connect to. When an agent connects to the central server, this one gets hold of the TCP connection, keeping it alive. When another client wants to access to the first client, the server bypasses both TCP connections. That way the server acts like a proxy, where it additionally routes the TCP connections. This also allows to connect to clients under LAN or firewalls (because the connections are created always from the clients).
If this is correct, what I would like to implement is a central server, in nodejs as well, which manages a pool of socket connections coming from the different active devices, and when a client wants to connect to one specific device, the server bypasses the incoming TCP connection of the client with the already existing connection of the device.
What I first would like to know is if this is possible in nodejs. My idea is to keep the device connections alive, so clients can inmediately connect to them, creating some sort of pool of device connections.
If implemented in C, I guess I could get hold of the socket descriptor, keeping it alive, and bypassing it to the incoming client request. But in nodejs I can't seem to find any modules that manage TCP connections.
Are there any high level npm packages which do this function? Else, is it possible to use lower level modules (like net) which have those functionalities.
Ideally I would like to implement it with high level modules (express), but if it's not possible, I could always rewrite the server using low level modules.
Thanks in advance
I have a 'native' program (in Java) which would like to communicate with a Google Chrome/Chromium extension. The communication contains sensitive informations, and should not be accessible by anybody else than the user running them (and the root of course).
What technology should I choose for this communication channel? Is there even a solution?
EDIT:
Of course I could open a TCP/IP port on the local host, but wouldn't it be accessible by other users having an account on the same host? Is there a technic to avoid that side effect?
Could we access unix domain sockets from Google Chrome extensions?
Assuming you are already familiar with TCP, if you use localhost / 127.0.0.1 for the communication it would not be visible/available for other machines.
You could solve this at the higher level with a secured SSL communication with certificates etc... IF someone does not have the certificate, then the connection is killed. Moreover, you would benefit from encryption.
The solution that I chose is to have an server socket listening on the loopback interface (/ 127.0.0.1) with a shared secret used as an api key.
The reason is that I didn't realize that in my case each app which connect to my node had to be authenticated .. because each app is treated in a different way, with different access permissions.
I have an interesting network security challenge that I can't figure out the best way to attack.
I need to provide a way to allow two computers (A and B) that are behind firewalls to make a secure connection to each other using only a common "broker" untrusted server on the internet (somewhere like RackSpace). (the server is considered untrusted because the customers behind the firewalls won't trust it since it is on an open server) I can not adjust the firewall settings to allow the networks to directly connect to each other because the connections are no known ahead of time.
This is very similar to a NAT to NAT connection problem like that handled by remote desktop help tools (crossloop, copilot, etc).
What I would really like to find is a way to open an SSL connection between the two hosts and have the public server broker the connection. Preferably when host A tries to connect to host B, it should have to provide a token that the broker can check with host B before establishing the connection.
To add another wrinkle to this, the connection mechanism needs to support two types of communication. First, HTTP request/response to a REST web service and second persistent socket connection(s) to allow for real-time message passing.
I have looked at the techniques I know about like OpenSSL using certificates, OAuth, etc, but I don't see anything that quite does what I need.
Has anyone else handled something like this before? Any pointers?
You can solve your problem with plain SSL.
Just have the untrusted server forward connections between the client hosts as opaque TCP connections. The clients then establish an end-to-end SSL connection over that forwarded TCP tunnel - with OpenSSL, one client calls SSL_accept() and the other calls SSL_connect().
Use certificates, probably including client certificates, to verify that the other end of the SSL connection is who you expect it to be.
(This is conceptually similar to the way that HTTPS connections work over web proxies - the browser just says "connect me to this destination", and establishes an SSL connection with the desired endpoint. The proxy just forwards encrypted SSL data backwards and forwards, and since it doesn't have the private key for the right certificate, it can't impersonate the desired endpoint).
In general, SSL is packet-based protocol (for the purpose of solving your task). If you can have the host forward the packets back and forth, you can easily have SSL-secured communication channel. One thing you need is something like our SSL/TLS components, which allow any transport and not just sockets. I.e. the component tells your code "send this packet to the other side" or "do you have anything for me to receive?" and your code communicates with your intermediate server.