My SSSS experience

On 2018-January-04, following a week of security and privacy events in Germany, I left Berlin for the United States via a connecting flight in Norway. I had spent most of my time in Germany at the 34th CCC (34C3) in Leipzig, and I was headed to New York to help Calyx Institute with some work that they and Emerald Onion are working on.

Upon getting to Berlin Schönefeld Airport (SXF), I checked in by visiting the Norwegian airline ticket counter. As expected, I received two tickets, one for my layover trip from Berlin (SXF) to Oslo (OSL), and another ticket for my flight from Oslo (OSL) to New York (JFK). On my ticket from Oslo to New York, I promptly noticed the “SSSS” in large, capital letters.

Secondary Security Screening Selection
Secondary Security Screening Selection (SSSS)


I was fortunate enough to be provided this clear warning. If you’re a high priority target, you probably won’t be so lucky. It is likely that if you are going to get SSSS, you won’t be able to pre-check online prior to your arrival, but, unfortunately, I didn’t attempt to pre-check on this occasion.

I set the “why” aside and immediately started thinking about mitigation and avoidance scenarios. In the information security space, this was like being alerted beforehand that a specific malicious actor with specific capabilities was going to be toying with me, my devices, and data. This was a gift.

SSSS has different severity levels, as there is some percentage of secondary screenings that are actually random. It’s up to you to plan for the worst. In addition to coming back into the United States, it is fairly well known that foreign nationals leaving the United States from conferences like DEF CON and Black Hat have a much higher probability to be hit with SSSS. Be prepared.


My secondary screening took place at the departure gate before boarding the plane to New York. I handed my boarding ticket with SSSS to the receptionist who scanned my ticket. The light flashed red, and she explained that I had been chosen for a random security screening. She took my passport and told me she would be keeping it until I finished the screening. The receptionist had a small stack of passports with her at the desk with no physical security aside from her looking at them. I verified with the receptionist that I would not be in possession of my passport until completed the screening.

The receptionist handed me off another security person with a clipboard. I observed the agent and the information on the clipboard. I had enough time to read through half the list, but intuitively decided not to commit any personal information to memory. Based on the data on the clipboard, there were 28 passengers who were “randomly” selected for secondary screening from a near full flight of a Boeing 787 Dreamliner. The list had women and men on it, and listed their first and last names, their gender (“Ms” and “Mr”, presumably based on info provided when purchasing the ticket), the originating airport and the destination airport.

The agent with the clipboard circled something on the line with my name and had me stand in a line that lead off to a private screening area. A third security agent came up behind me within a minute of standing in line and asked me to come into the room with him. He had me take off my bags but not my heavy parka, and had me take off my shoes. I was asked to verify my first and last name. I was asked to hold out my hands for a swab used for detecting chemicals used in explosives. The same swab was used for the outside and inside of my shoes. I was asked if I had any electronic tablets or computers. I took out my Surface and he used the swab on it, too. I was not asked to turn on the device.

The agent stated that I could put my shoes back on and after the swab analyzing machines displayed green that I could go, and I joked that if it turned red he’d be making some calls. He laughed and agreed. When leaving the private screening area, there were two people waiting in line for the secondary screening. I was told to go and speak to the first security agent (the receptionist) to get my passport, unescorted. After being handed my passport back, I tied my shoes and got on the plane.

My SSSS experience appeared to be random but I found evidence against that. There were 272 people who were flying from Oslo to New York, and 28 were on the SSSS list. I confirmed with one other person that they, too, attended 34C3 in Leipzig, Germany. A second person, from Twitter, also confirmed that they attended 34C3 and received SSSS on their way back to the United States.


Interestingly, also on 2018-January-04, the United States Department of Homeland Security, Customs and Border Patrol released an update to their Directive for Border Search of Electronic Devices:

Just a week earlier, Kurt Opsahl and William Budington of the Electronic Frontier Foundation (EFF) presented at 34C3 on this exact topic:

Legal Theory

I was traveling with a personal computer with Emerald Onion business secrets, like service account information, operational data from random technical and administrative chats (that are otherwise end-to-end encrypted), and client-privileged communications. However, my knowledge of my rights were limited being outside the United States.

When traveling, there are two questions: Who is searching you, and what are your rights in those instances?

There are three categories of entities that may search you.

The first is the United States Government (USG). If a USG official is searching you, you have constitutional protections. The second is a private company. If a private company is searching you under the direction of the USG, then you may have constitutional rights. The third category is foreign governments, which are subject to their own laws and search analyses.

