TEE: Eliminating Egress Liability and State-Actor Wiretaps via Networkless TEEs

[executed]

Description

Dstack allows direct no-VPN internet connection in terms of regular TDX compute instances.
It's worth remembering that LLM workloads share infrastructure with other potentially noisy tenants running regular TDX compute instances that can be rented anonymously.
What if one of the users exploits such infrastructure to harm a high-value target (e.g., 5-gon), prompting law enforcement to track down the data center from which the network traffic originated and start tampering with the hardware?
How could law enforcement wiretap Brave LLM users without anyone even noticing?
Well, it's a trivial task, especially for a state actor, particularly given that the instructions for this type of side-channel attack are already laid out in academic papers.

Click to explore scenario and tools

I call it the Honeypot Scenario.
• Any user on Dstack-powered infrastructure (e.g., Phala, NearAI) messes with a high-value target (e.g., 5-gon), either through automation or, even unintentionally, by deploying a sophisticated LLM agent. Reasonable network controls on Dstack side would not stop the attack as malicous actor may utilize sophisticated VPN tunnels (e.g. AmneziaWG - fork of wireguard) while intentionally leaking the the original genuine datacenter IP address and maybe even couple of machine IDs (PPID).
• Law enforcement traces malicious traffic back to the Dstack/Phala datacenter. The intent may be a genuine one to find the malicious actor. Or it may be that law enforcement was the malicous actor itself just simulating a situation that would guarantee them a court order to target particular datacenter.
• They raid the datacenter, attach a $200 DDR5 interposer, and extract the master key (PCK), using a Tee dot Fail / DDRop-style side-channel attack.
• They follow detailed, academic-grade instructions on how to build and operate the interposer, as well as how to use it to fake TDX attestations that are assumed to guarantee security integrity.
• A state actor can even scale this to as many instances as needed, all sharing the same valid hardware ID or as many valid hardware IDs as needed.
• The datacenter announces a "temporary outage" and brings the nodes back online, apologizing for the inconvenience and asking clients to reconnect.
• Clients see the exact same machine ID (PPID), with a valid, up-to-date TDX attestation that is even verifiable against the Proof Of Cloud whitelist of trusted compute providers.
• Clients establish a TLS session and continue sharing their highly sensitive data.
• Little do clients know that those machines are now honeypots. All requests are running in plaintext. SSL termination now happens not inside the enclave, but wherever the state actor decides the data should be decrypted.
• Depending on how determined the state actor is, some, most, or all machines in the datacenter are being wiretapped.

Now all of a sudden not only the malicous user, but also other genuine users are on the tape without no one even noticing.

Suggested Solution

Although non-trivial, I suggest implementing a mandatory "Networkless / Sealed Calculator" mode for Dstack workloads that share the same DC as LLM workloads (at least), heavily inspired by the AWS Nitro Enclaves architecture, but taken a step further.

The Proposed Architecture:

• Zero Egress by Default: The TDX instance is provisioned with absolutely zero direct internet access or outbound network interfaces.
• Client-Routed Egress: All necessary network I/O is routed over an encrypted tunnel (via a virtual socket) back to a client-controlled gateway.
• High-Availability Client Gateway: The client deploys its own high-availability router (e.g., an AWS instance running an obfuscated WireGuard tunnel to a VPN provider of choice). The client handles all internet routing from there.

Why this benefits the compute provider:

• Reduced Egress Liability: The compute provider is no longer acting as a proxy or ISP. Legal liabilities associated with routing all the traffic strictly through VPN, which is another potential solution, are completely bypassed. Otherwise, this could effectively resemble illegal bulletproof hosting.
• Physical DC Protection: If a malicious tenant uses this setup for illegal activity, investigators trace the attack back to the VPN exit node or the client's self-hosted gateway. Forensic evidence pointing to the physical Dstack/Phala data center are limited, reducing the likelihood of a court order being issued in the first place.
• Preserving Confidentiality: By entirely decoupling the egress IP from the compute hardware, you ensure that one malicious user cannot cause the physical compromise and wiretapping of other innocent tenants sharing the same data center.

It turns the compute provider into a pure, liability-free "encrypted state transition machine.".

Yes, it's a significant architectural and philosophical shift. However, without such safeguards, one malicious actor could put many legitimate users at risk of being wiretapped without their knowledge.

"Eliminating Egress Liability" complements the main objective of the suggested "Code and Location Verification" because it mitigates the potential compromization motive of a "Tier-1" cloud compute provider.
As the result Dstack maintainers no longer have opportunity to fake TDX attestations driven by financial incentive.

[executed]

Response from maintainer Leechael Yim so far (not taking into account suggested solution as it was suggested after response):

"This is an inherent problem every cloud provider faces, and the risk is real. The premise of confidential computing is that the platform cannot see or decrypt customer data — that's the value proposition, but it also means we can't tell what a customer is actually doing based on content.

So controls have to live at the network and contract layers: egress traffic analysis, anomaly detection (scanning, brute-forcing, DDoS), rate limits and port policy on the network side; identity verification, AUP/ToS, and fast suspension on the account side — to isolate a single bad actor before it escalates. Whether to allow direct internet access at all is a policy choice: it can be off by default, opt-in, or restricted egress.

To be clear, we can't reduce this risk to zero — in a serious incident, hardware seizure can't be fully ruled out, which is exactly why we keep visibility and enforcement at the network layer. That's the real meaning of "confidential": the platform doesn't snoop on data, and the trade-off is that content-based moderation is off the table.".