caution verify fetches attestation using unencrypted http #293

modalala commented 2026年06月15日 07:40:15 +02:00

during caution verify, unencrypted http is used on port 80 to connect, just after Requesting attestation... is printed.
To see this:

1. be logged into caution

2. checkout my http_demo branch which includes logging (and includes a cargo update)

3. run cargo clean && ./http_demo.sh

Though the nonce should protect against replay attacks, IIUC, an attacker could intercept the HTTP response and replace an attestation report with a modified or forged report, or, minimally, eavesdrop during verification.

Besides eavesdropping and DoS (dropping packets for attestation if in-line on the network path) I think this could lead to undesirable states like: a user can verify the deployed software is running somewhere, but not necessarily on the machine they are intending to connect with. That is, a user could unknowingly accept a report from an attacker's machine.

This is the line in the code I believe is hard-coding http, via this line that sets attestation_url, and later seeing the print from this line makes me believe self.verbose must be false (no error) and the received attestation must have been decoded.

I am not certain it is entirely relevant to this issue, but this IETF informational RFC document section 5.2 deals with "Prevention of Spoofing and Person-in-the-Middle Attacks" for attestation schemes.

during `caution verify`, unencrypted `http` is used on port 80 to connect, just after `Requesting attestation...` is printed. To see this: 1. be logged into `caution` 2. checkout [my http_demo branch](https://codeberg.org/modalala/platform/src/branch/http_demo) which includes logging (and includes a `cargo update`) 3. run `cargo clean && ./http_demo.sh` Though the nonce should protect against replay attacks, IIUC, an attacker could intercept the HTTP response and replace an attestation report with a modified or forged report, or, minimally, eavesdrop during verification. Besides eavesdropping and DoS (dropping packets for attestation if in-line on the network path) I think this could lead to undesirable states like: a user can verify the deployed software is running somewhere, but not necessarily on the machine they are intending to connect with. That is, a user could unknowingly accept a report from an attacker's machine. This is [the line in the code](https://codeberg.org/caution/platform/src/commit/40ecf936d28fabf20f95eab728f1dec1a1ffc540/src/cli/src/lib.rs#L4112) I believe is hard-coding `http`, via [this line](https://codeberg.org/caution/platform/src/commit/40ecf936d28fabf20f95eab728f1dec1a1ffc540/src/cli/src/lib.rs#L4688) that sets `attestation_url`, and later seeing the print from [this line](https://codeberg.org/caution/platform/src/commit/40ecf936d28fabf20f95eab728f1dec1a1ffc540/src/cli/src/lib.rs#L4743) makes me believe `self.verbose` must be false (no error) and the received attestation must have been decoded. I am not certain it is entirely relevant to this issue, but [this IETF informational RFC document](https://datatracker.ietf.org/doc/rfc9683/) section 5.2 deals with "Prevention of Spoofing and Person-in-the-Middle Attacks" for attestation schemes.

ryansquared commented 2026年06月15日 23:23:24 +02:00

There's a couple of trust models in play here:

1. You want to verify that the enclave you're connecting to is running the code they claim (caution verify).
2. You want to verify that the enclave you're connecting to is running the code you expect (caution verify --from-local).

Using HTTP could cause an issue with the first model, where someone intercepts the transmission and reroutes it to a different enclave. This means, under constraint 1, the only thing you are verifying is that you are connecting to "an enclave".

However, with model 2, you don't trust the external enclave when building your local enclave. If someone were able to reroute the nonce to a separate enclave running a different bit of code, you would get a PCR mismatch.

We do not consider HTTPS to be a significant security improvement, as if you could control traffic from the client to the enclave, you could also control traffic from the CA to the enclave, and get a TLS certificate from there. Furthermore, most TLS systems require a domain name, which is not a requirement we want to make of all enclaves.

There's a couple of trust models in play here: 1. You want to verify that the enclave you're connecting to is running the code *they claim* (`caution verify`). 2. You want to verify that the enclave you're connecting to is running the code *you expect* (`caution verify --from-local`). Using HTTP could cause an issue with the first model, where someone intercepts the transmission and reroutes it to a different enclave. This means, under constraint 1, the only thing you are verifying is that you are connecting to "an enclave". However, with model 2, you don't trust the external enclave when building your local enclave. If someone were able to reroute the nonce to a separate enclave running a different bit of code, you would get a PCR mismatch. We do not consider HTTPS to be a significant security improvement, as if you could control traffic from the client to the enclave, you could also control traffic from the CA to the enclave, and get a TLS certificate from there. Furthermore, most TLS systems require a domain name, which is not a requirement we want to make of all enclaves.