Secure communication between Chrome extension and mobile over local network - javascript

I am developing a mobile application and a corresponding chrome extension and planning to use UDP for data communication between mobile and extension using the udp API provided in chrome
It seems there is no provision to use DTLS in chrome APIs , so I a wondering how to secure the communication.
If I decide TCP over UDP I think TLS can be used for security as per the documentation
The mobile app and extension communicate only over local network.
Thanks in advance for suggestions.

To begin with: Extensions cannot use sockets APIs. Just so that doesn't come as a shock later. Only Apps have access to that.
That said, the sockets API provide you access to raw sockets. That means you can implement your own security on top of it. The API method you quote is there for convenience, but it can be reimplemented.

Related

How do Games (e.g. Counter Strike) find local network servers

I'm researching about servers and P2P and I remember that while playing CS on a local network, without an internet connection the client was able to fetch the servers on the local network. How is that possible? I really would like to implement something similar to that in WebRTC, although I believe it's not possible with WebRTC.
Peer discovery on a LAN is commonly done via UDP multicast which indeed is not available via browser APIs.

Socket connection from chrome extension being blocked by proxy/firewall

I have a web app in javascript that connects to a socket using socket.io and a Chrome Extension which connects in the same way and to the same server.
Everything works fine in most computers and internet connections, but one of my customer's computer is failing to have the Chrome Extension connected (the web app connects successfully).
By inspecting the extension's console for background.js (the script within the extension creating the socket connection) I see that it is not trying to connect to the right URL (my socket server) but to an unknown URL which seems to be a proxy: https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain...
Since this is happening only in that specific computer (from the 10 or so that I have tried with so far) using different internet connections (corporate network, guests network, mobile hotspot) and since other computers in those same networks DID succeed in connecting, I assume something installed or configured in the problematic computer is catching the connection request before it happens and tries to redirect it through a proxy.
Again, this happens only in the context of the Chrome Extension. The very same computer using the same internet connection DOES succeed in connecting from a web page in the same browser (Google Chrome).
Does anybody know what the problem could be? The client is not aware of having a security software (firewall, antivirus, etc...) that could be causing this, but it's a computer managed by his company so an admin could have done that for him. If that was the case, however, shouldn't the connection from the webpage be captured too? Is there anything specific to socket connections in Chrome Extensions that differ from regular web apps?
Thanks!
WebSocket connections differ from normal HTTP requests; they require a protocol upgrade after establishing that (some!) proxies may be unable to support.
I was at some point behind one such (transparent) proxy at work; however, it does not attempt to intercept HTTPS, which means I could use wss: WebSockets but not ws: WebSockets.
..which you should be using, anyway! With Let's Encrypt on the market, the barrier of entry for HTTPS is very low. If any sensitive data at all is sent through that connection, it's in your best interest.
For the record, that particular proxy is part of ZScaler which is a security solution. Sadly, it includes HTTPS MITM, so the above is unlikely to solve the problem (but should be implemented anyway!). It's set up as an OS-level proxy - if that setting is possible to change, or override with Chrome's proxy settings, that would fix it. However, that's going to piss off network security!
If you can't do that, then your client is a SOL and should complain up the chain about the security solution breaking legitimate applications.
Edit: I looked around and found this, which seems to claim that using SSL (that is, wss:) is enough. But that's from 2012 - perhaps before ZScaler was able to MITM all HTTPS traffic.
It should be possible to test whether wss: switch will work using https://www.websocket.org/echo.html - if it can connect then everything will work over wss:

Why we have WebSockets but have not simple Sockets in Web? [duplicate]

I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)

how to communicate through serial port on client side using javascript?

