I talked yesterday at Bornhack about the current state of secure messaging and the different primitives and threats that groups are working to address.
The talk is on youtube.
Excited to see this work show up at IMC in November.
I’m excited that the first project I helped on at Michigan will be presented at FOCI next month: An ISP-Scale Deployment of TapDance
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
git clone https://github.com/GNOME/gcr
git apply 0001-patch-for-osx-compilation.patch
PATH=/usr/local/opt/gettext/bin/:$PATH ./configure --enable-valgrind=no --enable-vala=yes --disable-nls --prefix=/usr/local/opt/seahorse
git clone https://github.com/GNOME/gnome-keyring
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
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/
To run, you’ll need to run these components connected by a DBUS instance.
The following script seems to accomplish this:
dbus-daemon --session --nofork --address=unix:path=$HERE/unix_listener &
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 &
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gcr/gcr-prompter &
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./seahorse/seahorse
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:
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.
I’ll be talking at Linux Fest Northwest in a couple weeks.
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.
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.
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 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.
In 2014, Domain Fronting became the newest obfuscation technique for covert, difficult to censor communication. Even today, the Meek Pluggable transport serves ~400GB of Tor traffic each day, at a cost of ~$3000/month.
The basic technique is to make an HTTPS connection to the CDN directly, and then once the encryption has begun, make the HTTP request to the actual backing site instead. Since many CDNs use the same “front-end cache” servers for incoming requests to all of the different sites they host, there is a disconnect between the software handling SSL, and the routing web server proxying requests to where they need to go.
Even as the technique became widely adopted in 2014-2015, its demise was already predicted, with practitioners in the censorship circumvention community focused on how long it could be made to last until the next mechanism was found. This prediction rested on two points:
We’ve seen both of these predictions mature.
Cloudflare, explicitly doesn’t support this mechanism of circumvention, and coincidentally has major Chinese partnerships and worked to deploy into China. Google also has limited the technique over periods as they have struggled with abuse (although mute in China, since the Google cloud doesn’t work there as a CDN.)
In terms of cost, the most notable incident is the “Great Cannon”, which targeted not only Github as widely reported, but also caused a significant amount of traffic to go to Amazon-hosted pages run by GreatFire, a dissident news organization, and costing them significant amounts of money. GreatFire had been providing a free browser that operated by proxying all traffic through domain-fronting. Due to a separate and less reported Chinese “DDOS” they ended up with a monthly bill for several tens of thousands of dollars and had to turn down the service.
The latest strike against domain fronting is seen in posts by Cobalt Strike and FireEye that the technique is also gaining adoption for Malware C&C. This abuse case will further incentivize CDNs from allowing the practice to continue, since there will now be many legitimate western voices actively calling on them to stop. Enterprises attempting to track threats on their networks, and CDN customers wanting to not be blamed for attacks will both begin putting more pressure on the CDNs to remove the ability for different domains to be intermixed, and we should expect to see a continued drop in the willingness of providers to offer such a service.
When I was in Pyongyang a few years ago and had access to a cell phone, I recorded a bunch of the prerecorded messages that you hear when dialing or mis-dialing numbers. I found them to be an interesting glimpse into the view of technology seen in that corner of the world, and helpfully they were translated into English for my edification. I’ve put them up here, and reconstructed the phone tree you get when dialing 999, so that the different messages can be heard in context.
At the end of last month, Seattle posted a request for information exploring the feasibility of a municipal Wireless deployment. With others at the Seattle Privacy Coalition, I draft a response to the city flagging some of the major privacy issues that we hope they will consider in the initiative. I believe these are much broader than just our specific case, and hopefully can help others when navigating the landscape of business models and privacy risks in this area.
Freely available municipal wireless Internet is an exciting service, but there have also been Wi-Fi deployments that have had significant, unintentional impacts on citizen privacy. This brief from the Seattle Privacy Coalition attempts to highlight some of the hidden costs that the City of Seattle should watch out for.
Many freely offered commercial wireless systems make money by selling analytics about customer behavior. An example is the Google-sponsored Wi-Fi provided at SeaTac airport and used in Starbuck’s coffee shops around town. While free to users, these services make money through the sale of user data to third-party advertisers.
This practice is especially questionable when low-income communities are targeted with ‘free’ services, greatly increasing the surveillance burden for an already vulnerable population.
Tracking and profiting from the sale of people’s behavior for advertising or other commercial purposes is a troubling practice at best, but it clearly goes against the public interest when it targets communities depending on a service as their primary or only access to the Internet.
Another threat to privacy found in commercial wireless deployments is the ability to track and analyze the behavior and location of every person in the vicinity, whether they are using the service or not. Cisco’s Meraki, a popular retail wireless product, advertises that it can “Glean analytics
from all Wi-Fi devices connected and unconnected.”
The city, perhaps unlike a business, has a responsibility to protect citizen privacy, and we think it would be irresponsible to track the locations of unconnected devices that have not explicitly opted-in to such a program.
From the start, the City must have a clear understanding of how collected data will be used, and it must not collect any data without the consent of the people tracked. Few citizens will welcome long-term, involuntary behavioral and location logging of their personal electronic devices by the government.
Finally, there are instances of wireless service which are based on a business model of injecting advertisements into web browsing. We merely note this is impossible to do without severely compromising the security of the Internet experience, and we do not believe that any trade off of benefits involving such approaches are justified.
We welcome additional digital connectivity through the city, and are especially excited by the potential for more equitable accessibility. There’s great potential in this technology, and while some incarnations impinge user privacy, many others have found successful models that avoid