https for secureproxy

[bengerman13]

In order to move towards our goal of end-to-end encryption, we want https for secureproxy.

We should also consider adding http2 at the same time. If it's as easy as adding http2 to the listen directive, do it. If it's harder, create a second ticket to do it.

Acceptance Criteria

• [ ] WHEN a tls request comes into secureproxy \ THEN we get a successful response
• [ ] WHEN a plaintext request comes into secureproxy \ THEN we do not get a successful response
• [ ] WHEN a plaintext request comes into a load balancer \ THEN it is redirected to https

---

Security considerations

This ~gets us closer~ provides full end-to-end encryption, which is a security and compliance win

Implementation sketch

• [ ] add https support to secureproxy
  • [ ] see if we can use self-/bosh-signed certs for this, or if ALBs need publicly-trusted certs
• [ ] add gorouters to target group with https port
• [ ] test
• [ ] drop http gorouters from target group
• [ ] test

[pburkholder]

Ben - Based on the very rough documentation at https://docs.google.com/document/d/1305gdMf8Q6OIzwfmuT4XJaw4-lTR0DNa10346wZDRcA/edit# shouldn't this work bring us to full E2E TLS except for customer container-to-container using apps.internal?

[bengerman13]

I believe so

[pburkholder]

@ChrisMcGowan For our meeting with IDVA (and others) can you provide an update on how this is going?

[kbighorse]

please tag me if the HTTP/2 bit becomes its own issue. We may have something coming down the pike.