PinkDate: If Silk Road had used this design, they’d still be online

PinkDate is the world’s first anonymously operating escort agency, leveraging blockchain fundraising and payments with anonymity technology to operate in an extrajurisdictional fashion. Find out more at

PinkDate takes anonymity and privacy very seriously. A common question I get asked is how we’re going to ensure the confidentiality of our user information. A related question is how will we keep our servers safe from law enforcement. In this article I’ll describe our design that successfully mitigates these threats.

Our primary principle here is that we can trade off latency, both in service delivery, and in time-to-recover, to achieve unmatched levels of anonymity and security. These are trade-offs most companies will not make. Just the simple act of having to enter a boot password in case of server failure or reset is unacceptable to most. We will make this trade for security, yet by tightly running our operation, we can eliminate most of the downside and maintain a reliable, snappy, platform.

If you are already familiar with this technology and threat model, skip to the bottom to read a short technical summary.

Disclaimer: Yes, we know DPR was taken down due to linking his other identities and not just due to poor server hygiene. Our opsec will be lightly discussed in another article. Our main defense is that the core team will hire people to be the public face, meaning the core team is rarely online in the first place. High latency = better anonymity.

This high-level overview diagram is explained in the article.

Tor Hidden Services — A Useful Building Block

The Tor Project provides software that mixes traffic to provide anonymity. When you browse the web with Tor, your real IP address is never revealed. Without a further leak of identity, a website simply will not know where you actually are, while using Tor.

In addition to providing anonymity to users, Tor provides anonymity to servers via a feature called Hidden Services. With a hidden service, a server uses a special .onion domain, resulting in URLs like http://mic7nabzyyzp2hk4r.onion. When a user accesses such a URL, the Tor network obscures where the server is located, hiding it within the entire Tor network, while providing automatic encryption to the hidden service. This is a huge benefit: If an attacker does not know where a server is located, they will have a hard time attacking the surrounding infrastructure via hacking, social engineering, warrants, or physical access.

A problem that several hidden service operators have run into in the past is accidental IP address disclosure. An attacker may be able to coerce the server software to generate an error page containing its real IP. Or an attacker may be able to cause the application software to make an outbound clearnet connection — for example by exploiting XML processing directives or otherwise causing a DNS lookup or connection attempt.

PinkDate solves this by making sure every server has no direct Internet access. App servers are put on an unrouted network with private IPs (10.x.x.x), with the only access being via a Tor proxy server. Even if the app server intentionally wanted to leak its public IP, it would be unable to do so.

But the main downside of hidden services is that users must use Tor: .onion domains are not accessible with normal Internet access. This poses a huge barrier to entry for potential users.

One workaround is to use a “Tor2Web” gateway, which is an HTTP proxy server that listens on a normal domain, then forwards requests to the hidden service. The gateway itself won’t keep any data and can be easily moved. This is important because the gateway will be public knowledge — attackers can target that server directly. But if the gateway is compromised, all user communications to the .onion domain are now compromised.

PinkDate solves this by providing a TCP-only proxy to its hidden services, while keeping the SSL certificates of the gateway domain on the hidden services. Users can check their browser bar to ensure an SSL (TLS) connection is established to the domain. This ensures that they have connected to the correct gateway and hidden service. If the gateway is compromised, only client IP address information is leaked. The communication content is encrypted all the way to the hidden service.

For an attacker to truly compromise user communications, they would need to first take over the gateway, then chase down the hidden service itself. De-anonymizing hidden services is non-trivial, but we assume a well-funded, well-connected opponent in our mitigations.

First, PinkDate uses Hidden Service Authorization. Normal hidden services have their names publicly listed, and there may be some attack vectors there. Authorized hidden services are not listed and cannot be discovered without knowing the authorization key. This means that until a gateway is compromised, an attacker cannot even start to de-anonymize the hidden service.

To make sure a de-anonymization attack never succeeds, PinkDate rotates its servers and hidden services. Each gateway gets its own hidden service address to forward to. This address is changed fairly frequently, and the gateway re-deployed. Even better, the actual servers running the services are rotated on a random interval. Thus even if an attacker did compromise these servers, access would be temporary.

