Closed tiziano88 closed 2 years ago
The only advantage of the current setup is that it makes the client side library more realistic, simulating what it would encounter in a "real" environment with TLS enabled. But there is nothing Oak-specific that relies on that, in fact ideally the outer connection (gRPC or HTTP) would be passed in to the Oak client library, already established in some other way, i.e. I don't expect the Oak client library to create the connection in the first place.
@ipetr0v @conradgrobler let me know if you can think of any other reason why we should keep this (e.g. some future enhancement or use case)
We currently use HTTP (with rustls
) for loading lookup data from a URL:
https://github.com/project-oak/oak/blob/3dca7f2f8fab96c4fff7bf086a2736657fed2db5/oak_functions/loader/src/lookup_data.rs#L20
https://github.com/project-oak/oak/blob/3dca7f2f8fab96c4fff7bf086a2736657fed2db5/oak_functions/loader/src/lookup_data.rs#L182
So rustls
would still be in the TCB (unless we decide to only load lookup data from a file).
Thanks Ivan, that's a good point, I forgot about that. I think it's still useful to remove TLS from the serving stack for simplicity though, and we can see if it makes sense to remove the URL download feature in the future. We don't use it at the moment, but it may be useful again for other cloud providers, for instance.
Looks like we don't use TLS for creating a server in Oak Functions: https://github.com/project-oak/oak/blob/3dca7f2f8fab96c4fff7bf086a2736657fed2db5/oak_functions/loader/src/grpc.rs#L86-L100
Since we don't assing the TLS identity to it: https://docs.rs/tonic/0.1.0-alpha.1/tonic/transport/struct.Server.html#method.rustls_tls
And the default address for the Oak Functions client uses HTTP: https://github.com/project-oak/oak/blob/3dca7f2f8fab96c4fff7bf086a2736657fed2db5/oak_functions/client/rust/src/main.rs#L32
Also, since we use tonic
we automatically depend on rustls
:
https://github.com/hyperium/tonic/blob/a337f132a57dfcc262b70537cf31686519e0f73c/tonic/Cargo.toml#L81-L85
Those deps are optional, so we would not automatically depend on them, if we remote the TLS features.
I think this is not an issue any more.
In all cases, outer TLS termination would be handled by Cloud or something else, so it does not seem useful to have this added logic in our TCB for examples only.