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 the system has been broken in the past? Furthermore, can I really be sure that I can trust SGX attestations if I can't actually verify SGX itself? Even if the code running under SGX is verifiable, as an ordinary user it's basically impossible to tell if there are bugs that would make it possible to compromise.
Personally I like the direction Mullvad went instead. I get that it means we really can't verify Mullvad's claims, but even in the event they're lying, at least we got some cool Coreboot ports out of it.
If you're really paranoid, neither this service nor Mullvad offers that much assurance. I like the idea of verifiability, but I believe the type of people who want it are looking to satisfy deeper paranoia than can be answered with just trusting Intel... Still, more VPN options that try to take privacy claims seriously is nothing to complain about.
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 TEE vendors (AMD SEV, ARM Trustzone, etc).
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.
That's a pretty big trust already. Intel has much to loose and would have no problem covering up bugs for government in SGX or certifying government-malware.
And intel had a LOT of successfull attacks and even with their cpu they are known to prefer speed than security.
Intel audits configuration on system launch and verifies it runs something they know safe. That involves CPU, CPU microcode, BIOS version and a few other things (SGX may not work if you don't have the right RAM for example).
The final signature comes in the form of a x509 cerificate signed with ECDSA.
What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.
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.
>the complete lack of trust that these people deserve
Yeah, I took one look at that and laughed. CEO of mt gox teaming up with the guy who sold his last VPN to an Israeli spyware company sounds like the start of a joke.
I didn’t sell PIA. It was a merger to create a publicly owned privacy company and, unfortunately, the terms of the merger did not come to fruition.
I left the company on principle by relinquishing my shares at a mere fraction (about 1/3) the value. I walked away from millions of dollars, and I am happy with my decision.
Given what happened, we built VP so that trust is no longer required.
The SGX TCB isn’t large enough to protect the really critical part of a private VPN: the source and destination of packets. Nothing stops them from sticking a user on their own enclave and monitoring all the traffic in-and-out.
Also, the README is full of AI slop buzzwords, which isn’t confidence-inspiring.
Also, it requires me to trust Intel—an American company, to not have a backdoor in the SGX. That amounts to exactly no trust at all, so it’s a pass from me, and probably any non-US citizen.
This is the best critique of VP.net's approach in this thread. The purpose of the enclave approach is that you can be sure they're not logging your traffic. This is an advantage over competitors. But, as you say, this does not actually work. When you connect to the VPN, you don't know whether your traffic really gets mixed with other people's traffic. If it doesn't get mixed, then no matter what the trusted enclave code does, they still know all the input and output traffic belongs to you.
You also have to trust that SGX isn't compromised.
But even without that, you can log what goes into SGX and what comes out of SGX. That seems pretty important, given that the packets flowing in and out need to be internet-routable and necessarily have IP headers. Their ISP could log the traffic, even if they don't.
> Packet Buffering and Timing Protection: A 10ms flush interval batches packets together for temporal obfuscation
That's something, I guess. I don't think 10ms worth of timing obfuscation gets you very much though.
> This temporal obfuscation prevents timing correlation attacks
This is a false statement. It makes correlation harder but correlation is a statistical relationship. The correlations are still there.
All that said, it is better to use SGX than to not use SGX, and it is better to use timing obfuscation than to not. Just don't let the marketing hype get ahead of the security properties!
While I do see the impl of the 10ms flush interval, I don't see any randomisation within batches. So iiuc, packets are still flushed in their original order.
The comment was added before the implementation of the IPC buffer & shuffling and was left there, sorry about that.
In an older version packets were sent back in sequence to their original connection to the host, as it was faster.
We since then implemented a system where nproc (16+) buffers receiving packets running at differed intervals, meaning that while packets are processed "in order" the fact this runs in multiple threads, reading packets even from the same client will cause these to be put in queues that will be flushed at different timings.
We have performed many tests and implementing a more straightforward randomized queue (by allocating memory, handling array of pointers of buffers, shuffling these, and sending these shuffled) did not make much of a difference in terms of randomization but resulted a huge loss in performance due to the limitations of the SGX environment.
As we implement other trusted environments (TEE) we will be implementing other strategies and obfuscation methods.
One of the many reasons I love Mullvad (been using it for 4 years now) is their simple pricing—$5/month whether you subscribe monthly, yearly, or even 10 years out.
I wanted to give your product a try, but the gap between the 1-month and 2-year plans is so big that a single month feels like a rip-off, while I’m not ready to commit to 2 years either.
On payments: for a privacy-focused product, Monero isn’t just a luxury, it’s a must (at least for me). A VPN that doesn’t accept Monero forces users into surveillance finance, since card and bank payments are legally preserved forever by processors. That means even if the VPN “keeps no logs,” the payment trail still ties your real identity to the service.
Until crypto is legally treated like cash (e.g. I don't have to report that I bought a beer with a $20 bill from an ATM), I don't think it's a very satisfying solution to have to either 1. Report to the IRS that I bought a VPN with monero or 2. Commit a tax crime and be paranoid about the IRS using automated tools to find you out for years after each transaction.
Even ignoring that elephant inthe room, how do you regularly (to pay subscription) get the crypto without leaving a paper trail or dealing with sketchy people?
I like virtual cards like privacy.com. If a state actor is after you, they will find you. So the typical threat model to me is companies trying to track you, like your ISP/Google/Facebook.
It would be nice if there was some way to be tax compliant and get the privacy benefits of monero though. Am I missing some crypto tax compliance tooling here or are all of these crypto payment users just poking the IRS bear?
> If you pay in crypto, you have to report every conversion from fiat to monero
That's not what your link says, and as far as I'm aware it's not true. Buying crypto and then using some of it to buy goods and services has no tax reporting requirement, those only start when you're either selling crypto or receiving it as payment. Which is the same situation as the tax reporting for any other currency or valuable item you could deal in.
to me at this point I only would trust these in this order:
Mullvad
IVPN
ProtonVPN
Mullvad is the only one that have RAM-only (diskless) servers.
Both Mullvad and IVPN have Monero as a payment method (which is the best for privacy) and both have Anonymous sign-up no email required.
Proton is last because they don't support Monero (only BTC which isn't very anonymous by design)
All have third party independent audits and are OSS
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?
"Ask a VP.NET server for the fingerprint it reports" is a little bit simplistic. The process for actually doing this involves you handing the server a random number, and it sending you back a signed statement including both the fingerprint and the random number you gave it. This prevents it simply reporting a fixed fingerprint statement every time someone asks. The second aspect of this is that the key used to sign the statement has a certificate chain that ties back to Intel, and which can be proven to be associated with an SGX enclave. Assuming you trust Intel, the only way for something to use this key to sign such a statement is for it to be a true representation of what that CPU is running inside SGX at the time.
How do I know I'm connecting to the WireGuard instance being attested and not something else? Could the host run one attestable instance, but then have users connect to a separate, malicious one?
> how do I verify the server is reporting the fingerprint of the actual running code
Since this was answered already, I'll just say that I think the bigger problem is that we can't know if the machine that replied with the fingerprint from this code is even related to the one currently serving your requests.
Someone had a comment here that just disappeared, mentioning it's by Mark Karpelès (yes, the same guy from MtGox) and Andrew Lee. Why did that remark get deleted?
The people who were convicted of multi-million dollar fraud resulting in someone walking away with millions of dollars of others bitcoin deposits, IIRC (https://en.m.wikipedia.org/wiki/Mark_Karpel%C3%A8s if you want to check details).
Also, I couldn't see where it is based? Anywhere in Five-Eyes countries, or places like USA with national security letters (or just their fascist government) is probably not going to fit most people's that models.
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 providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
> 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.
This VPN requires you to trust in Intel - a failing US megacorp desperate for money - as well as the guy who destroyed Mt Gox and the guy who destroyed Freenode. Personally, I'd rather trust in Mullvad.
>it is harder for the American government to eavesdrop on US soil than it is outside America.
I don't have any particular insight here, but isn't that why Five Eyes is used, a workaround for what would otherwise be illegal activities. Not that the current USA regime care about the law, of course.
The chief privacy officer of the company is the moron that destroyed Freenode. Of course, Libera lives on, but it is a transition we could’ve done without.
Freenode was sold to me by Christel, the previous owner. I did not even offer to purchase it and simply assumed I was doing what I had been doing for a decade for freenode and many other FOSS projects - keeping them alive. It was my funds that did so the whole time for freenode (and a number of other projects which I stopped funding thereafter given the death threats I was receiving which led to the end of many of them unfortunately).
The Libera staff [1] attempted to steal the domain because they wanted control. None of the staff were developers at the time and complained they couldn’t even write their own irc client. Think of Mozilla. The people who run it aren’t the coders. Same thing.
Here are the receipts for every statement I just made:
PS: Freenode seems more active then Libera where everyone is just idle (bots?) but that is another point. See for yourself with the client I wrote: IRC.com.
[1] By Libera staff I mean the former freenode staffers who left to form Libera. These are the same people I spent a lot of money helping to protect legally from the allegations made by “OldCoder”
Could it be that the original freenode staff did not want to have anything to do with you in an operational manner? Whilst the financial contributions for legal defense always went a long way, not much else was needed, like the live events and freenode branded merch. Staff were not adequately informed as to how the sale went down. Later, I do not believe tomaw was trying to strongarm anyone into leaving, staff genuinely wanted nothing to do with the supposed crown prince of Joseon.
Ultimately, the people who invested their labor into the network felt like they had little control over the future of the project and felt like they had been rug pulled by christel so they left. They did not believe that it was christel's to sell. Ultimately, as soon as the original operators left, the new management have not necessarily left a great impression. For a while, freenode.net would just redirect to a subreddit? And then later it was a reddit clone of sorts? (https://web.archive.org/web/20220505184527/https://freenode....). Channels were taken over at will. There were somewhat dubious partnerships made, crypto products endorsed. The first blog posts made by the new management straight after the changeover were markedly different from the previous messaging - (https://web.archive.org/web/20210730233709/https://freenode....). The original freenode was doing its best to be a place where like minded people could collaborate and communicate without adding too much of a political sway or coloring anything, the freenode after the takeover did not aspire to do any such thing. If in May of 2021 one could've argued that the old staff were a tad too eager to leave, then the newcomers did everything in their power to prove them right in less than a month.
Please do fund FOSS stuff, it really helps. Just don't expect to buy yourself out of being cringeworthy.
The whole community fled from Freenode as a direct consequence of your actions. You aren't convincing anyone with your "debunkings," dear masterdebater.
Readit News
Personally I like the direction Mullvad went instead. I get that it means we really can't verify Mullvad's claims, but even in the event they're lying, at least we got some cool Coreboot ports out of it.
If you're really paranoid, neither this service nor Mullvad offers that much assurance. I like the idea of verifiability, but I believe the type of people who want it are looking to satisfy deeper paranoia than can be answered with just trusting Intel... Still, more VPN options that try to take privacy claims seriously is nothing to complain about.
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 TEE vendors (AMD SEV, ARM Trustzone, etc).
That's a pretty big trust already. Intel has much to loose and would have no problem covering up bugs for government in SGX or certifying government-malware.
And intel had a LOT of successfull attacks and even with their cpu they are known to prefer speed than security.
As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty.
I would love to be wrong.
The final signature comes in the form of a x509 cerificate signed with ECDSA.
What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.
Because of the cryptographic verifications, the communication cannot be spoofed.
Yeah, I took one look at that and laughed. CEO of mt gox teaming up with the guy who sold his last VPN to an Israeli spyware company sounds like the start of a joke.
I left the company on principle by relinquishing my shares at a mere fraction (about 1/3) the value. I walked away from millions of dollars, and I am happy with my decision.
Given what happened, we built VP so that trust is no longer required.
Also, the README is full of AI slop buzzwords, which isn’t confidence-inspiring.
Trusting random internet people is actually the biggest “troll” of the internet.
Any VPN that asks you to trust their guarantees and not the guarantees of code is selling you snake oil and should not be trusted.
Trust is not a feature in security. Thus, we removed and replaced it with code based guarantees.
You also have to trust that SGX isn't compromised.
But even without that, you can log what goes into SGX and what comes out of SGX. That seems pretty important, given that the packets flowing in and out need to be internet-routable and necessarily have IP headers. Their ISP could log the traffic, even if they don't.
> Packet Buffering and Timing Protection: A 10ms flush interval batches packets together for temporal obfuscation
That's something, I guess. I don't think 10ms worth of timing obfuscation gets you very much though.
> This temporal obfuscation prevents timing correlation attacks
This is a false statement. It makes correlation harder but correlation is a statistical relationship. The correlations are still there.
(latter quotes are from their github readme https://github.com/vpdotnet/vpnetd-sgx )
All that said, it is better to use SGX than to not use SGX, and it is better to use timing obfuscation than to not. Just don't let the marketing hype get ahead of the security properties!
While I do see the impl of the 10ms flush interval, I don't see any randomisation within batches. So iiuc, packets are still flushed in their original order.
In an older version packets were sent back in sequence to their original connection to the host, as it was faster.
We since then implemented a system where nproc (16+) buffers receiving packets running at differed intervals, meaning that while packets are processed "in order" the fact this runs in multiple threads, reading packets even from the same client will cause these to be put in queues that will be flushed at different timings.
We have performed many tests and implementing a more straightforward randomized queue (by allocating memory, handling array of pointers of buffers, shuffling these, and sending these shuffled) did not make much of a difference in terms of randomization but resulted a huge loss in performance due to the limitations of the SGX environment.
As we implement other trusted environments (TEE) we will be implementing other strategies and obfuscation methods.
I wanted to give your product a try, but the gap between the 1-month and 2-year plans is so big that a single month feels like a rip-off, while I’m not ready to commit to 2 years either.
On payments: for a privacy-focused product, Monero isn’t just a luxury, it’s a must (at least for me). A VPN that doesn’t accept Monero forces users into surveillance finance, since card and bank payments are legally preserved forever by processors. That means even if the VPN “keeps no logs,” the payment trail still ties your real identity to the service.
Until crypto is legally treated like cash (e.g. I don't have to report that I bought a beer with a $20 bill from an ATM), I don't think it's a very satisfying solution to have to either 1. Report to the IRS that I bought a VPN with monero or 2. Commit a tax crime and be paranoid about the IRS using automated tools to find you out for years after each transaction.
Even ignoring that elephant inthe room, how do you regularly (to pay subscription) get the crypto without leaving a paper trail or dealing with sketchy people?
I like virtual cards like privacy.com. If a state actor is after you, they will find you. So the typical threat model to me is companies trying to track you, like your ISP/Google/Facebook.
It would be nice if there was some way to be tax compliant and get the privacy benefits of monero though. Am I missing some crypto tax compliance tooling here or are all of these crypto payment users just poking the IRS bear?
That's not what your link says, and as far as I'm aware it's not true. Buying crypto and then using some of it to buy goods and services has no tax reporting requirement, those only start when you're either selling crypto or receiving it as payment. Which is the same situation as the tax reporting for any other currency or valuable item you could deal in.
Mullvad is the only one that have RAM-only (diskless) servers. Both Mullvad and IVPN have Monero as a payment method (which is the best for privacy) and both have Anonymous sign-up no email required.
Proton is last because they don't support Monero (only BTC which isn't very anonymous by design)
All have third party independent audits and are OSS
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?
Since this was answered already, I'll just say that I think the bigger problem is that we can't know if the machine that replied with the fingerprint from this code is even related to the one currently serving your requests.
Also, I couldn't see where it is based? Anywhere in Five-Eyes countries, or places like USA with national security letters (or just their fascist government) is probably not going to fit most people's that models.
> we operate proudly in the united states. protected by the constitution — not offshore shell games.
> no backdoors. no stored data. even if they ask, we've got nothing.
> we don't dodge the law — we built tech that doesn't need to.
https://vp.net/l/en-US/about
Deleted Comment
Honestly, I feel more comfortable using Mullvad. This team has some folks with questionable backgrounds and I wouldn't trust Intel. Also VPN providers are usually in non-us countries due to things like the Lavabit, Yahoo incidents and the Snowden revelations.
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.
And worse, it is harder for the American government to eavesdrop on US soil than it is outside America.
Of course, if a national spying apparatus is after you, regardless of the nation, pretty good chance jurisdiction doesn’t matter.
I don't have any particular insight here, but isn't that why Five Eyes is used, a workaround for what would otherwise be illegal activities. Not that the current USA regime care about the law, of course.
The GP mentioned Snowden and yet you say this. What material and significant changes have happened since 2013 to make this claim?
Freenode was sold to me by Christel, the previous owner. I did not even offer to purchase it and simply assumed I was doing what I had been doing for a decade for freenode and many other FOSS projects - keeping them alive. It was my funds that did so the whole time for freenode (and a number of other projects which I stopped funding thereafter given the death threats I was receiving which led to the end of many of them unfortunately).
The Libera staff [1] attempted to steal the domain because they wanted control. None of the staff were developers at the time and complained they couldn’t even write their own irc client. Think of Mozilla. The people who run it aren’t the coders. Same thing.
Here are the receipts for every statement I just made:
http://techrights.org/wp-content/uploads/2021/05/lee-side.pd...
PS: Freenode seems more active then Libera where everyone is just idle (bots?) but that is another point. See for yourself with the client I wrote: IRC.com.
[1] By Libera staff I mean the former freenode staffers who left to form Libera. These are the same people I spent a lot of money helping to protect legally from the allegations made by “OldCoder”
Ultimately, the people who invested their labor into the network felt like they had little control over the future of the project and felt like they had been rug pulled by christel so they left. They did not believe that it was christel's to sell. Ultimately, as soon as the original operators left, the new management have not necessarily left a great impression. For a while, freenode.net would just redirect to a subreddit? And then later it was a reddit clone of sorts? (https://web.archive.org/web/20220505184527/https://freenode....). Channels were taken over at will. There were somewhat dubious partnerships made, crypto products endorsed. The first blog posts made by the new management straight after the changeover were markedly different from the previous messaging - (https://web.archive.org/web/20210730233709/https://freenode....). The original freenode was doing its best to be a place where like minded people could collaborate and communicate without adding too much of a political sway or coloring anything, the freenode after the takeover did not aspire to do any such thing. If in May of 2021 one could've argued that the old staff were a tad too eager to leave, then the newcomers did everything in their power to prove them right in less than a month.
Please do fund FOSS stuff, it really helps. Just don't expect to buy yourself out of being cringeworthy.