The Roundup for December 23-29, 2017 Edition

Bright Fathers by Christopher Parsons

It’s the time of year when people reflect on past annual resolutions while beginning to think about what resolutions they’ll ‘commit’ to in the coming year. I enjoy the idea of establishing annual targets and goals. Not just because it’s fun to imagine how great life would be if you hit them all, but because it provides an ongoing sense of direction in what is often a rote world. More than that, resolutions, goal setting, or whatever else you call it are helpful for providing a lens through which to reflect on a year gone by.

I had one standard resolution, which I absolutely failed to make possible, and a host of them that were far more successful. I fully exited consumer debt hell, increased monthly student loan payments, photographically documented many of the major events in my life, dealt with the last administrative aspects of my last relationship, and mostly righted my financial ship. All of those were major life accomplishments and have done things like change how I visually see the world every day, how I experience my relationships with money, and how I approach my relationships today. It’s not just that I finished something but that in the course of undertaking a series of activities I’ve opened up entirely new (and, arguably, healthier) ways of seeing the world.

But there were other things that I accomplished that I think are as important as those goals that were set last year. I think I’m most proud of the fact that I can see ways in which I’ve grown emotionally. In specific, in my desire to avoid some of the mistakes of my last relationship I’ve had honest and oftentimes painful conversations that were based on what I believe to be right for me; rather than subsuming myself to make life easier I’ve just been me, even when doing so might cause challenges in my relationships. Such challenges, however, are healthy insofar as strong areas of disagreement aren’t indications of a lack of love but, instead, of a healthy set of egos that simply must come to a consensual agreement on how to proceed. Learning how to love in a healthy way has been scary while also amplifying my ability to be present and with others in ways I never understood as possible.

I’ve also managed to overcome some long held fears that were the result of bullying I experienced while growing up. The result is that I can make healthy choices for my body without having a voice in the back of my head that sabotages my efforts to be fitter, eat better, and be happier in my own body. Getting over those particular demons is especially important, in my situation, given that I’m creeping up on the age when coronary diseases start to take the lives of the men in my family.

In the coming days I’ll be thinking through the kinds of resolutions and thematics that I want to carry forward into the coming year. Centrally, I think I’m going to have ‘testable’ objectives, insofar as I’ll be able to actually measure whether or not I’ve advanced in some of the hobbies that I’m involved in, while also trying to find ways of deprioritizing activities that are pleasurable but don’t really do much to advance my physical, intellectual, artistic, professional, or emotional wellbeing.


I spent a significant amount of time thinking about the implications of path dependency in socio-technical systems over the course of my doctoral degree. For my work, I hypothesized that similar kinds of technologies in a path-dependent system would unfold in similar ways cross-jurisdictionally. This common unfolding would take place because once technological development began down a particular path, other paths would be foreclosed and a common end would be reached regardless of regulation, policy, or law.

In the work I did, this dependency wasn’t actually evidenced with much regularity. But some of that was because the technologies I was looking at were heavily socialized: they were used for a range of different tasks and, as such, their development impetuses were often decidedly non-technical. In contrast, the development of Transport Level Security (TLS) has a kind of path dependency that is notably challenging to deviate from, not just because clients and servers must implement new versions of the protocol but because developers of middle boxes simply assume technology will unfold in a given way and have developed their own technologies based on those assumptions. In reaction, the Internet community has spent a considerable amount of time trying to ameliorate the difficulties that arise when implementing new versions of the protocol, difficulties linked to assumptions as to how the protocol would, and will, develop.

Cryptographers are increasingly talking about the problems associated with adopting new versions of TLS as ‘joints’ ‘rusting shut.’ As discussed by Cloudflare, in the context of middleboxes:

Some features of TLS that were changed in TLS 1.3 were merely cosmetic. Things like the ChangeCipherSpec, session_id, and compression fields that were part of the protocol since SSLv3 were removed. These fields turned out to be considered essential features of TLS to some of these middleboxes, and removing them caused connection failures to skyrocket.