Recently received a request to add communication to a device connected via serialport on the client's machine through my webpage.
I'd done some googling and found that node.js with node-serialport seems to be the javascript way of doing it. However, in my case, the device is actually connected to the client's machine, and not the server.
My question would be how do i implement node.js in this sense? Since the code is run at the client browser, is it possible for me to 'embed' node.js on my webpage?
Or is there any other alternative for doing this? Applet and ActiveX are out of the picture though.
Thanks
UPDATES:
Had managed to convince the client to have applet loaded from the web, so we'll be going through the applet route. Thanks all for your great info! =)
JavaScript in the browser only has access to the APIs provided by the browser: it lives in the browser sandbox where it (rightly) has no access to the client file system or other hardware.
This is different from node.js, which is a server implementation that has access to all sorts of other file system APIs.
To "break out" of the browser you must use some sort of browser extension.
You will have to create a plugin, an applet, or a client side application to get the data into the client's web browser before being sent off to your server.
You could make a small app that reads the serial port of the clients machine that creates a .js file, and then your web page includes that src of that "dynamically" created js file on the client's machine and presto your webpage gets access to the serial port in a roundabout way.
This is how GPSGate works: http://gpsgate.com/developer/gps_in_browser/
See also here: How to read from Serial port in a webpage
And a java applet based solution:
http://code.google.com/p/java-simple-serial-connector/
http://code.google.com/p/java-simple-serial-connector/wiki/jSSC_Terminal
Try app.js if you want to access node.js functions from browser.
This can only be done via Active X or a plugin like Java or Flash. Code in JavaScript is only as powerful as the APIs provided to it from the browser.
Want to sent an HTTP request to a server? JavaScript can do that (subject to the same-origin policy), because the browser has the XMLHttpRequest API. Want to query what processes are running on the operating system right now? JavaScript cannot do that, because no browser provides an API for querying the OS about what processes it is running.
No browser that I know of implements any kind of JavaScript API for performing serial port operations, so there is no way to do it without using a plugin.
However, this does not preclude the possibility of such an API existing someday: the getUserMedia function can grab data from a camera or microphone, and it could theoretically be expanded to get data from other devices as well.
Another option (other than ActiveX or Java applet with security permissions) might be Google Native Client and the Pepper API, though whether this would be sufficient to access a serial port, I do not know.
A Firefox extension can include a native XPCOM component that could access the serial port, and you might find there is already a way to access the serial port from browser chrome (which extensions are) because the security token and smartcard system supports serial readers. A Firefox extension could also be used to deliver the next solution, which requires placing a native component or application on the system.
Can you tell us what browser(s) and OS('s) are targetted here, and why ActiveX and Java are ruled out?
Others have suggested a native running proxy exposing the serial port through some protocol. You could use node for this, or python, or any other language that can create both a serial connection and a socket. To access the proxy from a browser application you would need special security permissions to be granted to the page, and then you can make your proxy an HTTP or WebSocket server. You can also serve javascript from the proxy which would grant the script HTTP and WebSocket access to it's origin server which is the proxy. Google Chrome extensions can access any destination and port with their socket client. Also, I believe a config can be set in Google Chrome to allow this for certain or every page, the same with allowing native client to be used by a webpage.
Without knowing more about your goal, I can't determine what the best solution would be.
Another option to read the serial port data is using sockjs and sockjs-client-node at the server side and sockjs-0.3.js at the client side.

Can I connect to irc, icq, sip, etc services using WebSockets providing I have some sort implementation of those protocols in JavaScript?

I would like to connect to to irc, icq, sip, etc services using WebSockets.
Assuming I have some sort implementation of those protocols in JavaScript ?
Is that possible? I don't seems to understand limitations of WebSockets comparing to regular sockets.
No, you can't, at least not directly.
WebSockets allow real-time messaging between a browser and a WebSocket server, but they have their own layer 7 protocol for encapsulating those messages.
They don't provide access to a pure TCP (or UDP) socket over which you can implement existing protocols.
Absolutely!
The caveat is that you need something to bridge between the WebSocket transport protocol of the browser and the raw TCP socket of the existing service. For example, something like websockify (disclaimer: I created websockify). Another caveat is that websockify only supports TCP targets (WebSocket is TCP only right now so supporting UDP targets would be a little odd anyways).
The websockify project actually includes two proof of concept HTML/Javascript pages to communicate with IRC and telnet. If you are interested in leveraging websockify to build HTML/Javascript clients for some common TCP protocols, I might even pull them into the websockify repo as examples (assuming they are well coded and under an open source license.
An alternative to websockify is to integrate websocket server-side support directly into the servers you wish to communicate with. It's not all that difficult to add support. WebSocket has a very simple framing and while the handshake is compatible with HTTP servers it's actually much more restricted and simple and doesn't require a full HTTP parser. For example, libvncserver 0.9.9 now supports both regular VNC connections and VNC connections over WebSocket. This allows noVNC (which I also created) to connect directly to a libvncserver based VNC server without requiring websockify.
Inspircd has an unofficial module you can install called m_websockets, to allow connection. A server that has the module installed and setup will allow you to connect to the server via webbsockets.
https://github.com/barosl/inspircd-m_websocket
Extending on #kanaka's websockify, this project seems to do it:
A HTML5 irc-client, made with websocket and websockify.
[Has] support for autojoin, privmsg channel, topic, join, userlist, part, nick.
https://github.com/confact/dunirc
No, not with websockets, but you can with http.
Samy Kamkar gave a black hat talk about this.

Categories

Resources