https-bastion: Spec feedback

[niels-moller]

Hi,

at last I've had a closer look at the bastion spec, with implementor eyes. Some questions and comments:

Backend to bastion: Probably obvious, since it terminates TLS, but this means that bastion needs to be exposed directly to the internet, in contrast to, e.g., operating behind a reverse proxy. Makes perfect sense for its purpose, but makes it less attractive to integrate the bastion function in a service that otherwise provides a plain web api that can sit behind a reverse proxy. My uses case would be the sigsum log server.

Backend auth: "The bastion checks the backend public key against an allowlist or verifies the client certificate chain." I don't get chain validation as an alternative to the public key allowlist. Are you thinking about an allowlist of x.509 names (rather than key hashes), with the names certified by any trusted web CA, or bastion operator running it's own CA signing the client certs of all allowed backends?

On bastion configuration, I wonder if there's some way to avoid maintaining an explicit allowlist. Is there any reasonable way to either be rather liberal in accepting backends, or have clients tell the bastion which backends they would like the bastion to serve?

Client to bastion requests: Would it make sense to add a verb to the request url, like

https://<bastion-host>/<verb>/<key hash>/<path>

For the main operation, verb would be "connect". The other operation I'm thinking about is "add", meaning please add this keyhash to the allowlist. May also be useful for troubleshooting with verbs exposing some of the bastion status. The "add" verb may require some authentication of the client, which adds complexity, but perhaps it's useful operational flexibility to be able to trade maintaining a backend allowlist or a client allowlist?

Client to bastion request errors: Would it make sense to return different status codes for a backend that is unknown to the bastion (i.e., key hash not on the allowlist), and a backend that is configured but not currently connected? 503 Service unavailable might be reasonable for bastion errors, even though I don't see an obvious choice of when to return 502 and when to return 503.

[FiloSottile]

Backend to bastion: Probably obvious, since it terminates TLS, but this means that bastion needs to be exposed directly to the internet, in contrast to, e.g., operating behind a reverse proxy. Makes perfect sense for its purpose, but makes it less attractive to integrate the bastion function in a service that otherwise provides a plain web api that can sit behind a reverse proxy. My uses case would be the sigsum log server.

Correct, but bidirectional traffic over HTTP is hard to do, especially through a reverse proxy.

Backend auth: "The bastion checks the backend public key against an allowlist or verifies the client certificate chain." I don't get chain validation as an alternative to the public key allowlist. Are you thinking about an allowlist of x.509 names (rather than key hashes), with the names certified by any trusted web CA, or bastion operator running it's own CA signing the client certs of all allowed backends?

The latter, a bastion might want to run its own CA to avoid updating an allowlist any time a backend is added.

On bastion configuration, I wonder if there's some way to avoid maintaining an explicit allowlist. Is there any reasonable way to either be rather liberal in accepting backends, or have clients tell the bastion which backends they would like the bastion to serve?

Since the bastion effectively "hosts" content for the backend, I don't think we can be liberal.

Client to bastion requests: Would it make sense to add a verb to the request url, like

https://<bastion-host>/<verb>/<key hash>/<path>

For the main operation, verb would be "connect". The other operation I'm thinking about is "add", meaning please add this keyhash to the allowlist. May also be useful for troubleshooting with verbs exposing some of the bastion status. The "add" verb may require some authentication of the client, which adds complexity, but perhaps it's useful operational flexibility to be able to trade maintaining a backend allowlist or a client allowlist?

I don't think we can build a client authentication story since we've so far developed the witness protocol on the assumption that anyone can submit valid checkpoints.

Client to bastion request errors: Would it make sense to return different status codes for a backend that is unknown to the bastion (i.e., key hash not on the allowlist), and a backend that is configured but not currently connected? 503 Service unavailable might be reasonable for bastion errors, even though I don't see an obvious choice of when to return 502 and when to return 503.

Filed #72

[niels-moller]

Correct, but bidirectional traffic over HTTP is hard to do, especially through a reverse proxy.

I would expect it's possible to do some long-polling thing, but that would be a protocol rather different from what the bastion is doing. On a higher level, question is if backend-bastion protocol is built on top of TLS (current bastion protocol) or on top of plain HTTP(s) (would be a different beast).

So my only concrete suggesting is to point out clearer in the intro that while the bastion is plain HTTP(s) on its surface to clients, it's a something-else-over-TLS on the surface to backends. E.g., the client surface can easily coexist with other contents on a HTTPS server, on same IP and port 443. For the backend to coexist with a plain HTTPS service, one would need to insert some dispatch on the ALPN in incoming TLS connections, which sounds a bit hairy.