If a protocol is in use for a long enough time with a similar enough format, people building tools around that protocol will make assumptions around that format being constant. This is often not an intentional choice by developers, but an unintended consequence of how a protocol is used in practice. Developers of network devices may not understand every protocol used on the internet, so they often test against what they see on the network. If a part of a protocol that is supposed to be flexible never changes in practice, someone will assume it is a constant. This is more likely the more implementations are created.

It would be disingenuous to put all of the blame for this on the specific implementers of these middleboxes. Yes, they created faulty implementations of TLS, but another way to think about it is that the original design of TLS lent itself to this type of failure. Implementers implement to the reality of the protocol, not the intention of the protocol’s designer or the text of the specification. In complex ecosystems with multiple implementers, unused joints rust shut.

To some extent, the lesson to be taken from the efforts to update to TLS 1.3 is to have protocols which are simpler in nature and with fewer moving parts.1 Another lesson is that it takes years to actually shift the global population of Internet devices en masse to more secure ways of communicating. But perhaps the most fundamental lesson — to my mind — is that the security of the Internet is still trying to mediate and resolve problems which were initially seeded many, many years ago and which may mean it takes up to a decade to fix the specific problems to TLS 1.2.

Built infrastructure such as middleboxes isn’t updated on a regular basis because the infrastructure represents a capital cost. And so even as new protocols struggle to come to terms with the past, they do so by comforming to the paths sets down by previously deployed protocols. Even as TLS 1.3 is deployed and made usable, it will be done so based on how earlier versions of the protocol were designed and then implemented. So the questions that linger include: how will implementers of TLS 1.3 make decisions, and how will their decisions direct the development and implementation of future versions of TLS? In effect: how much will the paths of the past continue to affect how future versions of TLS can be practically — as opposed to hypothetically — developed??


Inspirational Quotation

“Generosity is the most natural outward expression of an inner attitude of compassion and loving-kindness.”

– Dalai Lama

Great Photography Shots

I’ve really fallen in love with some of the shots which were submitted to this year’s Sony Wold Photography Awards.

The Horns at sunrise. © Vincent Chen, China, Entry, Open, Landscape & Nature (2018 Open competition), 2018 Sony World Photography Awards.
The Horns at sunrise. © Vincent Chen, China, Entry, Open, Landscape & Nature (2018 Open competition), 2018 Sony World Photography Awards.
Little Indian. © Virgilio Liberato, Philippines, Entry, Open, Portraiture (Open competition), 2018 Sony World Photography Awards
Little Indian. © Virgilio Liberato, Philippines, Entry, Open, Portraiture (Open competition), 2018 Sony World Photography Awards.
Lunch Break. © Omer Faidi, Turkey, Entry, Open, Street Photography (Open competition), 2018 Sony World Photography Awards.
Lunch Break. © Omer Faidi, Turkey, Entry, Open, Street Photography (Open competition), 2018 Sony World Photography Awards.

Intriguing Video Art

Music I’m Digging

Neat Podcast Episodes

Good Reads for the Week

Cool Product Advice

  1. Per Cloudflare: David Benjamin proposed a way to keep the most important joints in TLS oiled. His GREASE proposal for TLS is designed to throw in random values where a protocol should be tolerant of new values. If popular implementations intersperse unknown ciphers, extensions and versions in real-world deployments, then implementers will be forced to handle them correctly. GREASE is like WD-40 for the Internet.
Link

Netflix Adopts Efficient HTTPS Encryption For Its Video Streams

Netflix Adopts Efficient HTTPS Encryption For Its Video Streams:

Netflix has been reluctant to adopt HTTPS for its video streams so far because delivering video is already a bandwidth-heavy task, and adding encryption on top of that risked adding too much overhead. To solve this problem, the company searched for the ideal cipher and its fastest implementation.

Encrypting everything matters because third-parties can use our unique ‘tells’, be they video watching, online reading, music listening, website browsing, or other human behaviours to track us across the Internet. Some of these trackers are other companies, some of them are governments, and some are just questionable groups of hackers.

Netflix’s adoption of HTTPS for their entire service line is a good thing but, now, it’ll be important to actually test the implementations of HTTPS. Unfortunately, most implementations suffer some kind of deficiency and it’s more likely than not that Netflix’s initial deployment will be similarly flawed.

