# Public url via http

**URL:** <https://forums.balena.io/t/public-url-via-http/1099>\
**Category:** Product support\
**Created:** [May 30, 2017, 8:53pm UTC](https://forums.balena.io/t/public-url-via-http/1099 "2017-05-30T20:53:38Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![jmarshall](https://avatars.discourse-cdn.com/v4/letter/j/7993a0/32.png) [@jmarshall](https://forums.balena.io/u/jmarshall)\
**Post date:** [May 30, 2017, 8:53pm UTC](https://forums.balena.io/t/public-url-via-http/1099/1 "2017-05-30T20:53:38Z")

</div>

hey so it seems devices public URLs aren’t being redirected from http to https and are accessible via http too, is this by design? is there anyway we can adjust this?

---

<div class="post-metadata">

**Author:** ![pcarranzav](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pcarranzav/32/94_2.png) [@pcarranzav](https://forums.balena.io/u/pcarranzav)\
**Post date:** [May 30, 2017, 9:11pm UTC](https://forums.balena.io/t/public-url-via-http/1099/3 "2017-05-30T21:11:06Z")

</div>

Hi @jmarshall  
It is by design that both HTTP and HTTPS work - but it does make sense to be able to disable HTTP access, so I’ve added it to our internal feature request tracking.

---

<div class="post-metadata">

**Author:** ![pimterry](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pimterry/32/140_2.png) [@pimterry](https://forums.balena.io/u/pimterry)\
**Post date:** [June 1, 2017, 12:48pm UTC](https://forums.balena.io/t/public-url-via-http/1099/5 "2017-06-01T12:48:35Z")

</div>

Whilst, as @pcarranzav says, we don’t have support to solve this built-in, if this is important to you then you can work around it yourself using HSTS: [https://en.wikipedia.org/wiki/HTTP\_Strict\_Transport\_Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security).

If you return an HSTS header with all responses, then after a given user’s browser receives its first HTTPS response, their browser will automatically redirect from HTTP to the HTTPS resources for all future requests.

This won’t work if the user’s first request is HTTP only, and I don’t think you can detect HTTP/HTTPS server-side with a public URL, so you can’t automatically redirect to HTTPS there yourself. You could detect this in JavaScript though, and trigger a redirect client-side.

With that you can ensure a given user is _always_ on a secure connection, after their first request. There’s HSTS preloading in browser releases, which in principle could let you do this for the first request, but is probably overkill for per-device URLs imo (since you’d have to submit all your device URLs to mozilla/google/et al). Hopefully we’ll take a look at this in future though, which would solve this more thoroughly anyway.

---

<div class="post-metadata">

**Author:** ![jmarshall](https://avatars.discourse-cdn.com/v4/letter/j/7993a0/32.png) [@jmarshall](https://forums.balena.io/u/jmarshall)\
**Post date:** [June 5, 2017, 3:46pm UTC](https://forums.balena.io/t/public-url-via-http/1099/6 "2017-06-05T15:46:27Z")

</div>

Tim,

having some problems implementing this as all we can only serve HTTP over the VPN, see [Open https via public URL](https://forums.balena.io/t/open-https-via-public-url/994/6)  
It seems all the HTTPS is offloaded by your reverse proxy. we can only see the request coming in as HTTP. so would never see a HTTPS connection unless as suggested we pick it up client-side, is of course open to manipulation. preloading i think is overkill too.

It would help massively if it was optionally to enable or disable. i’m surprised no one else is concerned about it.

---

<div class="post-metadata">

**Author:** ![pimterry](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pimterry/32/140_2.png) [@pimterry](https://forums.balena.io/u/pimterry)\
**Post date:** [June 5, 2017, 4:42pm UTC](https://forums.balena.io/t/public-url-via-http/1099/7 "2017-06-05T16:42:10Z")

</div>

Totally agree full support would be useful! This is in our feature requests list now, and we’ll certainly be considering it in future - I’m just trying to put together a workaround to help you out in the meantime.

The fact that a plain HTTP client-side scripting redirect is open to manipulation shouldn’t matter here - the traditional plain HTTP server-side redirect is open to exactly the same manipulation too, so they’re more or less equivalent in practice. I think the only difference is if you have clients that can’t/won’t run JS, but if you’re only worrying about browsers that’s unlikely to be a major concern.

Anyway, I think you should still be able to get the essential core of this functionality right now, even just with a simple HTTP-only server, even if you don’t want to do client-side redirects.

You should just need to return HSTS headers in all your server’s responses, including on plain HTTP requests. If you do that, then any user who does make an HTTPS request to the public url will receive their HTTPS response with valid HSTS headers, and that’ll take effect completely as normal from their point of view, even though it appears as plain HTTP to you. That will immediately block plain HTTP for this URL in that user’s browser. You can’t ensure that users who make HTTP requests straight from day 1 are guaranteed to be safe (although, to be fair, that’s also true for 100% of non-HSTS-preloaded domains on the internet), but if you just add those headers to your responses you can ensure that all users who’ve made at least one HTTPS request before can never accidentally end up on HTTP in future.

While I agree built-in support is much more convenient, without some kind of preloading this is actually very nearly the best guarantee here that you can get anyway. Even we blocked HTTP entirely in our servers, any user making an initial insecure HTTP request can get intercepted and MitM’d before their request reaches [Resin.io](http://Resin.io) in the first place.

---

<div class="post-metadata">

**Author:** ![pimterry](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/pimterry/32/140_2.png) [@pimterry](https://forums.balena.io/u/pimterry)\
**Post date:** [June 9, 2017, 11:17am UTC](https://forums.balena.io/t/public-url-via-http/1099/8 "2017-06-09T11:17:40Z")

</div>

@jmarshall any thoughts on the above? I’d love to know if you’ve tried this, and how it’s working for you in practice.

---

<div class="post-metadata">

**Author:** ![sam](https://avatars.discourse-cdn.com/v4/letter/s/5f9b8f/32.png) [@sam](https://forums.balena.io/u/sam)\
**Post date:** [June 15, 2018, 9:32pm UTC](https://forums.balena.io/t/public-url-via-http/1099/9 "2018-06-15T21:32:19Z")

</div>

Networking is not a strength area for me. But if i’m understanding this right, this doesn’t matter if you are the only user of your public URL.

For my use case I’m trying to make API calls between our remote devices and our AWS servers, API calls will be bi-directional. In order to have the servers hit our resin devices I was going to have it use the public URL. I’ve been digging on if it is secure or not, and it seems to depend on if we use http or https before the rest of the URL. Is this because we aren’t actually accessing the device on port 80? What we are actually doing is being forwarded that port by the [Resin.io](http://Resin.io) server? I don’t need to make each device have its own self signed cert because i’m actually talking to [Resin.io](http://Resin.io) which has its own cert?

Am I right on this? Sorry to bump old material but making a new post seems un-needed.

---

<div class="post-metadata">

**Author:** ![aliasbits](https://avatars.discourse-cdn.com/v4/letter/a/71c47a/32.png) [@aliasbits](https://forums.balena.io/u/aliasbits)\
**Post date:** [August 8, 2019, 2:38pm UTC](https://forums.balena.io/t/public-url-via-http/1099/11 "2019-08-08T14:38:21Z")

</div>

I am working on a solution which requires a device to be accessible for local area network and to be accessible for support via the balena public url. This works by use of HTTP for both local area network and balena public url.

The problem is that the balena public url proxies both a HTTP and HTTPS version of the HTTP device web service.

Are there any status/discussions/changes to the guide about using HSTS and client side redirect or on the balena public url proxy HTTP disable/enable feature?

Furthermore, the local area network needs to be served as HTTPS in near future.

Any status/discussion about providing the device [HTTPS](https://forums.balena.io/t/open-https-via-public-url/994/11) port on balena public url instead of the proxyed HTTPS version of the device HTTP port? This is not a question about trust model, but more if this will/can be allowed at some point when [multiple ports with public url](https://forums.balena.io/t/multiple-ports-with-public-url/927/17) is supported.

---

<div class="post-metadata">

**Author:** ![wrboyce](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/wrboyce/32/374_2.png) [@wrboyce](https://forums.balena.io/u/wrboyce)\
**Post date:** [August 9, 2019, 9:39am UTC](https://forums.balena.io/t/public-url-via-http/1099/14 "2019-08-09T09:39:29Z")

</div>

Hi there, we currently have a feature in internal testing which will allow https public urls to be terminated at the device when using a custom domain. This would allow you to handle requests on both ports 80 and 443 on your devices and redirect/reject http connections appropriately and serve https via both balena’s vpn and locally on the LAN. Additionally, there is currently (albeit limited) support for multiple ports on public urls: both ports 80 and 8080 will be forwarded to the device.

---

<div class="post-metadata">

**Author:** ![aliasbits](https://avatars.discourse-cdn.com/v4/letter/a/71c47a/32.png) [@aliasbits](https://forums.balena.io/u/aliasbits)\
**Post date:** [August 23, 2019, 12:16pm UTC](https://forums.balena.io/t/public-url-via-http/1099/16 "2019-08-23T12:16:22Z")

</div>

Hi @wrboyce

What does it mean by internal testing. Like in a solution which needs to be battle proven or trying to make a solution. Any idea about time estimate?

I am tried to add a webdav to an existing solution, but got some concerns about the fallback to http if the end user by mistake type http instead of https

---

<div class="post-metadata">

**Author:** ![CameronDiver](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@CameronDiver](https://forums.balena.io/u/CameronDiver)\
**Post date:** [August 23, 2019, 12:33pm UTC](https://forums.balena.io/t/public-url-via-http/1099/17 "2019-08-23T12:33:53Z")

</div>

We have implemented the feature itself, we now need to test it in several different scenarios to ensure that we don’t release any harmful bugs to production, but the lions share of the work is done. I would estimate that within a week or two this will be available. The http fallback is a valid concern, I’m not sure if we would be redirecting https -\> http after release. I will raise a ticket internally so that we can discuss this.

---

<div class="post-metadata">

**Author:** ![jason10](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/jason10/32/1464_2.png) [@jason10](https://forums.balena.io/u/jason10)\
**Post date:** [November 9, 2019, 1:01am UTC](https://forums.balena.io/t/public-url-via-http/1099/19 "2019-11-09T01:01:29Z")

</div>

What about running a simple webserver on port 80 that redirects using HTTP response 302 to port 443 or to the https domain?

---

<div class="post-metadata">

**Author:** ![mbedare](https://avatars.discourse-cdn.com/v4/letter/m/c57346/32.png) [@mbedare](https://forums.balena.io/u/mbedare)\
**Post date:** [November 25, 2019, 4:46pm UTC](https://forums.balena.io/t/public-url-via-http/1099/20 "2019-11-25T16:46:40Z")

</div>

HTTP redirect can not be used here as redirect URL is not reachable from client browser. We need wither achieve NAT or port forwarding.

---

<div class="post-metadata">

**Author:** ![chrisys](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/chrisys/32/1731_2.png) [@chrisys](https://forums.balena.io/u/chrisys)\
**Post date:** [November 25, 2019, 10:17pm UTC](https://forums.balena.io/t/public-url-via-http/1099/21 "2019-11-25T22:17:43Z")

</div>

@mbedare welcome to the forums!

What are you trying to do? Maybe start a new thread if you have a question that makes you think you’ll need NAT or port forwarding.

---

<div class="post-metadata">

**Author:** ![mbedare](https://avatars.discourse-cdn.com/v4/letter/m/c57346/32.png) [@mbedare](https://forums.balena.io/u/mbedare)\
**Post date:** [November 26, 2019, 9:56am UTC](https://forums.balena.io/t/public-url-via-http/1099/29 "2019-11-26T09:56:48Z")

</div>

> [@NAT or IP Port forwarding from container](https://forums.balena.io/t/nat-or-ip-port-forwarding-from-container/46414):
>
> Hi I want to access local web-server behind Belea OS using public URL provided by Balena. Setup Device with webserver (192.168.100.20)----- (192.169.100.1) eth0 Baleba : Balena wlan0 (DHCP dynamic IP) ----- local wifi ----internet ---- browser Can someone please guide on how we can achive NAT/Port forwarding? I tried software approach wherein simple java socket program binds to the incoming socket and opens other TCP connection in forward direction but this is very slow (I need to deploy thi…

---

<div class="post-metadata">

**Author:** ![Rishub](https://avatars.discourse-cdn.com/v4/letter/r/ba9def/32.png) [@Rishub](https://forums.balena.io/u/Rishub)\
**Post date:** [January 14, 2021, 2:59pm UTC](https://forums.balena.io/t/public-url-via-http/1099/34 "2021-01-14T14:59:06Z")

</div>

Hey, just wanted to see if there is any update on this. We’re also struggling with ensuring HTTPS only traffic, and I know y’all mentioned the feature was in internal testing since last year. Is it available now?

---

<div class="post-metadata">

**Author:** ![krix](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@krix](https://forums.balena.io/u/krix)\
**Post date:** [April 16, 2021, 4:25pm UTC](https://forums.balena.io/t/public-url-via-http/1099/35 "2021-04-16T16:25:55Z")

</div>

Echo that: We too are

> struggling with ensuring HTTPS only traffic