To top it all off, these app servers do not store any user data. In fact, they lack persistent storage completely and are re-imaged on every boot. User data is stored on a separate cluster of servers, accessible only via another Tor Hidden Service. These service addresses are also regularly changed.

In short, an attacker would need to quickly compromise the gateway servers, de-anonymize the first layer of hidden services, physically compromise the first layer servers, then repeat the process on the data-layer services. This is not a practical attack. Yet PinkDate does not stop there.

Segregation — Containing Threats

A common technique in safety and security, from physical to network, is segregation. Ships have compartments to prevent a breach of one section spreading to another. PCI compliance often involves splitting networks and applications up so the card-handling parts have minimal integration points. In encryption protocols, we prefer designs that offer forward-secrecy — compromising the secret material at one point in time should not compromise all messages in the future.

Pink’s server architecture takes this all the way. As described in the previous section, Pink’s platform has three layers of servers. The first two layers have no persistent storage and are physically rotated frequently (but randomly). Only the third layer (at that point, behind a gateway plus two Tor circuit hops) keeps any records. A compromise of the gateways, or even of the app-services, has a very limited impact. And even within layers, things are separated.

The most notable one is our authentication system. Auth info is stored in a separate set of servers, accessed via a separate set of services. The auth service generates a time-limited ticket that the application services can use to retrieve and process data on that user’s behalf. We do not expose our databases directly, but instead have a small data-access platform to make specific database queries. The data access software will not retrieve a user’s data without a currently valid ticket, regardless of what the app servers request. This also serves as a great failsafe: a bug in our app logic cannot accidentally access more information than it should.

Within each set of servers, Internet access is tightly restricted, physically. App and data servers simply do not have Internet access. App servers only receive connections via the Tor hidden service, running on another server. They can only make connections to the data services. And even then, not directly.

App services talk to an HTTP proxy running on the same network but different server, and that HTTP proxy then forwards to the data-layer .onion address. Data servers only have inbound connections and no outbound connectivity whatsoever.

Services run in a minimal environment; common tools are not available. So even if an attacker gained execution access in one of our processes, they’d find themselves in an extremely limited environment and unable to escalate this access into something persistent or useful.

To update or make any changes to the PinkDate platform, the app and data servers must be re-provisioned from scratch. Even a simple reboot requires manual intervention — data disks are fully encrypted, and the key is not stored in any persistent storage; it must be re-entered at boot time, every time. This increases lag in case of an outage, but immensely increases security.

Combined with our physical access-prevention and intrusion-detection measures (not publicly documented, but include rack and server-level security) that trigger an automatic shutdown, the chance that our data disks could be captured intact is negligible.

Technical Summary

PinkDate is available via a publicly accessible domain over HTTPS. DNS resolves to a Tor2Web gateway that only proxies the TCP connection to the app layer, a Tor hidden service in authenticated mode (the .onion is not listed and cannot be crawled).

SSL termination for the domain is performed on the app layer; compromising the gateway does not allow eavesdropping. The app layer can only talk to the database via a database service, provided on another hidden service. App layer has no persistent storage. Hidden service addresses are rotated. Servers are rotated (new server host every random interval). Services have no public Internet access, only access to the hidden services they need.

Services run in a highly restricted environment. All changes are done via complete re-imaging of the service servers. Servers use full disk encryption and the key must be manually entered at boot. Data layer servers will have intrusion detection, shutdown if tampered with, leaving data locked on disk.

Plenty More

This is just one aspect of our security, focusing on how our systems will remain anonymous and keeping attackers away from user data. Our security procedures encompass far more, in everything from day-to-day devops and change auditing, to physical security for our users on dates, to server and resource acquisition policies.

We have extensive contingency procedures to ensure succession and continuity of service, protecting our users and investors, even in case of loss of our core team. We’ll detail our disaster recovery plans, and how token-shareholders can participate in it, at a later date.

For now, rest assured that with every step, every message, every keystroke and tap PinkDate makes, we take into account both our own and our users’ security.