Hacker News Reader

Regarding verifying the application running server side matches the expected OSS version, Signal has an innovative approach as a part of their zero-knowledge contact discovery system.

> Run a contact discovery service in a secure SGX enclave. > Clients that wish to perform contact discovery negotiate a secure connection over the network all the way through the remote OS to the enclave. > Clients perform remote attestation to ensure that the code which is running in the enclave is the same as the expected published open source code. > Clients transmit the encrypted identifiers from their address book to the enclave. > The enclave looks up a client’s contacts in the set of all registered users and encrypts the results back to the client.

>Since the enclave attests to the software that’s running remotely, and since the remote server and OS have no visibility into the enclave, the service learns nothing about the contents of the client request. It’s almost as if the client is executing the query locally on the client device.

It's not perfect, but it is a huge improvement over blindly trusting the software running on a third party server. There's a lot more detail, including pitfalls, work arounds, limitations, and of course source code, in their blog post on the subject :

https://signal.org/blog/private-contact-discovery/

The same SGX that was on the front page a couple of days ago? https://news.ycombinator.com/item?id=21759683

I don't suppose there's any more information on how remote attestation works? (Ideally something an idiot like me could comprehend).

I can't understand how, if the company has control of the code running there, they can't just modify it to report as the known good code. It seems like it'd be slightly different from the DRM example where the end user can't access the code running in the enclave in the first place and doesn't know what it'd be reporting back.

I can't edit my comment, but after reading up on Intel's secure enclave last night, I still don't get how this would work in practise. As the end user (me) needs to know what the server is going to return in order to verify that, I don't understand what's stopping the server from returning that anyway. Even if it's using public key crypto to sign a challenge I send it, I still don't understand how I can have any assurance that this key only exists inside the enclave and isn't just running in software on the server.

> How is a user supposed to verify the infrastructure?

This is a bit outside of my league and thus might be completely irrelevant, but Signal does something interesting in this area: https://signal.org/blog/private-contact-discovery/

> Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel, similar to technologies like ARM’s TrustZone. SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.

> Originally designed for DRM applications, most SGX examples imagine an SGX enclave running on a client. This would allow a server to stream media content to a client enclave with the assurance that the client software requesting the media is the “authentic” software that will play the media only once, instead of custom software that reverse engineered the network API call and will publish the media as a torrent instead.

> However, we can invert the traditional SGX relationship to run a secure enclave on the server. An SGX enclave on the server-side would enable a service to perform computations on encrypted client data without learning the content of the data or the result of the computation.

AWS announced something similar this past week for EC2: https://news.ycombinator.com/item?id=21717114

Regarding deploying servers that you don’t have access to, you could deploy them with a boot loader that netboots signed images, require a certain number of developers to sign each image. I’ve considered something similar for deploying k8s workers - just a ramdisk that encrypts local storage with a random key, then requests admission to the cluster.

Troubleshooting is harder, but I can imagine a fault reporting component that anonymises error reports and uploads them to a public-visible tracker. If something looks like a hardware failure, take it out of the infra and boot a traditional OS to do some diagnostics.

> netboots signed images

There is no safe way to do this. Netboot picks up the fastest dhcp/tftp server to reply.

which means there is nothing to stop something booting a hypervisor, then booting your image.

I think you missed a few words there: "with a boot loader that netboots signed images".

They won't be relying on the BIOS netboot that picks up the first DHCP server, but rather a custom bootloader that will check the signature on the image before running it.

Which you can't really trust for the same reason.

Why not? If you're writing the bootloader (or using one that's trustworthy and open source) and deploying it by yourselves then it should be relatively safe. An attacker would have to have physical access to the hardware, or some method of modifying the bootloader on disk.

Unfortunately, for this use case the attacker that users are worried about are also the ones that will be installing the bootloader on the server in the first place. I don't see, from a computer science point of view, a process for verification that can't be emulated by the system that runs it.

If they hypothetically solved this problem, wouldn’t that be amazing for the security and privacy world?l to have a model they could copy?

>How is a user supposed to verify the infrastructure?

May be opening the logs for intrusion detection systems for their servers could help user be aware of external attacks. Also may be internal access logs?