In the US, as a US citizen, your rights generally come from the Fourth Amendment of the US Constitution, which enshrines the right to be free from unreasonable search and seizures. Inherent in this is that, if the search is reasonable, then it is not a violation of the Fourth Amendment.

Searches at the border have more leeway for reasonableness, as the USG is seen as having an increased interest in searching those entering in our borders, often called the border search exception. This is why electronic devices can more easily be searched at the border, whereas once inside the US, there would be more stringent requirements.

However, privacy rights still exist despite the border search exemption. The search still must be reasonable, it’s just the reasonableness bar is very low. There are also certain privileges that exist, such as attorney-client privilege, and trade secrets and similar intellectual privacy privileges. The government cannot legally force you to waive these rights, which is in fact the purpose of them.

Another right citizens have is the right to enter the US. A US citizen, almost always (except, potentially, in extreme circumstances like being an unlawful enemy combatant) has the right to enter the US. Therefore, US citizens can always refuse to give up their passwords or access to their devices, and still assert their right to return home. However, US border agents can still seize your devices and hold you for a period of time.

There are many legal reasons why you can push back at a border search. However, the question remains: how much do you want to push back? Border officials can legally do invasive things, such as seize your electronics and detain you for a significant period of time.

Technical Preparation

Tails Linux is always my favorite for traveling across borders. Tails is stateless, aside from small amounts of encrypted data in my (opt-in) persistent storage. However, I know that if any of my devices, USB included, leave my person and sight, they have to be distrusted and burned. Auto-torifying network traffic makes it easy for me to download or upload high value data from onion addresses via ssh and rsync, and I don’t need to deal with any untrustworthy VPN agents or infrastructure.

Static self-hosted VPN infrastructure isn’t trustworthy, especially when you’re a target. Commercial, single-agent operated, cloud-based (other people’s computers) VPNs can never be trustworthy, despite people’s strong desires for them to be.

Some useful points:

  • Before leaving home, I backed up my data to other encrypted devices.
  • I don’t travel with access to systems or authenticated communication mediums I do not need.
  • With proper 2FA and unmemorable passphrases, if I were asked to provide access credentials to specific accounts, I could tell the truth (don’t ever lie to a federal agent, anywhere) and yet wouldn’t be able to comply with the disclosure of account credentials. The 2FA (Yubikey, OTP device, etc) are kept at home in a trusted, safe place.
  • I don’t travel with a full list of contacts. No need to jeopardize the security and privacy of friends, family, etc if you won’t need to contact them during a short trip.

Technical Response

When going through mental scenarios, it occurred to me that there were two specific features that I would have liked to have in my chosen password manager:

  • A panic button (meaningful obliteration of data, but fortunately with Tails Linux, this is less important)
  • Functionality to support onion-hosted databases and key files

When first recognizing SSSS, I immediately thought about wiping some devices and even burning them before going through security. I refrained from doing this, but I later confirmed that, in this specific scenario, I did have the right to wipe or destroy devices. It felt like I did not have a right to do this since I am not a Norwegian citizen and thus I did not have any known protected rights in the country where the secondary screening took place, and more importantly, had no prior knowledge of which organization is performing the screening.

I focused on several preemptive tasks based on my limited access and knowledge:

  • People: alerting the people that I had secure access to about the anticipated breach (oh and Tweeting about it)
  • Device access: shutting the devices down and depending on hardware initialization and kernel boot security
  • Keybase groups: revoking the devices I was carrying
  • Signal groups: informing the participants the nature of the event, deleting the group itself, unregistering the number then deleting Signal
  • Password databases: shredding the database file and physically disposing of the corresponding key file

Looking forward

It’s important for technical folks, who have privileged access to presumably secure digital systems, to be aware of this type of physical, government surveillance. It’s also important to talk about this type of stuff with your co-workers, family, and friends. If you have contacts who are activists, journalists, or lawyers who are also likely to travel with sensitive data, please have conversations with them about this stuff, too!

Tor as infrastructure: challenges and opportunities

Infrastructure as a Service (IaaS) is commonly used within enterprise environments whereby organizations pay for someone else’s physical or virtual resources, including networking resources. Individuals also pay for IaaS when, for example, they need to deploy a VPS or VPN for personal use. From Gartner:

Infrastructure as a service (IaaS) is a standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities are owned and hosted by a service provider and offered to customers on-demand.


Tor, the network of operators that make up the network, is IaaS. What is unusual about this terminology is that the Tor network is distributed, and utilization of this networking resource is free. Companies like Duck Duck Go, Facebook, New York Times, and every organization utilizing SecureDrop including the Associated Press, is using this IaaS in order to best support their users’ privacy rights.

