hackoregon / civic-devops

Master collection point for issues, procedures, and code to manage the HackOregon Civic platform
MIT License
11 stars 4 forks source link

Redirect HTTP requests to HTTPS for APIs #215

Open MikeTheCanuck opened 6 years ago

MikeTheCanuck commented 6 years ago

Goals

  1. redirect any HTTP protocol requests to the HTTPS listeners
  2. send routes and query params intact
  3. minimize the extra infrastructure - e.g. ideally perform the redirection at the ALB layer

Need for redirect

There are many industry-wide efforts to drive as much of the world's traffic to HTTPS (TLS-encrypted) channels and minimize the amount of traffic over HTTP (non-encrypted). Google will be marking all HTTP pages "insecure" as of this year.

It would be preferable (especially as it's free, in an AWS world) to leverage HTTPS listeners - no questions there.

Given that all of Hack Oregon's infrastructure to date has been built on HTTP listeners (front end and APIs), there is a lot of legacy code that is hard-coded to send requests over HTTP.

So we will need to allow for incoming HTTP requests and redirect those requests to our HTTPS listeners.

Preserve routes and params

Further, I have noticed in many implementations of redirects that routes and query parameters can get dropped in the redirect, breaking the underlying application behaviour:

Minimize extra infrastructure

Ideally it would be less overhead, and fewer points of failure, if the redirects were performed at the ALB layer (or some other "hands-free" AWS piece). However, most documents and articles I'm finding in my research focus on implementing the redirecting listener as a web server module that you own yourself. Having to account for, configure, manage and support another dozen web servers just for the purpose of sending traffic from HTTP to HTTPS seems like an awful burden, and given how common this need is, I can't accept that Amazon hasn't found a way to relieve this burden themselves.

MikeTheCanuck commented 6 years ago

Minimizing infrastructure

If we believe the reddit thread that AWS has patently refused to implement the most common layer-7 redirect behaviour, that everyone in the world needs, in their layer-4 load balancer, then we're left to find the lightest-weight, lowest overhead web server configuration to manage this.

Here's one option which is attractive because it handles multiple domains and routes with a single web server. This would demand that we:

While I'm sure there's a way to walk that intricate tightrope, boy howdy does that sound painfully brittle.

MikeTheCanuck commented 6 years ago

Good news: ELB now supports redirects in ALB

Bad news: this is supported through direct manipulation, but CloudFormation hasn't implemented support for this new functionality.

So let's wait a couple of months before we can turn off the HTTP listeners.

martypdx commented 6 years ago

Any chance the "swagger" api pages (like this one) could be changed to use https for the underlying AJAX call?

MikeTheCanuck commented 5 years ago

Update: as of today AWS appears to provide the missing support in CloudFormation: https://forums.aws.amazon.com/thread.jspa?threadID=286855&tstart=0&messageID=878304#878304

MikeTheCanuck commented 5 years ago

And apparently this is a working example (haven’t read it, just filing away for later):

https://stackoverflow.com/questions/52085478/aws-cloudformation-application-load-balancer-how-to-redirect-http-listener-to/53498717#53498717

fstorr commented 5 years ago

Quick question about this. I notice that we have http and https versions of the site, but the https isn't the default. Is that in any way related to this issue and it's still blocked, or should I open a new issue to get https as default?

Thanks

MikeTheCanuck commented 5 years ago

Thanks for resurrecting this redirect idea @fstorr! I recall a recent problem folks were having with one but not the other of HTTP and HTTPS versions of the APIs: https://civicsoftware.slack.com/archives/CFTR2UVAP/p1567404250022600

Which leads to a couple of issues we have with our APIs: https://github.com/hackoregon/civic-devops/issues/210 - which hasn't been closed yet

https://github.com/hackoregon/2019-transportation-systems-backend/issues/63 - which apparently was implemented in the 2019 Transportation API but doesn't appear to have been resolved in the 2018/19 Disaster API yet (might just need a rebuild with the latest 2019-backend-docker build).