Proof-of-concept for adding attested TLS server

[ameba23]

This shows where how i would imagine to integrate attested-tls server into the rproxy http proxy server.

Its proof of concept in that there is no error handling, and currently does not take any attestation configuration - just demonstrates how the pieces could fit together.

Also note this does not [currently] add nested TLS - it simply uses the TLS key and certificate from the config for attested TLS.

This compiles but is not tested. @0x416e746f6e whats the best way to test this - do you have some kind of test setup for rproxy?

I did a cargo update to get around some dependency conflicts. If you prefer i only update the directly relevant crates let me know.

Also worth noting - this introduces a dependency on openssl. Its not used by attested-tls directly but when retrieving collateral from PCCS during attestation verification via reqwest.

[0x416e746f6e]

question:

this doesn't seem to implement nested TLS (self-signed CA with attestation primitives stream inside public CA rooted TLS stream). instead it's either one or the other. am I correct?

[ameba23]

No, no. I didn't get that far. I first just want to establish that this works at all.

[ameba23]

i can confirm i successfully rproxied a request with this.

But one thing which bit me is that alloy_rpc_client::RpcClient (which i was using to test this) by default will omit the params field in the request JSON if it is empty (rather than adding "params": []). This causes the error data did not match any variant of untagged enum JrpcRequestMetaMaybeBatch. I needed to put in a serde_json::Value::Null to get it to add the field.

Next steps: Ideally i would like to write a unit test which demonstrates using attested-tls, To be able to iterate a bit faster and know it still works.