A problem that Tor network operators have always faced is that setting up and maintaining the network is not free. Tor is free-to-use IaaS on purpose — people and services need to be able to use the network without attribution in order for Tor to provide specific guarantees of privacy.

If privacy infrastructure operators had better funding, we would be in a better position to support larger infrastructure needs. For example, if Mozilla or Brave ever wanted to collect browser telemetry over Tor onion services to best support the privacy of their users, the Tor network would likely need to pivot towards larger and more stable network operators. In this article, we will look at some of the challenges and opportunities for operators of privacy infrastructure.


Emerald Onion was created, in part, to be able to demonstrate a successful Transit Internet Service Provider that only supports privacy IaaS. It was designed to best leverage existing laws in the United States in tandem with operational designs that require privacy-focused security properties. There have been and continue to be serious challenges facing Emerald Onion along with any other organization that is dedicated to privacy IaaS.

IP transit service is exclusively a for-profit business

IP transit is a required part of an ISP. Emerald Onion, Riseup, Calyx, Quintex, etc, need to pay upstream providers who provide the physical transport of the encrypted packets that we transit as part of the Tor network. This transit service is expensive. For example, 1Gbps of service in a residential setting can cost around $80 per month in Seattle, and 1Gbps of service in a datacenter can easily cost $800 per month. This dramatic cost difference is because of capitalism — it is presumed that a service provider in a datacenter environment is going to be profiting off of this service. Upstream providers don’t care one bit that Emerald Onion is a 501(c)3 not-for-profit supporting human rights.

Little options for trustworthy, open source hardware, particularly networking equipment

Emerald Onion is using general-purpose computing devices (currently low-power Intel Xeon D) with BSD operating systems. It is a priority for us to be using trustworthy compute infrastructure, so we are at least ensuring that the kernels and applications that we use are free/libre open source software. We hope to transition to free/libre open source hardware and firmware as soon as we can, but we also have to be concerned with compatibility and stability with HardenedBSD/FreeBSD, and the cost of this hardware. We know that options exist for free/libre open source hardware, but this is still a very new and maturing market. To further complicate this prioritized need for trustworthy compute infrastructure, Emerald Onion has particular interest in 10Gbps networking for both the LAN and WAN.

One day, we’d like to be able to support 40Gbps and 100Gbps; however, we are not aware of any free/libre open source hardware and firmware that supports 40Gbps or 100Gbps networking.

High cost of network redundancy

Our proof-of-concept work has focused on low-cost options. This means we do not currently have redundancy at our LAN or WAN layers. Network redundancy for Emerald Onion, at minimum, would entail having not just one expensive IP transit link, but two, ideally from different upstream providers, which means two edge routers and two links to each of our Internet Exchange Points. This would also mean that we have to add redundant LAN switching, and all of this means increasing our rack space and power requirements. Basically, we would have to more than double our recurring costs to be able to have this level of infrastructure stability. While Tor itself is highly resistant to network changes, the more capacity that Emerald Onion, and other large Tor operators support, the greater the negative impact we would impose on the Tor network whenever we have to perform hardware, firmware, kernel, and application updates.

IPv4 scopes for exit operators

As an exit relay operator, Emerald Onion must own and operate our own IPv4 address space for efficiently handling abuse communications from other service providers and law enforcement. Additionally, relay operators who peer directly with other service providers in Internet Exchange Points (IXPs) who have their own Autonomous System Number (ASNs) also require their own IP space. The entire world ran out of IPv4 address scopes to hand out to new and existing service providers a few years ago, and this is a blocker for any new Tor operator who is working to achieve the same level of stability that Emerald Onion is working to achieve.

Tor exit relaying currently depends in IPv4 connectivity between Tor routers (middle relay to exit relay traffic, for example). To be given an exit flag, a static IPv4 address is ideal for the Tor network (dynamic IP addresses would require a few hours delay of client discovery in the consensus).

Tor exit operators would not need their own Regional Internet Registry (RIR) -provisioned IPv4 address space if the exit flag could be given to IPv6-only operators, but this is not currently possible. ORPort connections (inter-tor circuit connections from middle relays, for example) cannot usually generate abuse, so IPv4 scope leasing is an easier option if IPv6-only exiting was a possibility.

One idea that Emerald Onion has had is that it may be possible to make proposals to large organizations, including universities, that are sitting on very large IPv4 scopes. We think that these organizations might be willing to donate small (/24) scopes to not-for-profit Tor network operators.


Surveillance and latency minimization

