socket.io not connecting to mobile browser - macos

I wanna create a connection between my mobile Safari and nodejs + socket.io on my Macbook.
When i call localhost:8080 from my laptop, everything works fine. The console says that the client is connected and my little website is displayed.
When i call it over my mobile browser with 10.0.1.5:8080, the website is displayed as well, but my socket.io don't identify the mobile browser (iPhone) as client and nothing happens on the console board.
Does anybody where the problem is?

I found this post on SO, probably can help you out. why does my nodejs socket.io app not work on ios6
Localhost is local to the machine. You're IP should use a ip address
or domain name:
something like: io.connect('192.168.1.110'); or
io.connect('test.myapp.com');

WebSockets do not work over cellular network as they are not forwarded by the http proxy.
A possible workaround it to set the WebSocket server port to 443 (https) which forwards everything (as https is encrypted the proxy has to forward it in order to support https).
To see a real world example which solves this problem this way checkout nearby.
Remember this requires using two http servers:
Serving you mobile application (on port 80)
Serving the web sockets on (port 443)
Else you always have to use the specific ports in your urls which is mostly not preferred in production.

Related

Can Chrome and Safari access two different ports from the same page?

Currently my browser based application connects via port 7000 for both https web pages and websockets communication.
I understand that for security reasons, the browser will not let you connect to different IP addresses at the same time within the page.
My question is can my web page access the server (https port 443) for web page acquisition and then within the page open a https/wss.websocket connection to a different port (assuming the server is setup to accept a connection on that different port)?
Thanks.
The answer is YES.
I was hoping to get an answer so I would not have to design a test - but I did - and I can connect with WS on a different port than the port used to acquire web pages.

Restrict insecure web socket protocol connections in PCF

We are hosting an application in the preprod azure PCF environment which exposes websocket endpoints for client devices to connect to. Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
A few things:
You don't need to configure certs or anything like that when deploying your app to PCF. The platform takes care of all that. In your case, it'll likely be handled by HAProxy, but it could be some other load balancer or even Gorouter depending on your platform operations team installed PCF. The net result is that TLS is first terminated before it hits your app, so you don't need to worry about it.
Your app should always force users to HTTPS. How you do this depends on the language/framework you're using, but most have some functionality for this.
This process generally works by checking to see if the incoming request was over HTTP or HTTPS. If it's HTTP, then you issue a redirect to the same URL, but over HTTPS. This is important for all apps, not just ones using WebSockets. Encrypt all the things.
Do keep in mind that you are behind one or more reverse proxies, so if you are doing this manually, you'll need to consider what's in x-forwarded-proto or x-forwarded-port, not just the upstream connection which would be Gorouter, not your client's browser.
https://docs.pivotal.io/platform/application-service/2-7/concepts/http-routing.html#http-headers
If you are forcing your user's to HTTPS (#1 above), then your users will be unable to initiate an insecure WebSocket connection to your app. Browsers like Chrome & Firefox have restrictions to prevent an insecure WebSocket connection from being made when the site was loaded over HTTPS.
You'll get a message like The operation is insecure in Firefox or Cannot connect: SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. in Chrome.
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
From the application perspective, you don't do anything different. Your app is supposed to start and listen on the assigned port, i.e. what's in $PORT. This is the same for HTTP, HTTP, WS & WSS traffic. In short, as an app developer you don't need to think about this when deploying to PCF.
The only exception would be if your platform operations team uses a load balancer that does not natively support WebSockets. In this case, to work around the issue they need to separate traffic. HTTP and HTTPS go on the traditional ports 80 and 443, and they will route WebSockets on a different port. The PCF docs recommend 4443, which is where you're probably seeing that port. I can't tell you if your platform is set up this way, but if you know that you're using HAproxy, it is probably not.
https://docs.pivotal.io/platform/application-service/2-8/adminguide/supporting-websockets.html
At any rate, if you don't know just push an app and try to initiate a secure WebSocket connection over port 443 and see if it works. If it fails, try 4443 and see if that works. That or ask your platform operations team.
For what it's worth, even if your need to use port 4443 there is no difference to your application that runs on PCF. The only difference would be in your JavaScript code that initiates the WebSocket connection. It would need to know to use port 4443 instead of the default 443.

Android application Lose internet connection once connect to Fiddler

I have a strange situation using Fiddler to capture the HTTP/HTTPs traffic from an android application, in general, fiddler works fine, I got everything from any other app as chrome, and more, but this specific app not connect to the internet or lose the connection once I connect to fiddler Proxy server, I don't know why this happened also I don't know if someone has an explanation or got the same issue before, because fiddler in general working, but only this app, once I back to the normal connection and stop connecting to the Fiddler proxy server the connection back to this app.
so if someone has a solution or there is a similar problem as I did not find such kind of problem when I searched it will help.
I use the normal way to capture the data from fiddler by open Fiddler proxy server and connect my Android phone to my PC IP and the port of fiddler app, I was thinking about it and I'm not sure maybe this happened because the app did not trust the root certificate of the https of fiddler or the app protect from sniffing by disconnect the connection once the Android phone use a proxy, I am new using fiddler so I'm not sure how it's going.
I read about also certificate pinning, but I think this is not the case as if it happened it normally connect and show Tunnel or something like this as I understand in the fiddler screen, but not lose the connection.
Thanks in advance.

How to proxy HTTPS via HTTP without CA or MITM?

HTTP proxy with SSL and DNS support.
I must be lacking some key concepts about proxy-ing because I cannot grasp this. I am looking to run a simply http or https proxy without interfering with SSL. Simply, a fully transparent proxy that can passthrough all the traffic to the browser connected via HTTP or HTTPS proxy without modifying or intercepting any packets. Not able to find any code online or I'm not using the right keywords.
EX. On the browser adding server.someVPN.com:80 on the HTTP proxy field and as soon as you try to visit a website, it prompts for authentication. Then it works perfectly with any domain, any security, any ssl, no further steps needed. Most VPN providers have this.
How's this possible? it even resolves DNS itself. I thought on transparent proxy the dns relies on the client. Preferably looking for a nodeJS solution but any lang works.
Please don't propose any solutions such as SOCKS5 or sock forwarding or DNS overriding or CA based MITM. According to HTTP 1.1 which supports 'CONNECT' this should be easy.
Not looking to proxy specific domains, looking for an all inclusive solution just like most VPN Providers providers.
----Found the answer too quickly, feel free to delete this post/question admins.
The way it works is that the browser knows it is talking to a proxy server, so for example if the browser want to connect to htttp://www.example.com it sends a CONNECT www.example.com:443 HTTP/1.1 to the proxy server, the proxy server resolves wwww.example.com via DNS and then opens a TCP connection to wwww.example.com port 443 and proxies the TCP stream transparently to the client.
I don't know any solution for nodejs. Common proxy servers include Squid, Privoxy and Apache Traffic Server
See also: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT
Found the solution right after I asked...
This module works perfectly https://github.com/mpangrazzi/harrier
Does exactly what I was asking for.

WebSocket security?

I have a custom websockets server (non-secure) implemented with of libuv. Same server also supports some HTTP requests (source).
Everything works just fine if I listen on 127.0.0.1, except some users are reporting that they can't connect from remote systems. HTTP requests work fine if I listen on 0.0.0.0 but browsers and VS Code do not seem to even try to send Upgrade request. What could be the reason? Could it be my workstation setup (e.g. some sort of a firewall)?
Something wrong with my corp network settings - works just fine in other networks...

Resources