[MagicalTux]

The enclave fingerprint is generated as part of the attestation.

The way this works is the enclave on launch generates a ECDSA key (which only exists inside the enclave and is never stored or transmitted outside). It then passes it to SGX for attestation. SGX generates a payload (the attestation) which itself contains the enclave measured hash (MRENCLAVE) and other details about the CPU (microcode, BIOS, etc). The whole thing has a signature and a stamped certificate that is issued by Intel to the CPU (the CPU and Intel have an exchange at system startup and from times to times where Intel verifies the CPU security, ensures everything is up to date and gives the CPU a certificate).

Upon connection we extract the attestation from the TLS certificate and verify it (does MRENCLAVE match, is it signed by intel, is the certificate expired, etc) and also of course verify the TLS certificate itself matches the attested public key.

Unless TLS itself is broken or someone manages to exfiltrate the private key from the enclave (which should be impossible unless SGX is broken, but then Intel is supposed to not certify the CPU anymore) the connection is guaranteed to be with a host running the software in question.

[ranger_danger]

> the connection is guaranteed to be with a host running the software in question

a host... not necessarily the one actually serving your request at the moment, and doesn't prove that it's the only machine touching that data. And afaik this only proves the data in the enclave matches a key, and has nothing to do with "connections".

[MagicalTux]

Let me clarify, it guarantees your connection is being served by the enclave itself. The TLS encryption keys are kept inside the enclave, so whatever data is exchanged with the host, it can only be read from within the secure encrypted enclave.

[rasengan]

The attestation guarantees it's the one serving the request, and the encryption/decryption and NAT occurs inside the enclave so it's definitely private.