Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A privacy VPN you can verify

vp.net

Post reply on HN
Print view View original

61–70 of 160 posts

Re: A privacy VPN you can verify

#61

Post by kachapopopow »

MagicalTux wrote: post #45
stavros wrote: post #39

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?

Similar to TLS, the attestation includes a signature and a x509 certificate with a chain of trust to Intel's CA. The whole attestation is certified by Intel to be valid and details such as the enclave fingerprint (MRENCLAVE) are generated by the CPU to be part of the attestation. This whole process is already widely used in financial and automotive sectors to ensure servers are indeed running what they claim to be ru…

Remember that this only works if the cpu can be trusted! The hardware still has to be secure.

Re: A privacy VPN you can verify

#62

Post by kachapopopow »

gmlenovo22 wrote: post #54

I don't buy this. They could run one secure enclave runningng the legit version of code and one insecure hardware running insecure software. Then they put a load balancer in front of both. When people ask for the attestation the LB sends traffic to the secure enclave, so you get the attestation back and all seems good. When people send vpn traffic the loadbalancer sends them to the insecure hardware with insecure sof…

That's not what they;re trying to prove. Only one server is give the certificate to authenticate with you, you connect to that server, every message with that server is authenticated with that certificate.

They are proving that they are the ones hosting the VPN server - not some server that stole their software and are running a honeypot and that the hosting company has not tampered with it.

So in the end you still have to trust the company that they are not sharing the certificates with 3rd parties.

Re: A privacy VPN you can verify

#63

Post by saurik »

MagicalTux wrote: post #37
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)

(First off, duskwuff's attack is pretty epic. I do feel like there might be a way to ensure there is only exactly one giant server--not that that would scale well--but, it also sounds like you didn't deal with it ;P. The rest of my comment is going to assume that you only have a single instance.)

A packet goes in to your server and a packet goes out of your server: the code managing the enclave can just track this (and someone not even on the same server can figure this out almost perfectly just by timing analysis). What are you, thereby, actually mixing up in the middle?

You can add some kind of probably-small (as otherwise TCP will start to collapse) delay, but that doesn't really help as people are sending a lot of packets from their one source to the same destination, so the delay you add is going to be over some distribution that I can statistics out.

You can add a ton of cover traffic to the server, but each interesting output packet is still going to be able to be correlated with one input packet, and the extra input packets aren't really going to change that. I'd want to see lots of statistics showing you actually obfuscated something real.

The only thing you can trivially do is prove that you don't know which valid paying user is sending you the packets (which is also something that one could think might be of value even if you did have a separate copy of the server running for every user that connected, as it hides something from you)...

...but, SGX is, frankly, a dumb way to do that, as we have ways to do that that are actually cryptographically secure -- aka, blinded tokens (the mechanism used in Privacy Pass for IP reputation and Brave for its ad rewards) -- instead of relying on SGX (which not only is, at best, something we have to trust Intel on, but something which is routinely broken).

Re: A privacy VPN you can verify

#64

Post by nneonneo »

Cute idea. Bit worried about the owners here; rasengan doesn't have a stellar reputation after what happened with Freenode.

The idea itself is sound: if there are no SGX bypasses (hardware keys dumped, enclaves violated, CPU bugs exploited, etc.), and the SGX code is sound (doesn't leak the private keys by writing them to any non-confidential storage, isn't vulnerable to timing-based attacks, etc.), and you get a valid, up-to-date attestation containing the public key that you're encrypting your traffic with plus a hash of a trustworthy version of the SGX code, then you can trust that your traffic is indeed being decrypted inside an SGX enclave which has exclusive access to the private key.

Obviously, that's a lot of conditions. Happily, you can largely verify those conditions given what's provided here; you can check that the attestation points to a CPU and configuration new enough to not have any (known) SGX breaks; you can check that the SGX code is sound and builds to the provided hash (exercise left to the reader); and you can check the attestation itself as it is signed with hardware keys that chain up to an Intel root-of-trust.

However! An SGX enclave cannot interface with the system beyond simple shared memory input/output. In particular, an SGX enclave is not (and cannot be) responsible for socket communication; that must be handled by an OS that lies outside the SGX TCB (Trusted Computing Base). For typical SGX use-cases, this is OK; the data is what is secret, and the socket destinations are not.

For a VPN, this is not true! The OS can happily log anything it wants! There's nothing stopping it from logging all the data going into and out of the SGX enclave and performing traffic correlation. Even with traffic mixing, there's nothing stopping the operators from sticking a single user onto their own, dedicated SGX enclave which is closely monitored; traffic mixing means nothing if its just a single user's traffic being mixed.

So, while the use of SGX here is a nice nod to privacy, at the end of the day, you still have to decide whether to trust the operators, and you still cannot verify in an end-to-end way whether the service is truly private.

Re: A privacy VPN you can verify

#65

Post by victorbjorklund »

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.

Mullvad VPN allows you to pay with cash in an envelop with no name etc

Re: A privacy VPN you can verify

#67

Post by tavavex »

lcnPylGDnU4H9OF wrote: post #55
kwanbix wrote: post #47

Earlier quoted context omitted.

So what do you suggest instead?

Semi-serious: redeemable codes you can buy at a national retail chain, ostensibly using cash. It has the unfortunate side effect of training people to fall for scams, however. Bonus points if you can somehow make the codes worthless on the black market, I guess.

Some VPNs kind of offer that. I know at least one that sells physical redeemable cards you can buy - maybe physically in some countries, but in mine it's only available on Amazon. Even that option should be safe for keeping your identifying data from the VPN provider, even in the situation where they betray their promises on not holding onto your data. This is because Amazon can't know which exact code was sent out to you, and the provider in turn doesn't have any additional info to associate with that code, besides knowing if it's valid or not. The biggest downside is that now Amazon knows you paid for this service, even if they don't know the specifics.

There's also an option to just mail them cash, but some countries may seize all mailed cash if discovered.

Re: A privacy VPN you can verify

#68

Post by mjg59 »

I'm a huge fan of the technical basis for this. I want services to attest themselves to me so I can verify that they're running the source code I can inspect. And, well, the combination of founders here? Good fucking lord. I'm really fascinated to see whether we can generate enough trust in the code to be able to overcome the complete lack of trust that these people deserve. I can't imagine a better way to troll me on this point.

Re: A privacy VPN you can verify

#69

Post by can16358p »

Okay I don't have much information about this whole attestation flow and one question boggles my mind. If someone can explain this in simple terms, I'd be thankful:

The post says build the repo and get the fingerprint, which is fine. Then it says compare it to the fingerprint that vp.net reports.

My question is: how do I verify the server is reporting the fingerprint of the actual running code, and not just returning the (publicly available) fingerprint that we get result of building the code in the first place?

Post reply on HN