How Helm Works — Part 1: Networking

Threat Model

To set some context for the level of privacy and security Helm has been designed for, let’s briefly touch on our threat model.

- Government Surveillance: We are focusing on third-party doctrine and how large cloud service providers are routinely compelled to turn over user data.

- Corporate Surveillance: Providers of free services are interested in collecting as much data about their users as possible. All of this data is used to serve ads and may also be sold to data brokers.

- Hackers: We are focusing on how hackers compromise email accounts by exploiting bad passwords, phishing for email credentials and leveraging data from massive breaches.

We’ll have a post in the future that explores our threat model in greater detail.

Running an Email Server at Home is Hard

For an email server to send and receive email with other servers on the internet, they need port 25 to be open. Unfortunately, ISPs in the U.S. block port 25 by default, a practice started in the 90s when home computers were hacked and turned into open relays abused for spamming. Sometimes it’s possible to get this port unblocked, but it’s not uncommon for the ISP to ask for a significantly more expensive class of service in exchange.

ISPs also typically assign dynamic IPs to residential internet connections. Large email service providers block residential dynamic IPs en masse also due to the issue raised above. While it’s possible to get a static IP address from your ISP, they will charge for it and potentially require a more expensive class of service. PTR records, or reverse DNS, is also a key requirement for trustworthiness when setting up an email server. Getting this type of record with a residential internet connection can be a significant challenge and may also incur additional costs.

To summarize, port blocking, dynamic IPs and challenges in establishing a PTR record all interfere with easily running an email server at home. It can cost hundreds of dollars per year and consist of a significant investment of time with your ISP to get things set up just right. After thinking about this problem and experimenting for a while, we managed to find a better way.

Helm’s Network Architecture

We wanted a plug and play solution for customers while adhering to our design tenets and conforming to how email works. To build a plug and play solution, we knew that our server could not require listening for inbound connections on a residential internet connection. We also had to solve for how we could route traffic to and from a home server in a way that prevented us from being able to read emails. We investigated solutions like proxies, transparent proxies, relays, SSH port forwarding and more. We eventually settled on a combination of a simple iptables configuration and a VPN connection.

Here are the steps for Helm’s network architecture to work end to end:

1. When you buy a Helm, a gateway (AWS EC2 instance) is spun up with an Elastic IP. A hosted zone with DNS records, including a PTR record, is established in Route53 for the gateway. The Elastic IP enables a Helm in your home to be easily addressed from anywhere in the world.

2. After you receive your Helm and begin setup, it connects to your router over WiFi or Ethernet. Your Helm then establishes an outbound VPN connection (IKEv2) to the gateway.

3. The combination of an iptables configuration on the gateway and the VPN connection between the gateway and your Helm routes packets between your Helm and the internet.

4. Using this VPN connection, your Helm fetches Let’s Encrypt certificates for your domain.

5. Client-to-server and server-to-server TLS sessions terminate on your Helm, not the gateway. Packets for these TLS sessions travel their last mile over the VPN connection between the gateway and your Helm. Thanks to the Let’s Encrypt project, this architecture is viable and adheres to our design tenet of knowing as little about our customers as possible. We strive to ensure that all inbound and outbound traffic routed through the EC2 instance is using TLS with these certificates from Let’s Encrypt.

Questions About Helm

Don’t ISPs bar home servers per their Terms of Service?

There are many products that function in ways similar to Helm. Thermostats, video cameras, DVRs, and more are remotely accessible when you are away from your home network. The network service between the phone outside your home and the IoT devices inside your home is what allows you to change the temperature, check in on your dog over video or stream the football game you can’t watch live. In the same way, Helm connects to the gateway to easily support inbound and outbound traffic with the internet.

So while there may be legacy language in ISP Terms of Service prohibiting running servers on your internet connection, it typically doesn’t address more modern products like the examples above (including Helm). Separately, your ISP will not be able to see and profile traffic to and from your Helm as it travels over a VPN connection to its gateway.

