chore: replace cvm-reverse-proxy with attested-tls-proxy

[MoeMahhouk]

Summary

• Replace cvm-reverse-proxy with attested-tls-proxy for serving TDX attestation in bob images
• Install attested-tls-proxy v1.1.1 from pre-built .deb (with sha256 verification) instead of building cvm-reverse-proxy from source
• Uses self-signed TLS mode (no cert/key paths), which provides the same security model as cvm-reverse-proxy (attestation only, no cert auth)
• Port 8745 unchanged

Test plan

Local QEMU testing (no TDX, attestation type none):

Inside the VM, the server runs via systemd with these flags:
attested-tls-proxy server
--listen-addr 0.0.0.0:8745
--server-attestation-type auto
--allowed-remote-attestation-type none
127.0.0.1:5001

On the host, start the client:
attested-tls-proxy client
--listen-addr 127.0.0.1:9090
--allowed-remote-attestation-type none
--allow-self-signed
localhost:8745

Then fetch pubkeys through the full chain:
curl http://localhost:9090/pubkey

Production testing (Azure/GCP TDX VM, attestation type auto):

Server runs via systemd with --server-attestation-type auto (detects TDX hardware). On the client machine:
attested-tls-proxy client
--listen-addr 127.0.0.1:9090
--allowed-remote-attestation-type none
--allow-self-signed
<VM_IP>:8745

curl http://localhost:9090/pubkey

[ameba23]

Looks great.

One question - do we need to worry about the service needing access to /sys/kernel/config/tsm/report for DCAP attestation? Im not sure whether cvm-reverse-proxy needed this, but attested-tls-proxy definitely does on GCP.

The buildernet service explicitly adds it as a read-write path, presumably because otherwise the service could not access it:

flashbots-images/mkosi.images/buildernet-gcp/mkosi.extra/etc/systemd/system/attested-tls-proxy-client.service.d/gcp-override.conf

Lines 10 to 13 in a0e1841

	ProtectSystem=strict
	ProtectHome=yes
	AmbientCapabilities=CAP_DAC_OVERRIDE
	ReadWritePaths=/sys/kernel/config/tsm/report

[MoeMahhouk]

Looks great.

One question - do we need to worry about the service needing access to /sys/kernel/config/tsm/report for DCAP attestation? Im not sure whether cvm-reverse-proxy needed this, but attested-tls-proxy definitely does on GCP.

The buildernet service explicitly adds it as a read-write path, presumably because otherwise the service could not access it:

flashbots-images/mkosi.images/buildernet-gcp/mkosi.extra/etc/systemd/system/attested-tls-proxy-client.service.d/gcp-override.conf

Lines 10 to 13 in a0e1841

	ProtectSystem=strict
	ProtectHome=yes
	AmbientCapabilities=CAP_DAC_OVERRIDE
	ReadWritePaths=/sys/kernel/config/tsm/report

Good question!
I believe in Buildernet it was security hardened because it is not running as root but unprivileged dynamic user and mounting the filesystem as read-only. We could probably try to do similar enhancement here and test with it too.

Edit:
I'd recommend doing this hardening on another PR because this would require adding cloud-specific drop-in directories for both GCP and Azure profiles and testing each combination (L1<>gcp, l1<>azure, l2<>gcp) of them separately.

This PR, is just a drop-in replacement to cvm-reverse-proxy service which wasnt hardened before either.

Created an issue for it here #99 to track it