I’ve got a device exposed via the resin vpn/public url.
I’d like to serve https from the device itself - however the vpn only proxies port 80 - any chance you could open up 443 as well?
hey @nite,
I don’t think we can since Port 443 is used by our VPN. You can find more details about network requirements on a resin device here https://docs.resin.io/deployment/network/1.x.x/.
Hi @nghiant2710 - so, how would you suggest we proceed? Currently, we’ve got a gap of no ssl from device to resin. Would serving https over another port work from your side, eg. (random pick 4443), either a fixed port you specify, or configure somehow via the dashboard?
What do you use to serve HTTPS on the device? Most servers can be set up to serve on any port, not just default ports, thus you could have a HTTPS server on port 80, that is then forwarded properly.
In the same time, can you give us a bit more info on why you need HTTPS in this particular case? Both the device->VPN connection (through OpenVPN) and VPN->visitor traffic is encrypted already, so there should not need to be doing a second encryption on the device->vpn connection.
at the moment just using express.js I think but @nite can confirm. we could serve https over port 80 but unless the device endpoint is not also serving https which I understand is forced your end I’m not sure how the browser would handle it, i guess first pass is try it.
On the no need to add encryption because of the Device ->VPN->Visitor traffic route means that there is a high degree of trust placed in resin.io as the proxy operator and only person to have visibility of the devices that operate the VPN->visitorTraffic coupling.
I imagine certainly in the data collection scenario that asset owners are more than happy for you to provide the management services but will want the assurance that only their own PKI can provide to their data, also in the Device->VPN->visitorTraffic there is only a token issued by yourselves to provide authentication to both ends and no ability for customers to apply there own PKI systems. not utilising TLS anyway
Was just checking it out, in my quick test actually serving HTTPS on port 80 does not seem to work with Public Device URL (while in general it works, could serve it on the local network). So that workaround is probably out, then 
If you’d like a tunnel that is completely independent of resin.io, then maybe can recommend ngrok. That’s a pretty good service that we are using for a bunch of times here and there (not in the platform itself, but for projects). That way you can create your own separate communication channel, and seeing their docs, there seems to be a couple of settings that are relevant to how to do a setup as you mention.
cheers @imrehg - we are indeed serving via node/express currently - will give https over port 80 a go.
Cheers for the reminder re: ngrok - it’s definitely a handy service 
I had a look at ngrok the other day and thought nah won’t need that with resin’s public url 
looks like i might need to have a chat with them then
It all depends on what you want to achieve, always a trade-off 
If your trust model is such that you trust resin.io for device updates and management but not data traffic, then you’ll need some external services at the moment.
Nevertheless, I’ll put in a note for the team to check out whether the Public URL can be served such as you describe it, thanks for the feedback!
no problem thanks for the help, hopefully this means we don’t move over to ngrok link 
as that could meet some of our device management needs too, are you likely to be getting ISO27001 any time soon? or be able to share how the VPN public URL coupling is handled? it doesn’t seem very graceful to use both at the same time but that said it would likely work very nicely
It’s a setup such that the connections go as Device <-> VPN <-> Proxy <-> Client. The VPN is OpenVPN through which the device communicates with the resin.io services. The proxy is a very small app running on our servers based on https://github.com/findhit/proxywrap, and it’s a really minimal wrapper to proxy data between the VPN and the client, and display some meaningful error messages when that’s not possible (ie. nothing’s listening on the device on port 80).
As for ISO27001, I don’t think that it is something that we are currently working on.
HTTPS over port 80 is a bad idea. Don’t mess with standards. Any number of things could go wrong with assumptions made about correspondence between port number and functionality with every piece of software used in the process. Any other port, just not 80.
1 Like
Hi All,
sorry for resuming this old topic but for security reasons is a requirement for us that public URL traffic must be encrypted.
Traffic between balena proxy and host could be unencrypted because it should be already protected by the vpn but internet traffic not. Balena proxy should enforce HTTPS.
As a workaround we upgrade the connection from the js page to https but this still leaves our API exposed on internet over plain HTTP.
Bye.
Hi @fcasarsa
Thanks for your message. Can you please provide us with some more details on your use case, and how we can assist you in this?
Kind regards
Alida