Seattle is home to a very large telecommunications hub called the Westin Building Exchange (WBE). We know that this building has National Security Agency (NSA) taps on I/O connections that are likely to facilitate traffic to regions like China and Russia. Additionally, WBE hosts several of the Internet’s DNS Root Servers, several of which are part of the Seattle Internet Exchange (SIX).

Emerald Onion went through the process of securing our own ASN, IPv6, and IPv4 scopes from American Registry of Internet Numbers (ARIN). We needed these things to connect to the SIX. Connecting to the SIX means that we are physically and directly connected to as many as 280 other service providers. We made this a priority because direct peering, using Border Gateway Protocol (BGP), minimizes the amount of clear-net switches and routers that a Tor user’s exit traffic has to travel through to reach its final destination. Every switch or router that Tor traffic has to traverse is an opportunity for surveillance and adds latency.

This strategy for Tor exit router placement is also ideal considering DNS. Being that multiple DNS Root Servers are directly peered with Emerald Onion, this further minimizes a global persistent adversary’s ability to spy on what Tor users are doing.

Statistically, due to requirements in the Tor protocol, individual Tor circuits bounce around multiple countries before they exit the network. This means that a non-trivial amount of the traffic that Emerald Onion, and any other United States exit operator facilitates, comes from a middle relay not within the United States. In tandem, generally speaking, a non-trivial amount of Tor exit traffic is destined to American services like Akamai, Cloudflare, Facebook, Google, and DNS Root Servers. These two likelihoods, together, means the following:

Tor exit traffic that is destined to service providers in the United States is best served, in terms of surveillance and latency minimization, by Tor exit operators that have exit relays connected to IXPs in datacenters along the coasts of the United States where undersea cables physically terminate, presuming that popular service providers like Akamai, Cloudflare, Facebook, Google, and DNS Root Servers are direct peers. This, in theory, minimizes the opportunity for American-sponsored traffic analysis, data retention, and surveillance, in addition to any other global persistent adversary who may have compromised network equipment within IXPs.

Emerald Onion has already compiled an initial list of IXPs around the United States. We continue to work on a list of qualities that an IXP should have that is a ideal for a Tor network operator:

  • Number of participants — This is important because if there is a peering link (using BGP) with another service provider, the opportunities for surveillance are minimized. For obvious reasons, the amount of direct peers is as important as the popularity of said services.
  • Access to specific participants — This is important because, for example, peering agreements with large providers such as Akamai, Cloudflare, Facebook, Google, and DNS Root Servers minimize the opportunity for surveillance while minimizing latency.
  • Nonprofit and affordable — A large number of IXPs are for-profit and thus have high up-front and high recurring costs for connectivity, in addition to setup fees and recurring fees for copper or fiber maintenance.
  • Geo-location — This is important because of, at least, location diversity, peer diversity, and direct connections with international undersea cables are focal points for the facilitators of global passive surveillance.
  • Prohibits network surveillance — The Seattle Internet Exchange, for example, has a stated policy that prohibits surveillance on peering links. One day, we hope that the SIX, and other public-benefit IXPs, will also publish a regular transparency report.


Emerald Onion has been in operation for 10 months. We wouldn’t exist, as we are today, without the generous startup grant of $5,000 from Tor Servers. We also would not still be around without the continuous donations from our Directors who personally donate as much as $350 each month. We currently require roughly $700 per month to operate, largely due to our service contract with our co-location provider who is also our upstream transit ISP.

Going back to the beginning of this article, the Tor network is a privacy-focused IaaS. Sustainability is a constant issue for Tor network operators, especially for operators who preemptively tackle legal and long-term operational challenges. We need help. There is no easy answer for funding. Grant writing and grant management is not a trivial task, nor is sustaining a 501(c)3 not-for-profit purely based on part-time volunteer work. Emerald Onion is incredibly lucky to have a few people who regularly donate large amounts of money and time to keep the organization online, but this is not sustainable.

The operations model that Emerald Onion has created, however, is scalable if properly funded. If we were provided between between $7,000 to $10,000 per month, we could multiply our capacity by a factor of 10. If we had a pool of funding that supported 10 independent Tor network operators in the United States (there are over 100 IXPs in the United States), we could dramatically bolster the capacity and stability of the Tor network while also minimizing network surveillance opportunities and network latency.


I hope that this article begins to shed light on the challenges facing privacy IaaS providers like the thousands of operators that make up the Tor network. Emerald Onion is going to continue to educate others on these topics, attempt to find and create solutions for these challenges, and continue to encourage hacker communities around the United States to build their own privacy-focused not-for-profit ISP.