Blue MormonMP3 ↓ 3:21
Hello! I’m Justin Fairchild, a full-time IT engineer and spare-time songwriter.
Codaworry has been offline for two months due to a migration, and since I assume readers care as little as I do about my brain ephemera, I just let it sit for a while. My first step aside from bringing this back online, is to start caring again. For years I’ve hoped to borrow self-esteem from others in my life, but I finally accept that no-one else will care about my dreams until I do. People don’t want to risk the mental space on someone that’s not intent on winning, of making their dreams and truth manifest and real. (Read More...)
Since I broke up with my ex in 2017, and have felt the fire (and been burned) with my current partner, it has taken some awful times to realize truths in my life, and what I need to do to keep myself healthy and strong. The most painful moments are crucibles, and whatever mixed feelings I had, my tears never lied to me. In my weakest moments I couldn’t deceive myself anymore.
Hopefully this can guide my songwriting, not just to aim for that frisson that makes every sense in your body tickle, but to make it ache too, a fragment of emotional truth that scars and then heals. I’ve looked for ways that music can be more meaningful, and it has less to do with the lyrics or the instruments or the singing, and more to do with offering a meaningful reflection of my emotional reality. Tears don’t lie.
On Gin’s birthday this year I baked the most delicious apple pie I’ve ever made in her honor, since apples were her soul food. Two days later she fell from a ledge in a freak accident, and now she’s sharing an apple tree with her sister Kin high in the sky. Gin-bear, small but fearless, full of life and attitude, will always have my love and my apples.
Words are trains, for moving past what really has no name.
In buying some stereo gear for a friend this weekend, I re-learned a crucial truth I’d forgotten in my long struggle to finish recording my songs. Feeling music is also about dynamics, about loud songs being as intense as they need to be, and quiet music having as much space as it needs to be softly felt. If you practice loud music quietly, you might be un-learning what made that music special.
Fingers crossed, but I believe all of the challenging development tasks for Red Panda Finder are complete. The last major feature I finished was a parser that builds a tree of search result sets based on some combination of subject names (pandas, zoos) and keywords. Plenty of work remains — I want to auto-generate timeline pages that show the panda’s life based on their sequence of zoos and neighbor animals. Of course, someday I hope to implement a WebGL browser-based family tree too. (Read More...)
But all projects have diminishing returns over time. At least with Red Panda Finder, adding a few photos and animals over time isn't a giant effort, and it keeps these precious little angels close to my heart.
I’ve started doing little recordings again, and I have a violin recital in under two weeks to practice for. One thing I’d like to do is start recording short pieces for people to use in their projects. Rather than think in terms of albums, to start with something lower-stakes, just as studies that might be useful for others. If the music finds its way into a red panda video on Instagram or YouTube, I’m sure I’ll be thrilled.
It’s been a while since I had a musical discovery quite this satisfying, though the discovery is pretty minor. Over time, my AKG 240 studio headphones, the most comfortable over-ears I’ve ever tracked music with, have become quite a chore to wear. Unfortunately I think the problem is me, not the headphones — wearing things tight around my head for longer than 20-30 minutes just feels awkward and wrong. And you can’t multi-track music in a studio without headphones. But there’s a solution! (Read More...)
Tonight was a cold day for the Bay Area in California, and I was wearing a beanie hat home. They’re so cozy and warm that I just wanted to leave it on inside. I tried putting my headphones on over the beanie, half out of laziness and half just to see how ridiculous the idea would feel.
Of course, I’ll need a new strategy when it gets hotter than piss outside, but there’s something really interesting in this idea. I’m going to stick with it!
Power pylons are amazing! They deliver the electricity our cities run and grow with, in the form of menacing alien giants that track the country, each step an angular metallic web of arabesque repetition and beauty.
Since late June, I’ve dove headfirst into a project which I hope to launch on International Red Panda Day 2018 — a family tree of all zoo-born red pandas, with hand-chosen Instagram photos and first-class searching. My friends know I care for these little guys, but it’s escalated into something my friends must find pretty odd! (Read More...)
I admit that things feel pretty out of focus right now, and that I’ve been myopically pushing this project at the exclusion of everything else. It’s exhausting to want this family tree to be finished, and still have so much left to do. And yet, every morning when I check on my Instagram red pandas, I feel validated in a way unlike anything I’ve ever done. Red pandas are the first thing I’ve ever loved where my passion feels meaningful outside of myself. They’re almost like extended family, little lights in the world that have value just for shining in their own way.
I hope everyone who loves red pandas gets value out of this family tree and can see literally how these rare, precious animals, and perhaps humanity as well, are just a large, extended family web, and that each leaf is vital and precious.
Inspired by trips to Japan and the wonderful hospitality and generosity of my fellow Red Panda lovers there, I spent roughly the last month and a half adding Japanese text and search support to Constantina. This involved porting Constantina from legacy Python 2.7 to Python 3, figuring out how Unicode UTF-8 encoding works in browsers, and adding a tokenizer that supports Japanese word boundaries.
In going to Japan, I remembered years ago why I chose the name Codaworry for my domain. It is a Anglicization of the word kotowari (こだわり) which I’m told means someone is “persistent”, “committed”, and “obsessive”. After nearly ten years running, I think that describes my Codaworry projects pretty well.
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.
I always hear about music getting worse and worse. When the world pays only $6/month for recordings, you're not going to get liberal arts schools, expensive tutoring, and lavish technique. I'm deeply inspired by sounds coming from beat-up guitars, buzzy old amplifiers and samplers, and the raw talent of producers, rappers, singers that beautifully and credibly evolve older forms of music, of the improbable magic of artists undeterred by a society that so undervalues them.
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.
Codaworry’s search bar hides a number of secrets. Try searching for songs I’ve written, or for well-known red pandas (レッサーパンダ) in Japanese zoos.
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.