How can Helm achieve consistent deliverability?

Although residential internet connections face many challenges like port blocking, dynamics IPs and reverse DNS, Helm is designed to handle them. After running email services for over 15 years, we’ve learned that the following are essential requirements for deliverability:

- SPF, DKIM, DMARC: DNS records specify strict policies for the Sender Policy Framework. Only the IP address assigned to the gateway is authorized to send email on behalf of the domain used with Helm. All outbound messages are signed per the DKIM standard. The DMARC policy reinforces that all messages must be signed and adhere to the SPF policy or they will be rejected. This helps ensure that receiving servers can properly authenticate emails and that only emails sent from your server are allowed for your domain.

- PTR Record / Reverse DNS: Every Helm customer has a gateway with a static IP address assigned to it and a PTR record configured to support reverse DNS.

- IP / Domain Reputation: We ensure that the static IPs that are assigned to gateways are not on any known blocklists and continue to monitor blocklists to ensure IPs maintain a good reputation. The email authentication mentioned above helps ensure that good reputation builds over time. Lastly, we are developing a methodology to ensure that IPs used with Helms start with baseline reputation for deliverability.

While there is no perfect solution for deliverability, these steps significantly reduce the likelihood of emails not being delivered or ending up in a spam folder. If there are deliverability issues, they typically clear up within a week with low volumes of email that get moved to the inbox by recipients.

What does Helm (the company) see or know because of the gateway?

We don’t log, save or track any data passing through the gateway. We’ve designed Helm to work end to end with TLS sessions terminating on the server in customers’ homes so encrypted packets flow through the gateway. Over 92% of email traffic is over TLS globally and we will have an option for Helm customers to require all email be transmitted over TLS with the consequence that insecure transmission of emails will be rejected.

If the gateway is compromised, it is possible that the gateway can perform a man in the middle attack and request Let’s Encrypt certificates for the email domain instead of the Helm Personal Server. We lock down the gateway in the following ways:

- MFA required to access our AWS infrastructure

- Gateways are isolated from others

- Key-based SSH authentication for gateways

- Minimal software installed on the gateway to minimize attack surface

- Two ports (500, 4500) open for the inbound VPN connection from a Helm Personal Server

- All other open ports (25, 80, 443, 587, 993, 3333, 8443) are forwarded directly to the Helm over VPN using an iptables configuration

We are evaluating the STARTTLS Everywhere project from EFF. This, in combination with a CT-style log for the certificates Helm fetches from Let’s Encrypt or using STARTTLS Everywhere’s pinning option, can help us detect a compromise of the gateway or DNS and initiate remediation steps.

We are also evaluating how gateways can attest that they are running a configuration that we will be open sourcing. An attestation service can review ongoing attestations to help detect intrusions and initiate remediation steps as well. If you’re doing active work on attestation with secure enclaves and would like to chat, please contact us at “security AT thehelm.com”.

Can I use my own DNS with Helm when I bring my own domain? Do you support DNSSEC?

It’s not currently supported. Our setup process pauses until we detect that you’ve changed your nameservers to ones that specify. We currently have this requirement to ensure that the variety of DNS records (SPF, DKIM, DMARC, A record, PTR) are correctly and consistently configured to make sure that email is properly authenticated and delivered. We import all existing DNS records that are discoverable and make it easy to migrate ones that aren’t as well as create new ones using our mobile app.

We are investigating removing this requirement and allowing customers to use their own DNS provider. We do not currently support DNSSEC as we use AWS Route53 for managing domains and DNS records and they do not support DNSSEC at this time.

Stay Tuned

We’ll be sharing more over the coming weeks and months. Some upcoming posts:

- Our Threat Model For Helm

- Key Product Design Tenets

- Helm’s Software Architecture

- Helm’s Hardware-based Security

- And more…

Join the Movement

Follow us on Medium and Twitter and sign up for our mailing list.