TLS integration #249
Comments
smklein
changed the title
smklein
added a commit
that referenced
this issue
Mar 24, 2022
- We have been serving Nexus' external API over HTTP, not HTTPS. This is a known deficiency, tracked by #249. - Session cookies, which are used when authenticating to the console, use the [Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies) attribute to ensure that they're exclusively sent over HTTPS. - @david-crespo has theorized that "this worked anyway" because the console had been typically accessed over localhost, and an exception was granted. Until HTTPS integration is adopted across the stack more universally, allow the console to be served in the interim. This change is necessary to access Nexus-from-within-a-Zone, as it is no longer accessible over localhost. This change should be undone once #249 has progressed.
smklein
added a commit
that referenced
this issue
Jun 28, 2022
Part of #249 This PR forces Nexus's external interface to be served via HTTPS when deployed by the sled-agent. - The packaging system expects to find these certificates within `./out/certs`, named `cert.pem` and `key.pem`. - `./tools/create_self_signed_cert.sh` is capable of creating a self-signed certificate.
smklein
added a commit
that referenced
this issue
Jul 26, 2022
Part of #249 This PR forces Nexus's external interface to be served via HTTPS when deployed by the sled-agent. - The packaging system expects to find these certificates within `./out/certs`, named `cert.pem` and `key.pem`. - `./tools/create_self_signed_cert.sh` is capable of creating a self-signed certificate.
jmpesp
pushed a commit
to jmpesp/omicron
that referenced
this issue
Aug 8, 2022
…1500) Another attempt at oxidecomputer#1287 In addition to launching an HTTPS server, this also launches an HTTP server so we can smoothly migrate clients (like the CLI). Part of oxidecomputer#249
|
Mentioning here that there's a TODO-security that mentions this ticket that we probably also want to resolve for MVP: omicron/nexus/src/authn/external/session_cookie.rs Lines 59 to 60 in b062e95 |
david-crespo
added a commit
that referenced
this issue
Sep 7, 2023
We had a TODO item in the code pointing to #249, but no dedicated issue. The `Secure` attribute means the browser will only include the cookie with encrypted requests. This is a no-brainer table stakes kind of thing we _must_ do. This was blocked on adding TLS to Nexus. We use `deployment.dropshot_external.tls` to decide whether to include `Secure` so things will still work in non-TLS environments like local dev. ~~Because the tests do not run in a browser, I think they should be indifferent to the `Secure` attribute, but I'll find out when CI runs.~~ ~~The browser ignores this on `localhost`, so for a simple local Nexus instance without TLS this shouldn't be a problem. However, if people are running Nexus without TLS for other test and dev setups, that might be a problem — the web console won't work. I think we could get around that by looking at the config value for `deployment.dropshot_external.tls` and only including `Secure` if it's true.~~
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a number of services which will need TLS integration. This issue tracks that integration:
Nexus
Nexus exposes an external server for servicing client requests, as well as an internal server for handling requests from sled agents. Both should exclusively use encrypted traffic.
Agents
Sled Agent, Bootstrap Agent, Oximeter and others (e.g., the to-be-created SP agent, possibly?) employ cross-machine communication, and will need TLS integration to securely communicate.
CockroachDB
For development purposes, we use the --insecure flag when deploying CockroachDB instances. However, in the limit, we should ensure that we can safely deploy Cockroach instances using exclusively encrypted traffic.
Blocked on...
The text was updated successfully, but these errors were encountered: