From 8b9c7ece6086522ae78134d6086f259e72635b41 Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 10:28:13 +0100 Subject: [PATCH 1/8] Explain measurements file --- README.md | 63 +++++++++++++++++++++++++++++++---- test-assets/measurements.json | 2 +- 2 files changed, 57 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 8e9b9f3..a369358 100644 --- a/README.md +++ b/README.md @@ -3,18 +3,66 @@ This is a work-in-progress crate designed to be an alternative to [`cvm-reverse-proxy`](https://github.com/flashbots/cvm-reverse-proxy). -It has three commands: -- `server` - run a proxy server, which accepts TLS connections from a proxy client, sends an attestation and then forwards traffic to a target CVM service. -- `client` - run a proxy client, which accepts connections from elsewhere, connects to and verifies the attestation from the proxy server, and then forwards traffic to it over TLS. -- `get-tls-cert` - connects to a proxy-server, verify the attestation, and if successful write the server's PEM-encoded TLS certificate chain to standard out. This can be used to make subsequent connections to services using this certificate over regular TLS. +It has three subcommands: +- `attested-tls-proxy server` - run a proxy server, which accepts TLS connections from a proxy client, sends an attestation and then forwards traffic to a target CVM service. +- `attested-tls-proxy client` - run a proxy client, which accepts connections from elsewhere, connects to and verifies the attestation from the proxy server, and then forwards traffic to it over TLS. +- `attested-tls-proxy get-tls-cert` - connects to a proxy-server, verify the attestation, and if successful write the server's PEM-encoded TLS certificate chain to standard out. This can be used to make subsequent connections to services using this certificate over regular TLS. Unlike `cvm-reverse-proxy`, this uses post-handshake remote-attested TLS, meaning regular CA-signed TLS certificates can be used. -This repo shares some code with [ameba23/attested-channels](https://github.com/ameba23/attested-channels) and may eventually be merged with that crate. -## Measurement headers +### Overview -When attestation is validated successfully, the following values are injected into the request / response headers: +This is a reverse HTTP proxy allowing a normal HTTP client to communicate with a normal HTTP server over a remote-attested TLS channel, by tunneling requests through a proxy-client and proxy-server. + +This works as follows: +1. The source HTTP client (eg: curl or a web browser) makes an HTTP request to a proxy-client instance running locally. +2. The proxy-client forwards the request to a proxy-server instance over a remote-attested TLS channel. +3. The proxy-server forwards the request to the target service over regular HTTP. +4. The response from the target service is sent back to the source client, via the proxy-server and proxy-client. + +One or both of the proxy-client and proxy-server may be running in a confidential environment and provide attestations which will be verified by the remote party. Verification is configured by a measurements file, and attestation generation is configured by specifying an attestation type when starting the proxy client or server. + +### Measurements File + +Accepted measurements for the remote party are specified in a JSON file containing an array of objects, each of which specifies an accepted attestation type and set of measurements. + +These object have the following fields: +- `measurement_id` - a name used to describe the entry. For example the name and version of the CVM OS image that these measurements correspond to. +- `attestation_type` - one of the attestation types (confidential computing platforms) described below. +- `measurements` - an object with fields referring to the five measurement registers. + +Example: + +```JSON +[ + { + "measurement_id": "dcap-tdx-example", + "attestation_type": "dcap-tdx", + "measurements": { + "0": { + "expected": "47a1cc074b914df8596bad0ed13d50d561ad1effc7f7cc530ab86da7ea49ffc03e57e7da829f8cba9c629c3970505323" + }, + "1": { + "expected": "da6e07866635cb34a9ffcdc26ec6622f289e625c42c39b320f29cdf1dc84390b4f89dd0b073be52ac38ca7b0a0f375bb" + }, + "2": { + "expected": "a7157e7c5f932e9babac9209d4527ec9ed837b8e335a931517677fa746db51ee56062e3324e266e3f39ec26a516f4f71" + }, + "3": { + "expected": "e63560e50830e22fbc9b06cdce8afe784bf111e4251256cf104050f1347cd4ad9f30da408475066575145da0b098a124" + }, + "4": { + "expected": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" + } + } + } +] +``` + +### Measurement Headers + +When attestation is validated successfully, the following values are injected into the request / response headers making them available to the source client and/or target service: Header name: `X-Flashbots-Measurement` @@ -37,3 +85,4 @@ One of `none`, `dummy`, `azure-tdx`, `qemu-tdx`, `gcp-tdx`. These aim to match the header formatting used by `cvm-reverse-proxy`. +## Protocol Specification diff --git a/test-assets/measurements.json b/test-assets/measurements.json index 7821018..f7714b7 100644 --- a/test-assets/measurements.json +++ b/test-assets/measurements.json @@ -1,6 +1,6 @@ [ { - "measurement_id": "dcap-tdx-dummy", + "measurement_id": "dcap-tdx-example", "attestation_type": "dcap-tdx", "measurements": { "0": { From babfeb964667624e09c4e4098810b91f65872b0f Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 11:58:07 +0100 Subject: [PATCH 2/8] Document protocol --- README.md | 46 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index a369358..4768c94 100644 --- a/README.md +++ b/README.md @@ -2,16 +2,14 @@ # `attested-tls-proxy` This is a work-in-progress crate designed to be an alternative to [`cvm-reverse-proxy`](https://github.com/flashbots/cvm-reverse-proxy). +Unlike `cvm-reverse-proxy`, this uses post-handshake remote-attested TLS, meaning regular CA-signed TLS certificates can be used. It has three subcommands: - `attested-tls-proxy server` - run a proxy server, which accepts TLS connections from a proxy client, sends an attestation and then forwards traffic to a target CVM service. - `attested-tls-proxy client` - run a proxy client, which accepts connections from elsewhere, connects to and verifies the attestation from the proxy server, and then forwards traffic to it over TLS. - `attested-tls-proxy get-tls-cert` - connects to a proxy-server, verify the attestation, and if successful write the server's PEM-encoded TLS certificate chain to standard out. This can be used to make subsequent connections to services using this certificate over regular TLS. -Unlike `cvm-reverse-proxy`, this uses post-handshake remote-attested TLS, meaning regular CA-signed TLS certificates can be used. - - -### Overview +### How it works This is a reverse HTTP proxy allowing a normal HTTP client to communicate with a normal HTTP server over a remote-attested TLS channel, by tunneling requests through a proxy-client and proxy-server. @@ -27,10 +25,12 @@ One or both of the proxy-client and proxy-server may be running in a confidentia Accepted measurements for the remote party are specified in a JSON file containing an array of objects, each of which specifies an accepted attestation type and set of measurements. +This aims to match the formatting used by `cvm-reverse-proxy`. + These object have the following fields: - `measurement_id` - a name used to describe the entry. For example the name and version of the CVM OS image that these measurements correspond to. -- `attestation_type` - one of the attestation types (confidential computing platforms) described below. -- `measurements` - an object with fields referring to the five measurement registers. +- `attestation_type` - a string containing one of the attestation types (confidential computing platforms) described below. +- `measurements` - an object with fields referring to the five measurement registers. Field names are the same as for the measurement headers (see below). Example: @@ -60,9 +60,13 @@ Example: ] ``` +If a path to this file is not given or it contains an empty array, **any** attestation type and **any** measurements will be accepted, **including no attestation**. The measurements can still be checked up-stream by the source client or target service using header injection described below. But it is then up to these external programs to reject unacceptable configurations. + ### Measurement Headers -When attestation is validated successfully, the following values are injected into the request / response headers making them available to the source client and/or target service: +When attestation is validated successfully, the following headers are injected into the HTTP request / response making them available to the source client and/or target service. + +These aim to match the header formatting used by `cvm-reverse-proxy`. Header name: `X-Flashbots-Measurement` @@ -79,10 +83,32 @@ Header value: Header name: `X-Flashbots-Attestation-Type` -Header value: +Header value: an attestation type given as a string as described below. + +## Attestation Types -One of `none`, `dummy`, `azure-tdx`, `qemu-tdx`, `gcp-tdx`. +These are the attestation type names used in the HTTP headers, and the measurements file, and when specifying a local attestation type with the `--client-attestation-type` or `--server-attestation-type` command line options. -These aim to match the header formatting used by `cvm-reverse-proxy`. +- `none` - No attestation provided +- `dummy` - Forwards the attestation to a remote service (for testing purposes, not yet supported) +- `gcp-tdx` - DCAP TDX on Google Cloud Platform +- `azure-tdx` - TDX on Azure, with MAA (not yet supported) +- `qemu-tdx` - TDX on Qemu (no cloud platform) +- `dcap-tdx` - DCAP TDX (platform not specified) ## Protocol Specification + +A proxy-client client will immediately attempt to connect to the given proxy-server. + +Proxy-client to proxy-server connections use TLS 1.3. + +The protocol name `flashbots-ratls/1` must be given in the TLS configuration for ALPN protocol negotiation during the TLS handshake. Future versions of this protocol will use incrementing version numbers, eg: `flashbots-ratls/2`. + +Immediately after the TLS handshake, an attestation exchange is made. The server first provides an attestation message (even if it has the `none` attestation type). The client verifies, if verification is successful it also provides an attestation message and otherwise closes the connection. If the server cannot verify the client's attestation, it closes the connection. + +Attestation messages are formatted as follows: +- A 4 byte length prefix - a big endian encoded unsigned 32 bit integer +Simple Concatenated Aggregate Little-Endian +Following a successful attestation exchange, the client can make HTTP requests using HTTP2, and the server will forward them to the target service. + +As described above, the server will inject measurement data into the request headers before forwarding them to the target service, and the client will inject measurement data into the response headers before forwarding them to the source client. From 7a2da2788a3b71773d1ec8e11baa2ef1702da945 Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 12:35:56 +0100 Subject: [PATCH 3/8] Add detail to protocol spec --- README.md | 26 ++++++++++++++++++++++++-- src/attestation/mod.rs | 12 ++++++------ src/lib.rs | 24 ++++++++++++------------ 3 files changed, 42 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 4768c94..3f0a419 100644 --- a/README.md +++ b/README.md @@ -104,11 +104,33 @@ Proxy-client to proxy-server connections use TLS 1.3. The protocol name `flashbots-ratls/1` must be given in the TLS configuration for ALPN protocol negotiation during the TLS handshake. Future versions of this protocol will use incrementing version numbers, eg: `flashbots-ratls/2`. +### Attestation Exchange + Immediately after the TLS handshake, an attestation exchange is made. The server first provides an attestation message (even if it has the `none` attestation type). The client verifies, if verification is successful it also provides an attestation message and otherwise closes the connection. If the server cannot verify the client's attestation, it closes the connection. -Attestation messages are formatted as follows: +Attestation exchange messages are formatted as follows: - A 4 byte length prefix - a big endian encoded unsigned 32 bit integer -Simple Concatenated Aggregate Little-Endian +- A SCALE (Simple Concatenated Aggregate Little-Endian) encoded [struct](./src/attestation/mod.rs) with the following fields: + - Attestation type - a string with one of the attestation types (described above) including `none`. + - Attestation - the actual attestation data. In the case of DCAP this is a binary quote report. In the case of `none` this is an empty byte array. + +SCALE is used by parity/substrate and was chosen because it is simple and actually matches the formatting used in TDX quotes. So it was already used as a dependency (of the `dcap-qvl` crate) here. + +## Attestation Generation and Verification + +Attestation input takes the form of a 64 byte array. + +The first 32 bytes are the SHA256 hash of the encoded public key from the TLS leaf certificate of the party providing the attestation, DER encoded exactly as given in the certificate. + +The remaining 32 bytes are exported key material ([RFC5705](https://www.rfc-editor.org/rfc/rfc5705)) from the TLS session. This must have the exporter label `EXPORTER-Channel-Binding` and no context data. + +In the case of attestation types `dcap-tx`, `gcp-tdx`, and `qemu-tdx`, a standard DCAP attestation is generated using the `configfs-tsm` linux filesystem interface. This means that this binary must be run with access to `/sys/kernel/config/tsm/report` which on many systems requires sudo. + +When verifying DCAP attestations, the Intel PCS is used to retrieve collateral unless a PCCS url is provided via a command line argument. If expired TCB collateral is provided, the quote will fail to verify. + +## HTTP reverse proxy + Following a successful attestation exchange, the client can make HTTP requests using HTTP2, and the server will forward them to the target service. As described above, the server will inject measurement data into the request headers before forwarding them to the target service, and the client will inject measurement data into the response headers before forwarding them to the source client. + diff --git a/src/attestation/mod.rs b/src/attestation/mod.rs index 0cb9b0e..e89df1d 100644 --- a/src/attestation/mod.rs +++ b/src/attestation/mod.rs @@ -25,14 +25,14 @@ const PCS_URL: &str = "https://api.trustedservices.intel.com"; /// This is the type sent over the channel to provide an attestation #[derive(Debug, Serialize, Deserialize, Encode, Decode)] -pub struct AttesationPayload { +pub struct AttestationExchangeMessage { /// What CVM platform is used (including none) pub attestation_type: AttestationType, /// The attestation evidence as bytes - in the case of DCAP this is a quote pub attestation: Vec, } -impl AttesationPayload { +impl AttestationExchangeMessage { /// Given an attestation generator (quote generation function for a specific platform) /// return an attestation /// This also takes the certificate chain and exporter as they are given as input to the attestation @@ -185,16 +185,16 @@ impl AttestationVerifier { /// Verify an attestation, and ensure the measurements match one of our accepted measurements pub async fn verify_attestation( &self, - attestation_payload: AttesationPayload, + attestation_exchange_message: AttestationExchangeMessage, cert_chain: &[CertificateDer<'_>], exporter: [u8; 32], ) -> Result, AttestationError> { - let attestation_type = attestation_payload.attestation_type; + let attestation_type = attestation_exchange_message.attestation_type; let measurements = match attestation_type { AttestationType::DcapTdx => { verify_dcap_attestation( - attestation_payload.attestation, + attestation_exchange_message.attestation, cert_chain, exporter, self.pccs_url.clone(), @@ -202,7 +202,7 @@ impl AttestationVerifier { .await? } AttestationType::None => { - if attestation_payload.attestation.is_empty() { + if attestation_exchange_message.attestation.is_empty() { return Ok(None); } else { return Err(AttestationError::AttestationGivenWhenNoneExpected); diff --git a/src/lib.rs b/src/lib.rs index 9bb9105..6fdbfdb 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -28,7 +28,7 @@ use tokio_rustls::{ TlsAcceptor, TlsConnector, }; -use crate::attestation::{AttesationPayload, AttestationVerifier}; +use crate::attestation::{AttestationExchangeMessage, AttestationVerifier}; /// This makes it possible to add breaking protocol changes and provide backwards compatibility. /// When adding more supported versions, note that ordering is important. ALPN will pick the first @@ -204,7 +204,7 @@ impl ProxyServer { let remote_cert_chain = connection.peer_certificates().map(|c| c.to_owned()); // If we are in a CVM, generate an attestation - let attestation = AttesationPayload::from_attestation_generator( + let attestation = AttestationExchangeMessage::from_attestation_generator( &cert_chain, exporter, local_quote_generator, @@ -225,14 +225,14 @@ impl ProxyServer { let mut buf = vec![0; length]; tls_stream.read_exact(&mut buf).await?; - let remote_attestation_payload = AttesationPayload::decode(&mut &buf[..])?; - let remote_attestation_type = remote_attestation_payload.attestation_type; + let remote_attestation_message = AttestationExchangeMessage::decode(&mut &buf[..])?; + let remote_attestation_type = remote_attestation_message.attestation_type; // If we expect an attestaion from the client, verify it and get measurements let measurements = if attestation_verifier.has_remote_attestion() { attestation_verifier .verify_attestation( - remote_attestation_payload, + remote_attestation_message, &remote_cert_chain.ok_or(ProxyError::NoClientAuth)?, exporter, ) @@ -623,24 +623,24 @@ impl ProxyClient { let mut buf = vec![0; length]; tls_stream.read_exact(&mut buf).await?; - let remote_attestation_payload = AttesationPayload::decode(&mut &buf[..])?; - let remote_attestation_type = remote_attestation_payload.attestation_type; + let remote_attestation_message = AttestationExchangeMessage::decode(&mut &buf[..])?; + let remote_attestation_type = remote_attestation_message.attestation_type; // Verify the remote attestation against our accepted measurements let measurements = attestation_verifier - .verify_attestation(remote_attestation_payload, &remote_cert_chain, exporter) + .verify_attestation(remote_attestation_message, &remote_cert_chain, exporter) .await?; // If we are in a CVM, provide an attestation let attestation = if local_quote_generator.attestation_type() != AttestationType::None { - AttesationPayload::from_attestation_generator( + AttestationExchangeMessage::from_attestation_generator( &cert_chain.ok_or(ProxyError::NoClientAuth)?, exporter, local_quote_generator, )? .encode() } else { - AttesationPayload::without_attestation().encode() + AttestationExchangeMessage::without_attestation().encode() }; // Send our attestation (or zero bytes) prefixed with length @@ -722,10 +722,10 @@ async fn get_tls_cert_with_config( let mut buf = vec![0; length]; tls_stream.read_exact(&mut buf).await?; - let remote_attestation_payload = AttesationPayload::decode(&mut &buf[..])?; + let remote_attestation_message = AttestationExchangeMessage::decode(&mut &buf[..])?; let _measurements = attestation_verifier - .verify_attestation(remote_attestation_payload, &remote_cert_chain, exporter) + .verify_attestation(remote_attestation_message, &remote_cert_chain, exporter) .await?; Ok(remote_cert_chain) From 26c80da974cf25bda01ab48813114cec05256fb9 Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 12:38:43 +0100 Subject: [PATCH 4/8] Fix heading levels --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 3f0a419..2db4b6e 100644 --- a/README.md +++ b/README.md @@ -85,7 +85,7 @@ Header name: `X-Flashbots-Attestation-Type` Header value: an attestation type given as a string as described below. -## Attestation Types +### Attestation Types These are the attestation type names used in the HTTP headers, and the measurements file, and when specifying a local attestation type with the `--client-attestation-type` or `--server-attestation-type` command line options. @@ -116,7 +116,7 @@ Attestation exchange messages are formatted as follows: SCALE is used by parity/substrate and was chosen because it is simple and actually matches the formatting used in TDX quotes. So it was already used as a dependency (of the `dcap-qvl` crate) here. -## Attestation Generation and Verification +### Attestation Generation and Verification Attestation input takes the form of a 64 byte array. @@ -128,7 +128,7 @@ In the case of attestation types `dcap-tx`, `gcp-tdx`, and `qemu-tdx`, a standar When verifying DCAP attestations, the Intel PCS is used to retrieve collateral unless a PCCS url is provided via a command line argument. If expired TCB collateral is provided, the quote will fail to verify. -## HTTP reverse proxy +### HTTP reverse proxy Following a successful attestation exchange, the client can make HTTP requests using HTTP2, and the server will forward them to the target service. From 76128d8b18c36dfd71ed8c9a73e4d23606c06e3a Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 12:42:44 +0100 Subject: [PATCH 5/8] Minor edit to readme --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 2db4b6e..5b45e7d 100644 --- a/README.md +++ b/README.md @@ -111,8 +111,8 @@ Immediately after the TLS handshake, an attestation exchange is made. The server Attestation exchange messages are formatted as follows: - A 4 byte length prefix - a big endian encoded unsigned 32 bit integer - A SCALE (Simple Concatenated Aggregate Little-Endian) encoded [struct](./src/attestation/mod.rs) with the following fields: - - Attestation type - a string with one of the attestation types (described above) including `none`. - - Attestation - the actual attestation data. In the case of DCAP this is a binary quote report. In the case of `none` this is an empty byte array. + - `attestation_type` - a string with one of the attestation types (described above) including `none`. + - `attestation` - the actual attestation data. In the case of DCAP this is a binary quote report. In the case of `none` this is an empty byte array. SCALE is used by parity/substrate and was chosen because it is simple and actually matches the formatting used in TDX quotes. So it was already used as a dependency (of the `dcap-qvl` crate) here. From b83c2cbb8de5193324b5828fcc843c43ee2a10dd Mon Sep 17 00:00:00 2001 From: peg Date: Thu, 20 Nov 2025 12:44:11 +0100 Subject: [PATCH 6/8] Minor edit to readme --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5b45e7d..a82b5ce 100644 --- a/README.md +++ b/README.md @@ -114,7 +114,7 @@ Attestation exchange messages are formatted as follows: - `attestation_type` - a string with one of the attestation types (described above) including `none`. - `attestation` - the actual attestation data. In the case of DCAP this is a binary quote report. In the case of `none` this is an empty byte array. -SCALE is used by parity/substrate and was chosen because it is simple and actually matches the formatting used in TDX quotes. So it was already used as a dependency (of the `dcap-qvl` crate) here. +SCALE is used by parity/substrate and was chosen because it is simple and actually matches the formatting used in TDX quotes. So it was already used as a dependency (via the [`dcap-qvl`](https://docs.rs/dcap-qvl) crate). ### Attestation Generation and Verification From 88a0c019789812c21253eb73924e84194daa2a07 Mon Sep 17 00:00:00 2001 From: peg Date: Mon, 24 Nov 2025 10:14:18 +0100 Subject: [PATCH 7/8] Typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a82b5ce..d09f840 100644 --- a/README.md +++ b/README.md @@ -124,7 +124,7 @@ The first 32 bytes are the SHA256 hash of the encoded public key from the TLS le The remaining 32 bytes are exported key material ([RFC5705](https://www.rfc-editor.org/rfc/rfc5705)) from the TLS session. This must have the exporter label `EXPORTER-Channel-Binding` and no context data. -In the case of attestation types `dcap-tx`, `gcp-tdx`, and `qemu-tdx`, a standard DCAP attestation is generated using the `configfs-tsm` linux filesystem interface. This means that this binary must be run with access to `/sys/kernel/config/tsm/report` which on many systems requires sudo. +In the case of attestation types `dcap-tdx`, `gcp-tdx`, and `qemu-tdx`, a standard DCAP attestation is generated using the `configfs-tsm` linux filesystem interface. This means that this binary must be run with access to `/sys/kernel/config/tsm/report` which on many systems requires sudo. When verifying DCAP attestations, the Intel PCS is used to retrieve collateral unless a PCCS url is provided via a command line argument. If expired TCB collateral is provided, the quote will fail to verify. From 6f7e1564c360b3cb06cedaed95a6998d4cf5343b Mon Sep 17 00:00:00 2001 From: peg Date: Mon, 24 Nov 2025 10:20:43 +0100 Subject: [PATCH 8/8] Additional clarification of connection reuse --- README.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index d09f840..cfed2a5 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,13 @@ # `attested-tls-proxy` -This is a work-in-progress crate designed to be an alternative to [`cvm-reverse-proxy`](https://github.com/flashbots/cvm-reverse-proxy). +This is a reverse HTTP proxy allowing a normal HTTP client to communicate with a normal HTTP server over a remote-attested TLS channel, by tunneling requests through a proxy-client and proxy-server. + +This work-in-progress crate is designed to be an alternative to [`cvm-reverse-proxy`](https://github.com/flashbots/cvm-reverse-proxy). Unlike `cvm-reverse-proxy`, this uses post-handshake remote-attested TLS, meaning regular CA-signed TLS certificates can be used. +The proxy-client, on starting, immediately connects to the proxy-server and an attestation-verification exchange is made. This attested-TLS channel is then re-used for all requests from that proxy-client instance. + It has three subcommands: - `attested-tls-proxy server` - run a proxy server, which accepts TLS connections from a proxy client, sends an attestation and then forwards traffic to a target CVM service. - `attested-tls-proxy client` - run a proxy client, which accepts connections from elsewhere, connects to and verifies the attestation from the proxy server, and then forwards traffic to it over TLS. @@ -11,7 +15,6 @@ It has three subcommands: ### How it works -This is a reverse HTTP proxy allowing a normal HTTP client to communicate with a normal HTTP server over a remote-attested TLS channel, by tunneling requests through a proxy-client and proxy-server. This works as follows: 1. The source HTTP client (eg: curl or a web browser) makes an HTTP request to a proxy-client instance running locally.