All posts by Will

34C3

I’m very excited to have two talks at CCC at the end of the month. The bulk of accepted talks can be seen and voted on at the CCC “halfnarp”.

The first talk is on the Internet in Cuba. It expands upon the recent talk I presented at IMC last month, to provide additional color on what Internet access is really like in Cuba, and what the community there is doing to create LANs and other alternatives to the official but expensive ETECSA service.

The second talk looks again at technology in Pyongyang. Since 2014, there have been a number of talks about the totally closed off tech ecosystem there, but as it ramps up we continue to only get a few glimpses into what’s going on, and it’s getting only harder as the broader tensions ramp up. My goal is to propose a path for getting more rather than less transparency into the picture, because it is a really fascinating place.

The talks should both be recorded, and might even be streamed. If you’re one of the (I hear it could be up 16,000) participants, I hope to see you in Leipzig!

China in 2017

I had the chance to visit China last week and tag along with the tail-end of a longer trip organized around various Makerspaces around the region. This is the first time in several years that I’ve spent a prolonged amount of time in the dense population areas of Beijing and Shanghai, and it was fascinating to watch the evolution that continues in this majority of Chinese life.

The most noticeable change from my perspective is that Beijing and Shanghai are effectively almost cashless. The use of Alipay and wechat pay are ubiquitous, to the point that you feel that you are creating an imposition to shop keepers by paying with cash. While funding your account on either of these services requires a chinese bank account (which itself requires a mainland cellphone number), the process can be short-circuited by making an unofficial exchange with someone willing to send you a personal transfer within the systems. It remains easy enough to find people at hostels, (as well as localbitcoins, I hear) who are willing to trade.

The systems themselves are fascinating to use. Payment to a merchant will automatically cause you to follow the merchants account, typically leading to messages about member cards and discounts. These messages seemed to only be pushed directly in response to a purchase, and weren’t overly intrusive. It seems to be the realization of the business-to-consumer engagement systems facebook and google have been struggling and so far failing to build in the US. Smaller vendors often operate directly as individuals – you type in how much money the bill is, and send it as a direct transfer to an account specified by the waiter or merchant.

This payment structure has resulted in a secondary industry of android-based devices dedicated to sales and scanning QR codes for these systems, as well as receipt printers that turn app orders into printed requests for food or similar.

Apart from the payment evolution, it is really interesting to watch China modernize. Life there now is much more comfortable from a western perspective than it has been in the past, with both a larger presence of foreigners visible and more english available to help navigate. Some distinctive characteristics remain, including a self-interested approach to queuing and different expectations of personal space. Prices in Shanghai have reached parity with those in the west, although cheaper options remain if you look for them.

In terms of Internet connectivity, I was surprised to find that connectivity remained quite similar to what I had experienced in the past. An SSH tunnel to a foreign server was sufficient to maintain email access while I was there, and disruptions I experienced seemed to be much more a function of over-loaded local networks than of more restrictions for international traffic. I talked with a couple different people who mentioned that Astrill continues to not be blocked, and seemed surprised that something so well known continues to operate without disruption.

Accessing gnome-keyring on a mac

One of the more common password managers in linux environments is the gnome-keyring, which is split into a service (gnome-keyring-daemon), and a user interface (most commonly, seahorse).

After a bit of fiddling in the last couple weeks, this system can be compiled to run on a mac, with only a little bit of pain.

On the off chance that it saves someone some pain who’s trying to do the same thing, here are the basic steps I needed to take:

brew install autoconf automake dbus gettext gnome-icon-theme gobject-introspection gtk+3 gtk-doc intltool libffi libgcrypt libtool p11-kit pkg-config vala
brew install libsecret --with-vala

mkdir keyring-buildenv
cd keyring-buildenv

mkdir /usr/local/opt/seahorse

git clone https://github.com/GNOME/gcr
cd gcr
wget https://gist.githubusercontent.com/willscott/fb5d50eba8a2fda17b7ead7d6e6ed98d/raw/5dcdc33f617e1196d5b365dda6b3b8e798f6b644/0001-patch-for-osx-compilation.patch
git apply 0001-patch-for-osx-compilation.patch
glibtoolize
intltoolize
autoreconf
automake -a
PATH=/usr/local/opt/gettext/bin/:$PATH ./configure --enable-valgrind=no --enable-vala=yes --disable-nls --prefix=/usr/local/opt/seahorse
make
make install

cd ..
git clone https://github.com/GNOME/gnome-keyring
cd gnome-keyring
glibtoolize
intltoolize
autoreconf
automake -a
PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-valgrind --without-libcap-ng --disable-doc --disable-pam --disable-ssh-agent --disable-selinux --disable-p11-tests --disable-nls --prefix=/usr/local/opt/seahorse
make
make install

