A privacy VPN you can verify • Hacker News Board

Re: A privacy VPN you can verify

#31

Post by rasengan » Sat, Aug 16, 2025, 1:18 AM UTC

ranger_danger wrote: post #25

MagicalTux wrote: post #19

Earlier quoted context omitted.

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 wh…

> 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".

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.

Re: A privacy VPN you can verify

#32

Post by MagicalTux » Sat, Aug 16, 2025, 1:19 AM UTC

exfil wrote: post #29

These VPN's for privacy are so bad. You give your credit card (verified identity), default gateway and payload to foreign soil and feel safe. On top of that your packets clear text metadata verifies you with cryptographic accuracy. In today's internet you just cannot have exit IP which is not tied either into your identity, payment information or physical location. And don't even mention TOR, pls.

You're welcome to use cryptocurrencies (we have a page for that), and our system only links your identity at connection time to ensure you have a valid subscription. Your traffic isn't tied to your identity, and you can look at the code to verify that.

Re: A privacy VPN you can verify

#33

Post by MagicalTux » Sat, Aug 16, 2025, 1:20 AM UTC

ranger_danger wrote: post #25

MagicalTux wrote: post #19

Earlier quoted context omitted.

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 wh…

> 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".

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.

Re: A privacy VPN you can verify

#34

Post by rasengan » Sat, Aug 16, 2025, 1:21 AM UTC

junon wrote: post #27

jchw wrote: post #14

Intel SGX/remote attestation for verifying that servers are running the code they say they are running is very interesting, I believe Signal talked about doing something similar for contact discovery, but at a base level it requires a lot of trust. How do I verify that the attestation I receive back is the one of the machine I am contacting? Can I know for sure that this isn't a compromised SGX configuration, since t…

> Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past? As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty. I would love to be wrong.

> Any network protocol can be spoofed, with varying degrees of difficulty.

Because of the cryptographic verifications, the communication cannot be spoofed.

Re: A privacy VPN you can verify

#35

Post by MagicalTux » Sat, Aug 16, 2025, 1:23 AM UTC

jchw wrote: post #26

MagicalTux wrote: post #22

Earlier quoted context omitted.

Intel will not attest insecure configurations. Our client will automatically verify the attestation it receives to make sure the certificate isn't expired and has a proper signature under Intel's CA trust. A lot of people have been attempting to attack SGX, and while there have been some successful attacks these have been addressed by Intel and resolved. Intel will not attest any insecure configuration as do other TE…

I really am interested in how this works. How can the client software verify that the SGX attestation actually is from the same machine as the VPN connection? I guess there's probably an answer here, but I don't know enough about SGX.

The way this works is by generating a private key inside the enclave and having the CPU attest its public key.

This allows generating a self signed TLS certificate that includes the attestation (under OID 1.3.6.1.4.1.311.105.1) and a client connecting verifying the TLS certificate not via the standard chain of trust, but by reading the attestion, verifying the attestation itself is valid (properly signed, matching measured values, etc) and verifying the containing TLS certificate is indeed signed with the attested key.

Intel includes a number of details inside the attestation, the most important being intel's own signature of the attestation and chain of trust to their CA.

Re: A privacy VPN you can verify

#36

Post by rasengan » Sat, Aug 16, 2025, 1:29 AM UTC

b8 wrote: post #23

They claim to allow anonymous sign up and payments, but requires an email,an account, zip code and name for Crypto payments, but fake info could be used I guess. I tried ordering via Crypto, but it constantly gives me this error: "Unable to load order information. Try again". Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel. Also VPN pr…

> Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel.

Relying on "trust" in a security/privacy architecture isn't the right way to do things - which is what this solves. It removes the need to trust in a person or person(s) in most VPN company cases since they have many employees, and moves it to trusting in code.

> Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.

The system is designed so that any change server side will be immediately noticed by clients/users. As a result, these issues are sufficiently mitigated, and instead, allows people to take advantage of strong consumer, and personal, protection laws in the US.

Re: A privacy VPN you can verify

#37

Post by MagicalTux » Sat, Aug 16, 2025, 1:33 AM UTC

remram wrote: post #16

What does the verifiable program do though? With a VPN, what I'm concerned about is my traffic not being sniffed and analyzed. This code seem to have something to do with keys but it's not clear how that helps...?

This is the server-side part of things. It receives encrypted traffic from your (and other customers) device, and routes it to the Internet.

This guarantees that your traffic isn't being linked to you, and is mixed up with others in a way that makes it difficult for someone to attribute it to you, as long as you also protect yourself on the application side (clear cookies, no tracking browser extension, etc)

Re: A privacy VPN you can verify

#38

Post by rasengan » Sat, Aug 16, 2025, 1:37 AM UTC

do_not_redeem wrote: post #18

> Build the code we published, get the fingerprint it produces, ask a VP.NET server for the fingerprint it reports, and compare the two. If they match, the server is running the exact code you inspected. No trust required. Okay, maybe I'm being thick, but... when I get a response from your server, how do I know it's actually running inside the enclave, and not an ordinary process sending a hardcoded expected fingerpr…

> how do I know it's actually running inside the enclave, and not an ordinary process sending a hardcoded expected fingerprint?

It's signed by Intel and thus, guaranteed to come from the enclave!

Re: A privacy VPN you can verify

#39

Post by stavros » Sat, Aug 16, 2025, 1:40 AM UTC

How does this attestation work? How can I be sure that this isn't just returning the fingerprint I expect without actually running in an enclave at all? Does Intel sign those messages?

Re: A privacy VPN you can verify

#40

Post by MagicalTux » Sat, Aug 16, 2025, 1:41 AM UTC

do_not_redeem wrote: post #18

> Build the code we published, get the fingerprint it produces, ask a VP.NET server for the fingerprint it reports, and compare the two. If they match, the server is running the exact code you inspected. No trust required. Okay, maybe I'm being thick, but... when I get a response from your server, how do I know it's actually running inside the enclave, and not an ordinary process sending a hardcoded expected fingerpr…

Intel SGX comes with an attestation process aiming at exactly that. The attestation contains a number of details, such as the hardware configuration (cpu microcode version, BIOS, etc) and the hash of the enclave code. At system startup the CPU gets a certificate from Intel confirming the configuration is known safe, which is used by the CPU to in turn certify the enclave is indeed running code with a given fingerprint.

When the connection is established we verify the whole certificate chain up to Intel, and we verify the TLS connection itself is part of the attestation (public key is attested).