4 ms·

> We encourage everyone NOT to trust, but instead, to verify. I love this. I also don't know how you could possibly make it work. > We’re building an interna

> We encourage everyone NOT to trust, but instead, to verify. I love this. I also don't know how you could possibly make it work. > We’re building an internal roadmap... Keyword: Roadmap Translation: We haven't started on this, but it's something we think we want to do so we're going to start talking about it. > ...to create a transparent and verifiable infrastructure... How is a user supposed to verify the infrastructure? Do you mean you're going to hire a third-party auditor and ask users to trust their verification? I mean, that's better than nothing but it doesn't exactly enable everyone "not to trust, but instead, verify." In this scenario, the auditor is the only one doing the verification. > ...in which no one, including ourselves, is permitted access to the servers through which VPN traffic flows. Then how do you deploy the servers in the first place? How do you identify and handle hardware and software failures? How are you defining "access" such that this idea is possible?

mirimir 7y ago
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 https://secure.cryptohippie.com/products.php 1) http://www.cryptohippie.net/ http://www.cryptohippie.net/ 2) http://www.cryptohippie.net/AnonAdmin.html 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://cryptohippie.net/ https://web.archive.org/web/20081006023454/http://cryptohipp...
- iudqnolq 7y ago
  > 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?
  - mirimir 7y ago
    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.
    - iudqnolq 7y ago
      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?
      - mirimir 7y ago
        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-anonymity-part-1 https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano... 1) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains
Abishek_Muthian 7y ago
>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?
- iudqnolq 7y ago
  Trusting trust. What if the logs lie about what they're logging?
  - kerakaali 7y ago
    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.
    - iudqnolq 7y ago
      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.
      - smokelegend 7y ago
        "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
        iudqnolq 7y ago
        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.
jammygit 7y ago
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?
predakanga 7y ago
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.
- KaiserPro 7y ago
  > 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.
  - thenewnewguy 7y ago
    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.
    - KaiserPro 7y ago
      Which you can't really trust for the same reason.
      - thenewnewguy 7y ago
        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.
Vinnl 7y ago
> 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/ 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.
- ignoramous 7y ago
  AWS announced something similar this past week for EC2: https://news.ycombinator.com/item?id=21717114 https://news.ycombinator.com/item?id=21717114
ohthehugemanate 7y ago
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/ https://signal.org/blog/private-contact-discovery/
- Boulth 7y ago
  The same SGX that was on the front page a couple of days ago? https://news.ycombinator.com/item?id=21759683 https://news.ycombinator.com/item?id=21759683
- BuildTheRobots 7y ago
  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.
  - BuildTheRobots 7y ago
    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.

mirimir 7y ago

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 https://secure.cryptohippie.com/products.php 1) http://www.cryptohippie.net/ http://www.cryptohippie.net/ 2) http://www.cryptohippie.net/AnonAdmin.html 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://cryptohippie.net/ https://web.archive.org/web/20081006023454/http://cryptohipp...

iudqnolq 7y ago
> 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?
- mirimir 7y ago
  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.
  - iudqnolq 7y ago
    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?
    - mirimir 7y ago
      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-anonymity-part-1 https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano... 1) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains

Abishek_Muthian 7y ago

>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?

iudqnolq 7y ago
Trusting trust. What if the logs lie about what they're logging?
- kerakaali 7y ago
  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.
  - iudqnolq 7y ago
    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.
    - smokelegend 7y ago
      "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
      - iudqnolq 7y ago
        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.

jammygit 7y ago

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?

predakanga 7y ago

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.

KaiserPro 7y ago
> 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.
- thenewnewguy 7y ago
  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.
  - KaiserPro 7y ago
    Which you can't really trust for the same reason.
    - thenewnewguy 7y ago
      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.

Vinnl 7y ago

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

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

ohthehugemanate 7y ago

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/ https://signal.org/blog/private-contact-discovery/

Boulth 7y ago
The same SGX that was on the front page a couple of days ago? https://news.ycombinator.com/item?id=21759683 https://news.ycombinator.com/item?id=21759683
BuildTheRobots 7y ago
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.
- BuildTheRobots 7y ago
  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.