VerifiedRoutes.url used behind reverse proxy

Phoenix Forum Questions / Help
,
1

I’ve encountered an issue with VerifiedRoutes.url when the application is running behind nginx. I need to send a link via e-mail, so I generate the url with url(~p/some_path/), which returns http://myapp.com:5000/some_path, since the endpoint itself is using http and the port is set to 5000. Of course, what I actually need is https://myapp.com/some_path

I have nginx configured to send the X-Forwarded-For header, so the application knows the actual address that is visible to users. Is there an easy way to make url use this information instead of the endpoint config? Or should I make a custom helper instead?

2

The URL generation is controlled by the Endpoint configuration (specifically the :url option). The value is configured in runtime.exs by default. This option only controls URL generation (for links in the app), it does not configure the webserver (that’s the :http option right below it).

I’m assuming from your post that you changed it thinking it was the webserver configuration, so if that’s the case changing it back to the default should resolve the problem :slight_smile:

(Also: If this is the case, the links in your app should all be wrong too, right?)

For the record, you could also pass a few other things into url/2 if you needed to, like a conn / socket, a different endpoint, or a URI. But I don’t think that’s what you need here.

Not sure I understand what you mean here. X-Forwarded-For contains the original client IP address(es) from the original request (and any proxies in between). The host/port are sent via the Host header, which I assume Nginx just passes along in the proxied request.

Either way, by default the URL generation is controlled by the Endpoint config.

2 Likes
3

Thanks, it seems there are a few options I have mixed together that mean different things and I need to sort them out.

1 Like
4

I haven’t tested it myself, but I guess that if you configure Nginx to pass the x-forwarded-port header, and apply Plug.RewriteOn plug in the endpoint, the url helpers will generate links with the appropriate port(s).

2 Likes
5

So I think the confusion has been explained. The scheme option worked as expected, but it seems that the port from the http config gets used for url generation as well, so I had to explicitly set it to 443. Thanks for the help, this is what the config looks like in case anyone else gets confused:

config :myapp, MyappWeb.Endpoint,
  url: [
    scheme: "https",
    host: "myapp.com",
    port: 443
  ],
  http: [port: 5000]

Also, to explain why I never noticed it from links in the application itself, it’s because they only need ~p unlike links in e-mails, which need the full url, so the incorrect options never manifested.

2 Likes
6

This configuration might fix the generated URLs, but it does not solve the underlying issue that Phoenix does not know that the server was actually reached via HTTPS. As a result, certain security features are not enabled. In particular, (session) cookies do not get the secure option that is meant to prevent them from leaking in plaintext HTTP requests.

For more details, see TLS Vulnerabilities | EEF Security WG

The better solution is the use of HTTP headers to pass the external scheme and port from the reverse proxy to the application, as suggested by @ibarch

3 Likes
7

Interesting, I was unaware of X-Forwarded-Host/Port. That would explain my confusion regarding X-Forwarded-For in the OP :slight_smile: It’s funny that reverse proxies don’t just pass along the original Host header - obviously in the case of the IP address that’s impossible, but the header could be forwarded just fine. Maybe it’s just done this way for consistency?

Is this mentioned anywhere in the Phoenix docs? I would think it should be brought up in the deployment guides, i.e. the Fly.io one which would sit behind Fly’s reverse proxy, but I see no mention of it. The Plug.SSL docs are the most I see about it. The default runtime.exs does have a line suggesting that you enable HSTS.

It seems to me like enabling HSTS would also resolve the issue, correct? The client can’t send cookies over HTTP if it’s not allowed to make insecure requests at all. Obviously this is not an option if you intend to actually serve insecure traffic, but that’s not common anymore.

So if that’s the case, either (or both) of these would suffice:

Edit: the above is NOT correct, see replies below. You always need :rewrite_on behind a reverse proxy:

# In prod.exs, not runtime (:force_ssl is a compile-time option)
config :my_app, MyAppWeb.Endpoint,
  force_ssl: [
    rewrite_on: [:x_forwarded_host, :x_forwarded_port, :x_forwarded_proto],
    # Optional, for HSTS:
    hsts: true,
  ]

Am I missing anything?

8

Either is not enough. Enabling HSTS would only surface that you’re missing the former, but it wouldn’t enable them.

1 Like
9

I was surprised to read this, but after checking the code I see that you’re correct - the HSTS header is only added if scheme is :https. Indeed, this is also the second line in the docs (hah) which I did not read because I only scanned the options section to see what was accepted by the Endpoint config :slight_smile:

This was not intuitive to me because I figured you could technically force HSTS over HTTP, but apparently the browser spec says to ignore strict-transport-security over http, so that’s probably why Plug doesn’t send it. Perhaps it would be safer to send it anyway in case the user has misconfigured their reverse proxy setup? I don’t see how it could hurt. (Edit: This would be pointless because forcing SSL would just create a redirect loop anyway, since Plug still doesn’t know the proxy terminated TLS.) I suppose this is really what HSTS preload is for.

I will update my previous comment just in case someone stumbles upon it. Thanks!

Also, I found the relevant part of the Phoenix documentation that I was looking for earlier:

https://hexdocs.pm/phoenix/using_ssl.html#force-ssl

I feel like this should be mentioned in all of the deployment guides, but I only see it linked in the Gigalixir/Heroku guides (the ones I didn’t check before, of course). I would think the Fly guide at least should also mention SSL.

10

I’m glad by original question uncovered something interesting. Yes, the X-Forwarded-For header was wrong, X-Forwarded-Host is the correct one, along with port and proto.

I’ve configured rewrite_on to use all three headers and made sure nginx was setting them properly. Thanks for your interest, everyone.

1 Like
11

I came across a couple things today which I figured I should post here for the sake of completeness.

First, Caddy actually does pass along the original Host header by default like I had thought before, though it of course also sets X-Forwarded-*. Nginx, on the other hand rewrites the header by default.

Second, there is actually a case where you do need to rewrite the Host header: if you are using HTTPS to encrypt traffic between the reverse proxy and your webserver, you need to set the Host to match the cert! In this case you would be forced to rely on X-Forwarded-Host to know the real host.

2 Likes