Link

FFS SSL

FFS SSL:

I just set up SSLTLS on my web site. Everything can be had via https://wingolog.org/, and things appear to work. However the process of transitioning even a simple web site to SSL is so clownshoes bad that it’s amazing anyone ever does it. So here’s an incomplete list of things that can go wrong when you set up TLS on a web site.

Now you start to add secure features to your web app, safe with the idea you have SSL. But better not forget to mark your cookies as secure, otherwise they could be leaked in the clear, and better not forget that your website might also be served over HTTP. And better check up on when your cert expires, and better have a plan for embedded browsers that don’t have useful feedback to the user about certificate status, and what about your CA’s audit trail, and better stay on top of the new developments in security! Did you read it? Did you read it? Did you read it?

It’s a wonder anything works. Indeed I wonder if anything does.

Without any doubt this is one of the better(?) rants about SSL/TLS that I’ve read recently. And given my own recent experiences in setting up SSL/TLS on another site I entirely empathize: it was a horrible experience that involved tracking down what was causing things to break, when they were breaking, and how to remedy them. It was a non-trivial learning experience and that was a very simple site. Large sites….well, I shudder to consider the work entailed in securing them.

(As a sidenote: yes, SSL/TLS is broken. But it adds friction to mass surveillance processes and at little cost to the visitor of websites/users of web services. It’s a pain for those delivering content, but that’s a pain that it’s arguably appropriate for those content providers to bear.)

Testing for “reverse” Heartbleed

Testing for “reverse” Heartbleed:

Importantly, even if the server that you are querying (e.g. Tumblr.com) is patched against this OpenSSL vulnerability the servers behind the front-end of the server may not be. As a result, payment gateways, agents responsible for fetching URLs, some identity federation protocols, and so forth may also be vulnerable. In Meldium’s tests, who have they announced was vulnerable?

  • An unnamed top 5 social network (we’re waiting for confirmation of their fix) that fetched our URL to generate a preview. The memory we extracted from their agent included results from internal API calls and snippets of python source code.
  • Reddit, which can use a URL to suggest a name for a new post, used a vulnerable agent that they’ve now patched. The memory we were able to extract from this agent was less sensitive, but we didn’t get as many samples because they patched so quickly (nice work!).
  • We registered a webhook to our malicious URL at rubygems.org to notify us whenever a gem was published. Within a few minutes, we captured chunks of S3 API calls that the Rubygems servers were making. After the disclosure, they quickly updated OpenSSL and are now protected (really nice work, especially from an all-volunteer staff!).

This is just a very, very small snippet of vulnerable parties. And given how many backend systems will simply not be updated for fear of breaking compatibility (e.g. in the case of payment gateways) this will be a long-term vulnerability.

SSL: the solution to a problem that is persistently generating problems unsolvable by SSL itself.

Aside

How Heartbleed transformed HTTPS security into the stuff of absurdist theater

I think the link between absurdist theatre and SSL certificate revocation checking is a (bit) tenuous, but nevertheless Dan Goodin’s article over at Ars Technica does a good job in describing (in less technical language than Adam Langley’s post) why having your browser check for revoked SSL certificates really isn’t all that effective.

Link

Heartbleed bug found in key encryption technology risks exposing private data

This was an absolute gift to intelligence agencies all over the world. And one that was – and is – being widely exploited in the wild by criminals and other unauthorized third-parties.

Source: Heartbleed bug found in key encryption technology risks exposing private data

Image

staff:

You can now take extra precaution against hackers and snoops by enabling SSL security on your Tumblr Dashboard. Just head over to your Account Settings and flip the switch.

“Any reason I shouldn’t do this?” Nope, not really. It doesn’t change anything about the dashboard, it just encrypts your connection to it. We’ve been using it for weeks and haven’t even noticed. So, yeah, turn it on and forget about it. Easy.

That this isn’t enabled by default shows that Tumblr is interested in the PR of offering security rather than giving enough of a damn to automatically enable SSL across the entire user-space.