Boring Protocol: On Privacy

A decentralized VPN on Solana.

In order to understand Boring Protocol’s support for privacy, it is absolutely vital that you know how it compares to a regular VPN and Tor. You InfoSec analysts, and persons capable of understanding how commercial VPNs work, should read on. Everyone else, there is plenty of information for you in here too so stick around.

Let’s run through a short list of important questions to consider, so that we can start to see a premise, and understand what problems we are solving and how different concerns are met. Here we go:

1. Is Boring allowing end points to control what can and cannot go through their node?
2. How does the protocol ensures that a response wasn’t forged along the way?
3. Is this closer to a general VPN provider or to Tor in terms of nodes?
4. Will my traffic pass on to one node and exit there? Or will you have entry-relay-exit nodes?
5. How many Nodes can you run in close proximity?
6. Who can see the customer IPs? Are there any relays? Who exits the traffic? (using one node as entry AND exit == malice and abuse.)
7. Will BOP use an entry-relay-exit model similar to Tor? Or it’s going to be more like most dVPNS where you just connect to one node directly?
8. What about malicious providers? Can someone who runs the node intercept ongoing traffic within the node?

With the exception of questions 1 and 2, all the others are basically the same question so let’s get those out of the way first:

Is Boring allowing end points to control what can and can’t go thorough their node?

No.

How does the protocol ensures that a response wasn’t forged along the way?

Traffic that goes through the VPN is encrypted. A third party attacker along the way will not have the encryption keys, and therefore cannot decrypt the traffic. Without decrypting it, it’s not feasible to forge traffic. Even if it was, all forged traffic would just be ignored by the peers since it would not be encrypted with a valid encryption key.

Ok, now let’s dive in deeper.

Can someone who runs the node intercept ongoing traffic within the node?
On the exit node, yes, they can. But that’s not an issue with our protocol, that’s just the way the internet works and the same is valid for all VPNs, distributed or not, as well as non-VPN traffic.

Suppose you are using TOR, considered one of the most secure dVPNs, say you access your Gmail using TOR, after the traffic goes through TOR, it will reach an exit node, after that, traffic will go to exit node’s provider (ISP). Suppose the exit node’s ISP is in Germany and the Google server you are trying to reach is in the USA. Your traffic needs to go across the Atlantic ocean, and there are thousands of paths it could use to reach the USA, including crossing the Pacific instead of the transatlantic submarine cables that may be damaged or overloaded. So, your traffic could be intercepted not only at the exit node but at any of hop along the way of these thousands of possible paths your traffic could go through.

The Internet’s answer for this problem of interception is SSL/TLS end-to-end encryption (like in HTTPS, FTPS, SFTP, IMAPS, etc). End-to-end encryption means your e-mail content, for example, is encrypted inside Google’s server before leaving it, and can only be decrypted by your browser. If someone tries to intercept your traffic, that will render the SSL/TLS certificate invalid, that’s why you kids should never ignore that invalid certificate warning you see sometimes, it could mean a real attack. Without tampering with the certificate, attackers will not be able to decrypt your traffic and/or change it, as they don’t have the private keys for that certificate.

If you are not using SSL/TLS you are screwed any way, your traffic can be intercepted and forged at any point along the way. A VPN can help a bit with that but only to some extent, like hiding your traffic from your ISP and maybe your neighbors, but after the exit node it’s all in the open, and that’s is true for any VPN, centralized or distributed, onion based or not.

That being said, considering the common case nowadays where basically all applications do use SSL/TLS, when we talk about the VPN based attacks, VPNs protect the routing information along the way, that means your e-mails are secure, we (wearing the attacker’s hat now) cannot read or forge your e-mails, we cannot see who you are sending e-mails to, who you are receiving e-mails from, etc. If we intercept the traffic, all we can see is that you are talking to Google’s servers, but we can’t know what is being communicated with Google. We can have a rough idea (far from exact) about how much information you exchange with Google (is it a few kb’s of traffic or many gigabytes?). Basically, the information that can leak from VPNs are origin IPs (source), destination IPs (servers) and amount and frequency of traffic exchanged.

As you can see, the main concern of the VPN is overall privacy: which IPs are talking to which servers and how frequent or how much.

Back to our Gmail example: it’s not very interesting to know that you are talking to Google, as many people do, but as an attacker — even if I cannot read/forge the traffic — it may be interesting to know that you are talking to [redacted] servers, or that you have traffic everyday with [redacted] servers, or with some servers from the government of [redacted].

That’s the main issue with centralized VPNs, they will know every server you are talking to and you have to trust that they will not log this data and not share/sell it.

With dVPNs, you spread this risk across many exit nodes, even if some malicious nodes do keep logs of that data, each one will only have access to a very small fractions of a traffic from many different users, due to the dVPNs natural rotation of peers, which is usually of little to no value to attackers.

With all that in mind, some protocols, like TOR, go to great lengths to create additional anonymity for it’s users, mostly by creating randomized multi-hop traffic paths of varying length and frequently changing across its network of relay nodes. That indeed improves the user’s privacy but at great costs of performance, which is an acceptable trade off for TOR’s goals of increased privacy.

The other extreme from TOR is single node dVPNS. Those single node dVPNs usually delivers the best performance, at the cost of less user privacy. The main issue with single node dVPNs is that malicious exit nodes have access to both traffic destination and source, so a single hope will know your IP and the servers your are connecting to.

Boring Protocol is somewhat in between, in general we lean more towards the performance side of the equation (Netflix is for example usable) but we do not allow single nodes either (entry nodes will never be the same as exit nodes). This way, no single node has access to both source and destination.

Entry nodes can see your IP (no way around that, as the connection needs to start somewhere) but not your traffic destination, intermediate nodes can’t see either, exit nodes can see the destination (no way around that either, as they must send the traffic to the correct destination) but can’t see the source IPs.

In our first public version, all the entry and relay nodes are operated by us directly, and the Motherbored boxes can operate as either consumers or providers (exit nodes). Since entry and relay nodes must be different from exit nodes, we are multi-hop in nature (not single node), but the number of intermediate relay hops is fixed at one for the moment.

We could have varying length multi-hop capabilities added for future versions if we find it useful.

We have a waitlist for the Motherbored V2 if you’d like to be notified when pre-orders begin. Meanwhile, Motherbored V1 has started shipping

We’d love to hear from you in the comments. Please let us know your thoughts. You can always reach out to us on Discord and Twitter.

Stay tuned for out next post coming very soon where we will be outlining all the benefits our Motherbored V1 users can expect in the future.