Require HTTPS or localhost connection

[drewwills]

No description provided.

[andrewstuart]

Would we be considering using TLS client certificates as well as validating that services are using HTTPS?

I think this will be important to think about, as I think it's probably much more important that the Soffit providers can validate the source of a request is trusted (part of why I advocate for JWT in #5) than the portal being to authenticate that the service providers it's talking to are trusted. We already have that trust (to a limited extent) by the fact that administrators are required to initially configure the Soffit endpoints.

Either way, we should be aware that adding an HTTPS requirement (or default) will add significant cost or complexity (must purchase certificates or run your own CA and add its cert to Java CA keystores, OS CA stores, etc.) to the implementation.

In testing out HTTPS with my own golang provider, I already ran into a significant amount of complexity making sure the portal was able to trust the certificates being presented by the endpoints.

[drewwills]

I'm not sure how much this issue is pertinent any longer, since all data model elements are encrypted & signed. You have to know the encryption password to see any data.

[andrewstuart]

I'd still expect this would be highly desireable, since there's still a decent amount of information sent in plaintext that TLS would hide. The URL will be fully visible, and more importantly, the whole response (which may very well contain some of the previously-encrpyted info) will be returned in plaintext.

Additionally, the encryption TLS provides (DH key exchange per-session versus long-lived password-based encrpytion) will be much stronger and nearly impossible to guess the encryption key. With password encryption, the password is much more likely to be leaked in practice than the RSA secret key + key password.

[andrewstuart]

Additionally, do you have plans to make the JWT encryption optional? AFAIK that is not a standard yet (JWE rfc is still draft status) and so our current implementation is nonstandard and will make non-java integration more challenging (versus the many JWT libraries that can already validate standard JWT signatures).