Trusting trust. What if the logs lie about what they're logging?

Well, one needs to make the leap of faith somewhere.

Though if someone was faking their logs, I'm pretty sure it's possibly to see that there's something fishy going on.

At the end of the day, only you can make the judgement of what constitutes secure enough relating to your own infosec.

Agree completely. I'm choosing to not make my leap of faith trusting a scammy VPN provider after they publish plain text files that claim they're really good people at heart.

Maybe I'll make my leap of faith trusting someone with a little more at stake, and a reputation for being trustworthy.

"Maybe I'll make my leap of faith trusting someone with a little more at stake, and a reputation for being trustworthy."

Which VPN provider in your opinion would you consider "trustworthy"???

My understanding PIA was a great option until the most recent buyout... now I don't know who to throw my $$$ at... just asking

Right now I use Mullvad, because they give off trustworthy vibes and let me use the default wireguard apps instead of custom apps that could give them more access to my computer. They generally appear the least sketchy, but I don't have the knowledge to recommend them per se.

It's not at all a new idea.

Cryptohippie has been claiming something like this for over a decade.[0]

> Cryptohippie USA, Inc. provides access to the Cryptohippie network, which is anonymous, thoroughly protected and globally distributed. This network creates anonymity and gives you very private access to standard Internet destinations.

> Cryptohippie is unique: we don't require you to trust a single entity for your privacy. Our sales and network are run by separate companies in different jurisdictions. The sales company never sees network traffic and the network company never sees sales data.

The network provider being Cryptohippie Inc., Panama.[1] And one of their services is "Anonymous Admin".[2]

> System administrators are prime targets for blackmail, corruption and outside force, and are in a central position to undermine your communication and data security.

> Cryptohippie Inc. operates an Anonymous Administrator pool that can be utilized to oversee critical enterprise infrastructure or administer highly sensitive information resources.

> Anonymous Administrators can not be targeted by third parties. Not even Cryptohippie Inc. can give away their personal information or identity which could put them at risk of under force.

> Using auditing and concurrent peer review processes, Anonymous Administrators are under your control and the risk of them becoming insider attackers is greatly reduced.

> Only carefully tested, hand-picked specialists with a long standing relationship with Cryptohippie Inc. are available for client work.

> Please be advised that Cryptohippie Inc. only facilitates the contact to the pool of administrators and helps with setting up processes for communication, auditing and payment escrow. We will not know what specific administrator works for your organization or what tasks you delegate to them. However, in case of conflict, we will mediate/arbitrate upon request.

The argument, I gather, is that substantive acts require consensus of multiple anonymous admins. So rogue admins are not so much an issue.

But still, as you say, how can users trust any of that?

So yes, there is no "verify".

That's why I recommend nested VPN chains. You just need to trust that most of the VPN services in your chain are not working together for an adversary.

0) https://secure.cryptohippie.com/products.php

1) http://www.cryptohippie.net/

2) http://www.cryptohippie.net/AnonAdmin.html

Edit: About that "over a decade" comment, here's a snapshot from 2008: https://web.archive.org/web/20081006023454/http://cryptohipp...

> That's why I recommend nested VPN chains. You just need to trust that most of the VPN services in your chain are not working together for an adversary.

In general in cryptography, it's possible to combine secure things and get a less-secure thing. I don't know if this is the case for VPNs. Have you analysed the issue in depth?

This isn't about cryptography. It's just that any VPN server must know the IP addresses it's communicating with. So with one VPN, someone can just look at the traffic logs.

But with two VPNs chained, neither one knows both your IP and the IPs of the sites that you access. And the longer the chain, the more collusion an adversary needs.

But yes, you're also encapsulating multiple levels of encryption. I do appreciate that potentially increasing the risk of breaking the encryption. However, I'm willing to accept that in exchange for not being so trivially findable.

I didn't mean necessarily you'll break the crypto primatives, more that these kinds of systems can interact in weird ways if you don't go through everything very carefully.

How do you set up the chains? Do you mean?

    You ---[vpn_1]---> your server        
    server ---[vpn_2]---> ISP

Or do you do

        ===[vpn_1]=====
   You  ----[proxy_server_1]--- ISP 
        ===============

