While building threat models for various people I kept running into a common problem when it came to making recommendations for cloud services. Some of the recommendations for people who were likely to have government or large private entities as adveraries were problematic because they were required to maintain confidentiality and privacy, but would more or less mean that person had to stop using the internet when working with any sensitive material.

Problematic Recommendation 1: Don't use cloud services

In cases where a governmental or large corporate entity is a potential adversary, we have to expect they will be able to access data stored within cloud services. Some adversaries will access the data via sophisticated cyber attacks others might use a warrant, so there are plenty of ways it could happen.

It's even difficult to trust some cloud services that offer end-to-end encryption because even though they can't read customer data, they still control the software you can access the service with (e.g. Apple iOS Messages) and that software could be modified to include backdoors without your knowledge. Or, by virtue of the type of service they offer, a cloud provider may have access to a large amount of metadata, including who you are communicating with (e.g. Signal).

Only cloud services accessible by open source software we can fully configure and trust and where the metadata is not useful for surveillance (e.g. Backblaze B2) can be safely used in these circumstances.

If we could run our own cloud services on equipment that we physically control and software we trust, both of the above risks would be mitigated.

Problematic Recommendation 2: Don't leave footprints

Data brokers are indiscriminately collecting large quantity of low value data from various sources:

• ISP and backbone transit Netflow records
• Cellphone tower access histories and call data
• WIFI and Bluetooth transmission, MACs and locations
• Cookies, Advertiser IDs, browser fingerprints.

Because they have access to such an enourmous amount of data, they are able to combine and cross reference it to associate traffic flows with devices, people and locations. In some cases, they are even able to trace connections through VPNs.

This combined data can then be sold as products to a wide range of government and commerical customers without any legal oversight or restrictions. This is an unacceptable risk for people who have adversaries trying to track their physical location or behaviour online but mitigating the risk by staying offline or exclusively using anonymising software like Tails or Whonix greatly limits their ability to communicate and collaborate with others on the internet.

If we could block all traffic to the internet from browsers, apps or operating systems on our devices, but still be able to communicate and collaborate securely with our team members, most of the above data sources are no longer useful for associating you or your devices with your internet traffic.

Perhaps a solution: Miniserve ^*

What if we built a security appliance in the form of a small box that you can plug into your laptop. It would:

• Provide common cloud services like file storage and sharing, collaborative document editing, instant messaging, video calls
• Use encryption and VPN tech to protect any traffic between you and people you are working with
• Act as a firewall to prevent any data from your laptop (browser footprints, app phone-home etc.) leaking onto the internet.

It might look something like:

Open, but private

Miniserve would rely heavily on opensource software and some external services for VPNs and backups, but crucially, all user data or metadata would never leave Miniserve or user laptops unencrypted so it would always remain under the physical control of the user while still providing many of the collaborative benefits of cloud services. Likely candidates for included opensource software would be:

• Collaborative documents: OnlyOffice
• Storage, sharing: OwnCloud/NextCloud
• IM, video calls: Element/Matrix

The integration and packaging and update mechanisms used by Miniserve would also be available as open source so it could be easily audited.

Components

Owner

The owner of the Miniserve would connect it via a cabled ethernet connections to their laptop/PC. This would give the best network performance and stability while still allowing Miniserve to be moved around with the owner's laptop. It would also allow them to access the services hosted on Miniserve when an internet connection is not availble.

Alternatively, the owner could setup Miniserve and leave it in a safe place at home or the office connected to the internet. They could then (along with team members) access the services hosted on Miniserve via the internet (and Tailscale, see below) from any device, albeit without the protection offered by using the Miniserve firewall to prevent data leakage from the ower's laptop/mobile device.

Team members

When the owner registers a team member with the management GUI, a script is generated that can be sent to the team member. When the team member runs the script, it would install and configure Tailscale on their device, then open a browser window to access the services on Miniserve. Alternatively, the team member could manually configure Tailscale if they prefer.

Tailscale/Headscale

The key to this working is using Tailscale to handle dynamic DNS and allow inbound connections to access devices behind firewalls without any firewall configuration.

Tailscale is a VPN that sets up Wireguard tunnels between the member devices of a 'tailnet' so that traffic can pass securely between them. Importantly, it also uses various techniques to do NAT traversal and allow access to a device inside a private network without requiring changes to the NAT firewall.

Headscale is an open source implementation of the centralised coordination server that Tailscale uses to open tunnels between the devices in a tailnet. It would be preferable to use Tailscale's SaaS provided instance of the centralized server, but Tailscale does not currently provide an API endpoint to share devices inside a tailnet, so instead we will use Headscale to create a tailnet for each Miniserve owner and then add team members to that tailnet so they are able to access Miniserve.

DERP Servers

DERP Servers are Encrypted TCP relays that will relay traffic between devices on the tailnet if NAT traversal fails. They do not have access to VPN keys or unencrypted traffic. We would run multiple DERP servers in logistically beneficial locations for all Miniserve owners to use.

External VPN

An external VPN would be used to obscure the source of traffic going from Miniserve to the Headscale service in case an adversary gains access to the traffic flow going in/out of the Headscale service. If possible the Tailscale traffic itself would also be routed via the VPN, but it remains to be seen if this will work.

Management GUI

This would only be available on the internal 1GbE interface accessible by the owner. It would be used to configure the various aspects of Miniserve such as the app services, filesystem decryption, WIFI connection, backups, VPN connection etc. It would need to make API calls to the Headscale service to enable tailscale, add/remove user permissions etc.

The Result

The overall result would be that a Miniserve owner would be able to securely store their documents, work on them collaboratively and use instant messaging and video calls. This would be possible without any sensitive data being exposed anywhere on the internet, without any way for an adversary to intercept communications and without leaving traceable connection and browser data across the internet.

What do you think?

Do you have any feedback? Do you see any flaws in the overall idea? Do you know someone who might use this?

Hit me up on Twitter, Mastadon or you can send a secure message via our contact form.

* Yeah, it needs a better name.