cd ..
git clone
cd seahorse
glibtoolize
intltoolize
autoreconf
automake -a
PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-ldap --disable-hkp --disable-sharing --disable-ssh --disable-pkcs11 --prefix=/usr/local/opt/seahorse/
make

To run, you’ll need to run these components connected by a DBUS instance.
The following script seems to accomplish this:

#!/bin/bash

#dbus session.
HERE=`pwd`
dbus-daemon --session --nofork --address=unix:path=$HERE/unix_listener &
DPID=$!

#keyring daemon
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gnome-keyring/gnome-keyring-daemon --start --foreground &
KPID=$!

#prompter
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gcr/gcr-prompter &

#seahorse
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./seahorse/seahorse

# cleanup
kill $KPID
kill $DPID

PUST in the news

The Pyongyang University of Science and Technology (PUST) has shown up in a recent New York Times article, and I’m mentioned at the end.

A couple notes on the article:

  • While the school may have 250 acres if the affiliated cooperative farms are included, the actual campus is much smaller, with ~10 buildings built around two sports fields.
  • The supposition of leverage is, I feel, more nuanced than expressed in the article. Detentions of Americans have and continue to occur across the different engagements. While PUST got unlucky this time, it provides no more benefit to the regime in that regard than the tourism or other ongoing aid projects, which have also experienced similar actions in the past.
  • PUST is not even close to the largest foreign community in the country, as stated, that honor goes to the Chinese

Projects like PUST are an opportunity to put a human face on Americans in the minds of the next generation of educators and empowered thinkers in Pyongyang. It’s hard to overstate the value of that engagement.

IETF 98

Last week I talked briefly about the state of open internet measurement for network anomalies at IETF 98. This was my first time attending an IETF in-person meeting, and it was very useful in getting a better understanding of how to navigate the standards process, how it’s used by others, and what value can be gained from it.

A couple highlights that I took away from the event:

There’s a concern throughout the IETF about solving the privacy leaks in existing protocols for general web access. There are three major points in the protocol that need to be addressed and are under discussion as part of this: The first is coming up with a successor to DNS that provides confidentiality. This, I think, is going to be the most challenging point. The second is coming up with a SNI equivalent that doesn’t send the requested domain in plain-text. The third is adapting the current public certificate transparency process to provide confidentiality of the specific domains issued certificates, while maintaining the accountability provided by the system.

Confidential DNS

There are two proposals with traction for encrypting DNS that I’m aware of. Neither fully solve the problem, but both provide reasonable ways forward. The first is dnscrypt, a protocol with support from entities like yandex and cloudflare. It maintains a stateless UDP protocol, and encrypts requests and responses against server and client keys. There are working client proxies for most platforms, although installation on mobile is hacky, and a set of running providers. The other alternative, which was represented at IETF and seems to be preferred by the standards community is DNS over TLS. The benefit here that there’s no new protocol, meaning less code that needs to be audited to gain confidence of the security properties for the system. There are some working servers and client proxies available for this, but the community seems more fragmented, unfortunately.

The eventual problem that isn’t yet addressed is that you still need to trust some remote party with your dns query and neither protocol changes the underlying protocol where the work of dns resolution is performed by someone chosen by the local network. Current proxies allow the client to choose who this is instead, but that doesn’t remove the trust issue, and doesn’t work well with captive portals or scale to widespread deployment. It also doesn’t prevent that third party from tracking the chain of dns requests made by the client and getting a pretty good idea about what the client is doing.

Hidden SNI

SNI, or server name identification, is a process that occurs at the beginning of an HTTPS request where the client tells the server which domain it wants to talk to. This is a critical part of the protocol, because it allows a single IP address to host HTTPS servers for multiple domains. Unfortunately, it also allows the network to detect and potentially block requests at a domain, rather than IP granularity.

Proposals for encrypting the SNI have been around for a couple years. Unfortunately, they did not get included in TLS1.3, which means that it will be a while before the next iteration of the standard and the potential to include this update.

The good news was that there seems to be continued interest in figuring out ways to protect the SNI of client requests, though no current proposal I’m aware of.

Certificate Transparency Privacy

Certificate Transparency is an addition to the HTTPS system to enforce additional accountability in to the certificate authority system. It requires authorities (CA)’s to publish a log of all certificates they issue publicly, so that third parties can audit their list and make sure they haven’t secretly mis-issued certificates. While a great feature for accountability and web security, it also opens an additional channel where the list of domains with SSL certificates can be enumerated. This includes internal or private domains that the owner would like to remain obscure.

As google and others have moved to require the CT log from all authorities through requirements on browser certificate validity, this issue is again at the fore. There’s been work on addressing this problem, including a cryptographic proposal and the IETF proposal for domain label redaction which seems to be advancing through the standards process.

There remains a ways to go to migrate to protocols which provide some protection against a malicious network, but there’s willingness and work to get there, which is at least a start.