Blue MormonMP3 ↓ 3:21
Hello! I’m Justin Fairchild, a full-time IT engineer and spare-time songwriter.
Late last year, I bid a fond farewell to my home media server hosted on a Nokia N900 Linux phone. For all of the innovations in the interface and design the erstwhile N900 had, you needed to be an expert-level Linux system administrator to keep one functioning, so eventually I named my phone Nusiance. This meant my spare, which served my music and video collection on a succession of larger micro-SD cards, became Twosiance. (Read More...)
Twosiance worked hard for me for over 5 years, both as a lightweight file server and as a playback device directly attached to my entertainment center. While the hardware would’ve happily kept running, the need to compile my own software to get new features and security updates became a burden. Running an always-on server over wireless is also a unique challenge, requiring cron-managed nightly firmware reloads to keep the wireless device performing steadily.
Unlike PCs, mobile devices lack the architectural consistency or corporate backing to support perpetually-updated Linux kernels and OS distributions. So we lose out on having little servers with battery back-up built in. With the advent of cloud provisioning, few people want low-power battery-powered mobile servers, but from a security perspective there's no substitute to directly managing your own data. In a world where the only provably-secure data is directly managed by individuals, such a system will eventually be necessary.
Designing a Public Key Infrastructure means managing keypairs to implement signing chains. These keypairs are the cornerstone for transport security (TLS) or code signing (software whitelisting, market restrictions). In other words, signing chains are crucial elements of both computer security and creating artificial scarcity on the Internet. So for those of you who don’t aspire to understand computer security, follow the smell of money and stick with me. (Read More...)
Cryptographic signing is process used to attest that the contents of a file haven’t changed since the moment-of-signing. For public-private keypairs, a signed public key is certified as a valid means of identifying services, particular servers, or other end-entities you may talk TLS with. Yeah, end-entity sounds clumsy, but just be grateful that PKI folks managed to avoid loading the word object with yet another jargon-definition.
Now let’s talk signing chains. In principal, signing chains illustrate the relationships between the holders of each keypair in the chain of trust. Typically a signing chain is a single path through a tree of other trust relationships. At the furthest edges of the tree are the leaf certificates, issued to end-entities such as servers (TLS) or whitelisted programs (code-signing). The keypair that signs a leaf certificate is generally an intermediate Certificate Authority.
These intermediate CAs are typically signed by a chain of one to two other intermediates, until you get to the root of the signing chain, which is called the Root Certificate Authority. Generally, the Root CAs are what your Operating System comes installed with so that your system trusts the leaf certificates it sees on the Internet. In other words, these Root CAs are the trust anchors that your OS uses as a reference. When your OS talks TLS, as soon as it encounters a trust anchor in a signing chain, the chain is considered valid and communications will proceed.
Since the Web PKI’s purpose is to ensure the authenticity of the services you talk to, we need to think about trust in the context of signing chains. When you visit a website, trusting a signing chain (and getting a green lock) means three things, in order of dependency:
Like taking advice from a succession of strangers, trusting a server means you trust every “authority” in this sequence. Each hop is another level of indirect trust worth thinking about for a PKI designer.
Last time, we discussed trust from the perspective of software politics and incentives. Another way to discuss trust is by talking about behavior or events that would compromise or threaten trust. This is a limited form of threat modelling. It may seem self-evident that security of your PKI depends on the security of your client and server OSes. Unfortunately, weak system security or outdated software often makes it frighteningly simple to compromise unencrypted private keys at rest, or add rogue CAs to your OS trust store as a trust anchor. Threat modelling of transport-level issues prior to solving endpoint security puts the cart before the horse. Although techniques exist for protecting key materials from the OS using hardware security modules, cross-platform standards for this protection remain immature at best, or nonexistent at worst.
Assuming your system security is implemented perfectly, PKI trust additionally hinges on the default Root CAs your software vendor manages. System updates tend to add or remove CAs from your OS trust store, and for any system on the broader Internet, if you don’t trust a broad set of CAs, you’ll get error fatigue from certificate warnings and connection failures. Basically, we blindly hope that the policies and procedures used by OS vendors to vet the controllers of CA private keys are sufficient. Oftentimes, it is not, so whenever you write software intended for use in a constrained environment, you can improve your transport-level security by maintaining a thin trust store, where only specific CAs or remote certificates that you trust are included in your trust store.
The last facet of signing chain trust to discuss is the chain validation step. Validating a signing chain means validating that each certificate in the chain is trustworthy, and not revoked by the signing authority. It will take more than one future article to discuss validating certificates, but due to how browsers implement trust, chain validation becomes a separate monster. In the ideal case, web servers include the entire chain of intermediary CAs leading to their signed server certificate, and in this case chain validation is equivalent to validating every certificate in the chain. Although web browsers wisely treat the world as non-ideal, this causes subtle problems.
When a browser is able to validate a fully formed signing chain, it tends to cache the state of a CA’s validation in an opaque, non-standardized way. I’ve seen these caches persist even when the “Clear Private Data” feature is used. So when a server presents just a leaf certificate, the browser might say the chain is valid, even though the missing cached CAs could have been revoked. If you care about the security of your users, be dogmatic about hosting your entire signing chain, up to (but not including) your root CA. Client trust stores hold their system’s trusted root CAs, so server signing chains don’t need to include them.
If you read closely about how chain validation works, you may have noticed that as a client, you have few options if you wish not to trust an intermediary CA signed by a trusted root. Again, we hope that root CAs have solid vetting practices for anyone they issue intermeidate CAs to.
Knowing the basics of signing chains, and being exposed to how they fuction in the real world, should make you deeply skeptical of how certificate validation works in practice. We’ll dive into certificate validation in the next installment of this PKI series.
Despite its issues, the Web PKI is the broadest, most visible implementation of certificates in the world. The emergent complexity of PKI just for web browsing leads me to believe that future widespread implementations of signing chain trust will rediscover many of the same threats and problems.
At some point after I discovered Linux and the joys of running my own Internet services, I began wanting security assurances. No matter where in the world I was, I wanted to guarantee that I was communicating with exactly the network endpoints that I had originally configured, and that no-one could casually intercept network messages to my servers. (Read More...)
This is how most people are introduced to the realities of TLS certificates in the Web’s Public Key Infrastructure (PKI). But certificates and signing are either a deep rabbit-hole or a bottomless pit! To truly comprehend the lifecycle of a certificate in the Web PKI, you’ll find yourself creating your own Certificate Authority, rather than simply purchasing certificates from an online third-party.
Managing my own personal CAs has been a non-trivial side project. The most difficult part is not technology or tooling, but understanding the spectrum of design choices and cohesively reasoning and documenting all of them. Hopefully this series on PKI design helps you understand one of the Internet’s foundational technologies, even if you decide that building your own PKI is better left as a thought exercise!
When you trust a server’s certificate, you are allowing your computer to begin an encrypted network connection to that server. Having trusted communications is valuable, but more important are the standards for how businesses securely store data on their servers. Web PKI and Transport-Layer Security standards have nothing to do with the security of data at rest on a server. Even an Extended-Validation certificate could easily be issued to someone who’s server has been secretly compromised without either the server admin or the issuing authority’s knowledge.
PKI trust only refers to the security of the network communication to a server. While this trust ends up being weak, it’s still better than having no assurance you’re actually communicating to, say, your bank. A good metaphor for PKI trust is checking someone’s driver’s license and saying “you resemble the person in this photo — carry on!” As a random observer, you’re not trained in how to validate the details of a license, though you can judge on appearance and fit/finish that a cheaply-made fake ID might lack.
If your computer shipped without a pre-installed set of trusted certificates, all Internet trust decisions would be similar to the “gut” decision around validating a driver’s license. Fortunately, operating systems or browsers make trust decisions on your behalf by including a set of default-trusted Certificate Authorities. Trusting your OS is one component of the indirect trust involved in the Web PKI. To understand the others, I’ll need to discuss how signing chains work in a future installment.
Conceptually, indirect trust is very weak, only one level above “gut trust”. And the more levels of indirection, the more fragile the trust. However, it’s possible to manage your trust chains and certificate issuance more directly, by creating your own Certificate Authority, and managing your OS’s list of CAs. For signing chains, the more you control the keys and system security of each step of the signing, the more you can trust the server certificates in the chain.
With all that indirection, the green lock in your browser starts feeling pretty fungible! Your OS trusted a third-party CA, and you trust your OS, therefore you should trust the remote server is the rightful recipient of your web traffic. But the remote server might be compromised, and the remote service’s data security practices might be questionable, and the OS vendor or CAs may have shady dealings with governments or institutions you don’t personally trust. Heaven forbid that a CA owner decides to sell their service to a new company — should you just trust that the new company has the same interests in managing the CA they purchased? Who knows!?
PKI trust can be modelled like any series of trust relationships between institutions, where any link in the chain appears brittle under the microscope, and yet there is great public and economic value in maintaining the chains and offering some definition of trust, even a weak one. Crucially, the social and political management of PKI services should be the basis of whether you trust a section of the Web PKI or not. Trust and risk management cannot be automated or programatically solved in the same way that other computer science and data management tasks can.
I play piano, violin, harp, bass guitar, synthesizers... and look how little I have to show for it!
One of the Maruyama Red Panda twins, Kin, passed away suddenly last week due to a bowel obstruction. She left behind her mate, Singen, and a panda cub that’s not even two months old. Kin was gentle, sweet, good at sharing but still willing to tussle and defend herself. She’s given me such joy, and now that Kin is a star in the sky, I wanted to share some video memories of her life.
For data, what some folks consider paranoia, I consider principles.
Happy Birthday to Maruyama Zoo’s precious, beautiful basketcase twins, Kin and Gin, born on July 20th, 2012. Both are recent red panda mothers, with Gin’s baby girl Marumi being born June 15 of last year, and Kin’s newborn having arrived on July 7 of this month! To spread the joy these little ones have given me, I’ve created a playlist of Kin and Gin favorites, starting with the classic “Who are you? Red Panda has seen it” featuring their cutest, coldest stranger-stares. Watch for cameos from the rest of the family bears! ♥
With a new version of Constantina released and live, I thought I’d indulge a graphic idea I’ve had for a couple of months. While the project might have only taken 30 minutes, the design employs a retro-futuristic typeface that's at least 50 years old, whose name has been collectively forgotten from the entire English-speaking Internet. (Read More...)
Meanwhile, on the fantasy Kobaïa-On-Line intergalactic network, their financial institutions and official documents are liberally slathered in this unknown typeface. At small type points, hopefully they used something vaguely more readable, though no less delightfully obscure.
So, the plan was to take two of my favorite science-fiction egyptological musical passions, harmonize them into a unified design, and sell a tiny batch of T-Shirts. Whoever buys one of these fusions of the Hieroglyphics and Magma band logos, is a very precious snowflake that I would love to talk music with!
But after three evenings of almost-totally failed searching on fontspring, whatthefont, identifont, and countless others, ingesting new typography jargon, searching by foundries and original creators, and grasping at metadata for anything resembling my curio vampiric triangular block capitals, I almost wanted to recreate this nameless enigma from scratch! For now though, I have a typeface that almost hits the same pre-disco apocalyptic emotional cues. I grimace at its relatively amateur feel, and how its name actively mocks my attempts to bend the Internet towards appreciating rare typographical wonders that only appear on album covers by Magma and Stevie Wonder.
Just a quick update. Codaworry was offline all of last week, since I underestimated the work it would take to massage this special snowflake onto the latest version of Constantina. The software now supports authentication, and as a result, I ended up shuffling around lots of files that were public-by-default into files that become inaccessible given that authentication is turned on. It’s one of those infuriating things where nothing looks different on the outside, but the soul was reincarnated into something new.
As I get older, I’ve had some age-related changes in how I think about what’s important. One of my favorite things now is seeing people, animals, and other life that is growing, well-taken-care of, able to be happy just by being. This feeling came about slowly over time, but now the feeling is so intense and fundamental that it has become non-conveyable, like how I can share why I’m happy about a sunny day but not what it feels like to have blue eyes or be a man. Today I’ll show you where this came from. (Read More...)
At the Maruyama Zoo in Sapporo, Japan, there are two red pandas, Coco (an 11-year-old female) and Seita (a 12-year-old male). Coco came from Saitama Children’s Zoo in November 2007, and Seita joined her from Chisuyama Zoo in July 2008. They might not be special if it weren’t for Miyano Mayu’s blog, where she has celebrated “the little things in Hokkaido” nearly every day since moving to Sapporo in 2005. The number of photos and videos she’s posted of Maruyama’s red pandas must be in the tens of thousands, but her joys of observing life extend around and beyond her beloved zoo animals, parks, mountain-trolleys, and the epic snowfall of her home city.
Red pandas are rare and precious, less than 10,000 remaining in the wild, limited to the stretch of highland jungles and bamboo veins around the Himalayas, across China, Nepal, Bhutan, India, and Myanmar. Through Mayu’s succession of three blogs and her YouTube site (Mmovies21), you can slowly watch Coco and Seita growing up together, fighting for apples, climbing up and down and sideways around their enclosures, snoozing and relaxing in the sun, safe from predators like snow leopards, and poachers who could sell their pelts for the price of a small car. Humankind cannot account for what we consume in the world, but we do have zookeepers and volunteers that can make space for these animals to just be, where we can learn enough to care for them.
Zoos are required by their charters and policies, to vouch for the conservation of species, and to appeal to our desire to protect the world for our children. Perhaps this appeals to our self-interest, how if we don’t preserve the world, we’ll be worse off in the future. But it’s subtly disingenuous, because I think the best outcome for a zoo is giving a place for animals to be loved. Humans have no ways to deeply interact with red pandas, and these adorable little creatures are not actually that warm, caring, or emotionally relatable, being devoted to eating bamboo and sleeping 16 hours a day. Like newborn babies that just need but have no means to give back, they can only be loved.
Coco and Seita have conceived three times, first giving birth to twin girls Lily and Lila in 2010, another set of twin girls Kin and Gin in 2012, and finally a boy Hokuto in 2014. With all the girls being born, Maruyama Zoo brought in a sprightly 2-year-old male from Chiba Zoological Park named Eita in late 2013. They’ve had wonderful spaces to live, full of overhead bridges and tracks, a giant oak tree, and both indoor and outdoor enclosures. The more videos you watch, you start recognizing their unique faces and tails, as well as their little moods and attitudes and power-structures with each other. When Kin was moved to Kushiro Zoo and separated from her sister Gin in May 2016, after seeing those two grow up together in hundreds of videos, I was devastated.
However, Kin’s move helped Maruyama make space for something wonderful. After unsuccessfully trying to conceive in 2015, Gin and Eita had a baby girl in 2016. Baby red pandas are covered in fluffy gray fur and are tiny enough to be weighed in small plastic buckets, which is done frequently to track that the baby is growing successfully and being fed appropriately by the mother. Red panda infants have a high mortality rate, subject to both neglect or over-parenting, as well as fungal infections and diseases like canine distemper. So every time Mmovies21 or Cattail Sapporo posted a new video, and the baby’s weight ticked up slightly higher, and after every passing day it seemed more likely that the baby would survive, it was something to celebrate and cherish. Marumi is now 8 months old, a puffy round bundle of fur and spirit, and I’ve watched her learn to eat apples and grapes, learn to shimmy over logs and eventually climb, discover how fun it is to chase her mother’s tail, and explore the world with wide-eyed wonder. Coco and Seita are now grandparents, and Maruyama’s family bears continue to thrive and be loved.
I don’t think happiness is a journey or a right or something you discover. I think you build and cultivate it with the world, and are thankful for it, because it cannot be promised or guaranteed. In October of last year, San Jose got its very own red pandas, a 2-year-old male named Will Smith and a 5-year-old female named Gaila. One of my favorite hobbies is visiting Happy Hollow Park and Zoo, catching the lemurs with their arms stretched out laid back in the sun, witnessing the goats make advances at anything that looks like a grass pellet, or seeing Will do whatever he likes, even if it’s nothing at all. And now you know why!
Special thanks to Maruyama Zoo and Happy Hollow Park and Zoo for taking care of my precious bears, and to Miyano Mayu who sees the extraordinary in the small things of the world.
The trend right now is flat design, but I thought I'd try adding a little texture.
Why is it so hard to start something new? I’m not sure if it’s knowing the time sink of a project prior to starting, not wanting to fail after spending that time, being afraid of new things or changes that you can’t expect, or maybe just fear itself — nothing to be afraid of! (Read More...)
I want Constantina, the engine behind this site, to become a community platform. When I first wrote Constantina in 2014, my goal was having a easily-browsable web journal that gave you my thoughts and feelings in the exact structure and aesthetic I intended. In the three years since, I’ve become more interested in connecting with peers and less interested in having an audience. Although I want people to care about the things I have conviction in and spend hours on, without power or excess social signalling, nobody really cares about what I do. While doing projects in my isolated way fuels the engine of my life’s meaning, that engine doesn’t power anyone else. So hopefully Constantina helps me find a small group whose engines run together.
In the meantime, the juggling continues. Barber’s violin concerto is on my practice list, the authentication/session handling for Constantina has been designed and awaits becoming real code, and San Jose is recovering from one of the nastier floods in recent memory. May none of your life’s new beginnings turn out to be false starts!
Since my last update, the Constantina engine that powers Codaworry has grown by 600 lines, though closer to 1000 lines of code have seen serious refactoring. Until recently, very little appeared to change, but under the hood I was fixing the card distribution and randomness functions, refactoring complex objects into simpler smaller ones, tidying the backing file stores, fully rewriting how input is validated, and squashing a subtle off-by-one error that quietly hid every 10th news post. You may notice the most recent change though, where each page refresh randomly chooses from three different site themes. This visible feature wouldn’t have been possible without all the invisible ones supporting it. (Read More...)
I’m within a month of releasing Constantina publicly, as a blog-engine with emphasis on responsive layout and randomly distributed static content. But my motivations for Constantina finally becoming release-quality had little to do with altruism, and more to do with trust.
Coming online and of-age in the mid 1990s, the Internet was three wonderful things at the same time. Firstly, it was rounds of deathmatch Quake or Worms against total strangers. Secondly, it was a wealth of information that felt as well-researched as books from the library, but much quicker to use. Finally, it was a way to socialize and share with people at the speed of writing, possibly the only type of socializing I’m categorically comfortable with. I love the idea of discovering truth slowly and conversationally, with ample time to consider details and sand-down the rough logic of instantaneous thought.
The Internet now connects us right down to our handsets, and the medium of text-image-video communications have been thoroughly explored, such that futurism compels you to imagine a world of deviceless telepathy and telepresence. An Internet user from 1997 would be enthralled with today’s Internet, though the Facebook-style socializing would definitely be confusing at first. Over time, as the reality of having an online social life and reputation sets in, perhaps they’d marvel at how completely the utopian fantasies of Internet pioneers have evaporated. The closer society moved to the Internet, the more the Internet reflected everyone’s base desires, needs, struggles, and weaknesses — consequentially, the Internet is a place where trust is earned, never assumed.
The early days of ISPs, trust and PKI, networks and services, have a sepia-tinged innocence to them now. Network surveillance would bother our transplant-from-time no less than us, and the variety of techniques for compromising software is clever beyond the wildest fantasies of 20th-centry science fiction. Network security problems were a distant shadow at the edges of my wasted hours on Perl WWWBoards — today they are unavoidable facets of our networks and our software engineering. Having social media accounts, making calls or using maps on a cellphone, or relying on a free email provider, equate to consenting being watchable and trackable indefinitely. Social pressure and convenience put nearly everyone in the same bucket of mutually-assured disclosure.
In computer security, it’s impossible to account for all threats or compromises in a system. Your goal as a system designer is to make it as expensive for your adversary as possible. In the corporate world, this amounts to hiring a computer security team and keeping a watchful eye. If you run an Internet service, it means you do regular pentests and code reviews, and design protections in line with the value of your data. As someone with a seed of 1997’s Internet still inside, I find myself thinking about the categorical version of this security problem: on a global untrusted network, how do you make it expensive to steal the private data of the network’s users?
While Facebook and friends have some incentive to protect the data exhaust you share with them, it’s a standard principal-agent problem — there will never be a mechanism to compel Facebook to value your data the same way you do. I believe the only way to categorically protect data on the Internet is for people to own and manage it themselves. This is the direction I’m taking Constantina, beyond a blog platform and into the realm of managing a small community of peers that write, share, plan, and grow with each other, in relative privacy.
Complex systems are expensive when you’re forced to reason about their outputs frequently. If you can’t simplify such a system, you require better tools or data to understand it.