Or differently? There's no way to tunnel a VPN in a VPN COTS.

Off the top of my (nonexpert) head, some adversaries can try a bunch of different correlation attacks and if they can associate your traffic with any of your VPNs they can work to track your transactions to pay for it. So having more VPNs gives them a greater chance of being able to access the data of one and a greater chance of you screwing up the anonymous purchase of one.

Also I'm pretty sure you mostly have to trust the last VPN in your chain anyway. So why not just use only that one?

It's simple.

I connect to a server of one VPN service. Then, through that VPN tunnel, I connect to a server of a second VPN service. Then, through that VPN tunnel, I connect to a server of a third VPN service. That's what I mean by nested. I don't use custom VPN clients. Just OpenVPN.

In the setup that I'm currently using, one VPN client runs in a VirtualBox host machine. And the others run in pfSense VMs.[0] Each pfSense instance uses ~500MB RAM, however.

But it also works in a single machine, using routing and iptables rules.[1] For a chain of three VPNs, these OUTPUT rules prevent leaks, with internet traffic restricted to the third VPN tunnel (tun2):

   -A OUTPUT -o enp0s3 -d VPN0 -j ACCEPT
   -A OUTPUT -o tun0 -d VPN1 -j ACCEPT
   -A OUTPUT -o tun1 -d VPN2 -j ACCEPT
   -A OUTPUT -o tun2 -j ACCEPT
   -A OUTPUT -j DROP

VPN0, VPN1 and VPN2 are the IPv4 addresses of the VPN servers that I'm using. From different VPN services. The script that sets up the chain alters the routing so that each VPN connects through the previous one. There's no isolation between the different VPN clients, but that also makes it easy to switch chains periodically. Sort of like Tor.

I pay for the first VPN with a credit card. But the rest I pay with Bitcoin, which has been mixed multiple times through Tor, using a different mixing service at each step. I used Bitcoin that's been mixed more times for VPNs that I connect to less directly. And I never lease different VPNs with the same batch of mixed Bitcoin.

The last VPN know only what I connect to, and what VPN I connected from.

0) https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano...

1) https://github.com/mirimir/vpnchains

Thanks for the reply. Guess SE was wrong about the configs. If you don't mind me asking, why cc for the first hop?

Also, vpnchains explicitly says they can't protect against adversaries with a global view od the network. That was the main weakness I assumed this would probably have. I'd buy that it protects from for instance VPN providers selling logs.

I use a card for the first one because it's gotta know my IP, and my ISP can link me to my IP.

Nothing can protect from adversaries with a global view of the internet. At least, for low-latency activity. If the latency is high enough, and there's lots of chaff, there's maybe a chance. Or at least, there are too many false positives to deal with.

Otherwise, you just make it harder. Once you have more than a couple VPNs in a chain, and especially if you switch chains frequently, latency varies a lot. So that likely helps too.

Edit: There is nothing in OpenVPN about routing one VPN through another. That's all done in the host networking stack, or using multiple routers with NAT forwarding. There is, however, a SOCKS5 proxy option, which you can use to route a VPN through Tor. Or you can just run a VPN server as an onion service.

But why go through so much trouble instead of just using Tor, which AFAIK gives you 3 hops right out of the box?

I do use Tor. Which gives me three hops for clearnet sites, and seven hops for onion services. But I don't trust Tor enough to connect directly to it. Given the risk of malicious relays, and of 0days like "relay early" that increase their effectiveness. And then there's the likelihood that TLAs track all connections to the Tor network.

So the nested VPN chains isolate me from Tor entry guards. If Tor circuits get deanonymized, an adversary just learns a VPN exit. Or at least, an adversary that isn't doing global traffic analysis.

But as Mirimir, I don't need all that. I really don't need anonymity at all, except to protect my professional reputation. And being retired, that doesn't matter any more.

So anyway, nested VPN chains are arguably enough for people who aren't juicy targets. They almost certainly aren't as good as Tor, unless Tor is more compromised than it seems.

But what they are is lots faster. There's somewhat less latency than Tor. And bandwidth is much higher.

You might want to look into wireguard.

It has much lower over-head then OpenVPN, and in your case the inter-connection latency/processing would be improved.