As of #1128, bootstrap-agent to bootstrap-agent communications may (if an SP is present) take place in sprockets sessions, providing authentication and confidentiality. However, the current mechanism by which sprockets is integrated is as a TCP proxy sitting between the bootstrap-agent dropshot server and its client (see #1128 for more details). The dropshot server itself listens on localhost and implicitly trusts all incoming connections, expecting them to only be coming from the sprockets proxy. This needs to be locked down to guarantee requests to the dropshot server can only take place if the client has connected via sprockets. (A similar problem exists on the client side, where the sprockets proxy implicitly trusts all connections made to it before forwarding them to the corresponding serverside sprockets proxy.) Some possible options:
- Extend dropshot itself (and progenitor) allowing custom listeners/acceptors sufficiently for us to use hyper-sprockets, similarly to how dropshot/progenitor have built-in support for TLS.
- Switch from using TCP for the localhost connections to Unix domain sockets?
- Sufficiently lock down the TCP services (this point is vague because it's unclear to me what could be done here)?
- Move away from dropshot/progenitor entirely, and use something bespoke over "raw TCP" (inside a sprockets session)
My preference is the first, but it requires a currently-unknown amount of work; probably more on the progenitor side than dropshot due to progenitor's use of reqwest, which currently does not support custom clients.
CC @smklein @andrewjstone @ahl
As of #1128, bootstrap-agent to bootstrap-agent communications may (if an SP is present) take place in sprockets sessions, providing authentication and confidentiality. However, the current mechanism by which sprockets is integrated is as a TCP proxy sitting between the bootstrap-agent dropshot server and its client (see #1128 for more details). The dropshot server itself listens on localhost and implicitly trusts all incoming connections, expecting them to only be coming from the sprockets proxy. This needs to be locked down to guarantee requests to the dropshot server can only take place if the client has connected via sprockets. (A similar problem exists on the client side, where the sprockets proxy implicitly trusts all connections made to it before forwarding them to the corresponding serverside sprockets proxy.) Some possible options:
My preference is the first, but it requires a currently-unknown amount of work; probably more on the progenitor side than dropshot due to progenitor's use of reqwest, which currently does not support custom clients.
CC @smklein @andrewjstone @ahl