Public url via http


#1

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?


#3

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.


#5

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.

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.


#6

Tim,

having some problems implementing this as all we can only serve HTTP over the VPN, see Open https via public URL
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.


#7

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 in the first place.


#8

@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.


#9

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 server? I don’t need to make each device have its own self signed cert because i’m actually talking to 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.