Enarx goes multi-platform

Now with added SGX!

Yesterday, Nathaniel McCallum and I presented a session “Confidential Computing and Enarx” at Open Source Summit Europe. As well as some new information on the architectural components for an Enarx deployment, we had a new demo. What’s exciting about this demo was that it shows off attestation and encryption on Intel’s SGX. Our initial work focussed on AMD’s SEV, so this is our first working multi-platform work flow. We’re very excited, and particularly as this week a number of the team will be attending the first face to face meetings of the Confidential Computing Consortium, at which we’ll be submitting Enarx as a project for contribution to the Consortium.

The demo had been the work of several people, but I’d like to call out Lily Sturmann in particular, who got things working late at night her time, with little time to spare.

What’s particularly important about this news is that SGX has a very different approach to providing a TEE compared with the other technology on which Enarx was previously concentrating, SEV. Whereas SEV provides a VM-based model for a TEE, SGX works at the process level. Each approach has different advantages and offers different challenges, and the very different models that they espouse mean that developers wishing to target TEEs have some tricky decisions to make about which to choose: the run-time models are so different that developing for both isn’t really an option. Add to that the significant differences in attestation models, and there’s no easy way to address more than one silicon platform at a time.

Which is where Enarx comes in. Enarx will provide platform independence both for attestation and run-time, on process-based TEEs (like SGX) and VM-based TEEs (like SEV). Our work on SEV and SGX is far from done, but also we plan to support more silicon platforms as they become available. On the attestation side (which we demoed yesterday), we’ll provide software to abstract away the different approaches. On the run-time side, we’ll provide a W3C standardised WebAssembly environment to allow you to choose at deployment time what host you want to execute your application on, rather than having to choose at development time where you’ll be running your code.

This article has sounded a little like a marketing pitch, for which I apologise. As one of the founders of the project, alongside Nathaniel, I’m passionate about Enarx, and would love you, the reader, to become passionate about it, too. Please visit enarx.io for more information – we’d love to tell you more about our passion.

What’s a Trusted Compute Base?

Tamper-evidence, auditability and measurability are three important properties.

A few months ago, in an article called “Turtles – and chains of trust“, I briefly mentioned Trusted Compute Bases, or TCBs, but then didn’t go any deeper.  I had a bit of a search across the articles on this blog, and realised that I’ve never gone into this topic in much detail, which feels like a mistake, so I’m going to do it now.

First of all, let’s think about computer systems.  When I talk about systems, I’m being both quite specific (see Systems security – why it matters) and quite broad (I don’t just mean computer that sits on your desk or in a data centre, but include phones, routers, aircraft navigation devices – pretty much anything that has a set of chips inside it).  There are surely some systems that you don’t rely on too much to do important things, but in most cases, you’re going to care if they go wrong, or, more relevant to this discussion, if they get compromised.  Even the most benign of systems – a smart light-bulb, for instance – can become a nightmare if compromised.  Even if you don’t particularly care whether you can continue to use it in the way it was intended, there are still worries about its misuse in the case of compromise:

  1. it may become a “jumping off point” for malicious attacks into your network or other systems;
  2. it may be used as part of a botnet, piggybacking on your network to attack other systems (leading to sanctions against your legitimate systems from outside);
  3. it may be used as part of a botnet, using up resources such as network bandwidth, storage or electricity (leading to resource constraints or increased charges).

For any systems dealing with sensitive data – anything from your messages to loved ones on your phone through intellectual property secrets for a manufacturing organisation through to National Security data for government department – these issues are compounded.  In order to protect your system, you can’t just say “this system is secure” (lovely as that would be).  What can you do to start making statement about the general security of a system?

The stack

Systems consist of multiple components, and modern computing systems are typically composed from multiple layers (one of my favourite xkcd comics, Stack, shows some of them).  What’s relevant from the point of view of this article is that, on the whole, the different layers of the stack start up – boot up – from the bottom upwards.  This means, following the “bottom turtle” rule (see the Turtles article referenced above), that we need to ensure that the bottom layer is as secure as possible.  In fact, in order to build a system in which we can have assurance that it will behave as expected and designed (in other words, a system in which we can have a trust relationship), we need to build a Trusted Compute Base.  This should have at least the following set of properties: tamper-evidence, auditability and measurability, all of which are related to each other.

Tamper-evidence

We want to know if the TCB – on which we are building everything else – has a problem.  Specifically, we need a set of layers or components that we are pretty sure have not been compromised, or which, if compromised, will be tamper-evident:

  • fail in expected ways,
  • refuse to start, or
  • flag that they have been compromised.

It turns out that this is not easy, and typically becomes more difficult as you move up the stack – partly because you’re adding more layers, and partly because those layers tend to get more complex.

Our TCB should have the properties listed above (around failure, refusing to start or compromise-flagging), and be as small as possible.  This seems the wrong way around: surely you would want to ensure that as much of your system was trusted as possible?  In fact, what you want is a small, easily measurable and easily auditable TCB on which you can build the rest of your system – from which you can build a “chain of trust” to the other parts of your system about which you care.  Auditability and measurability are the other two properties that you want in a TCB, and these two properties are why open source is a very useful tool in your toolkit when building a TCB.

Auditability (and open source)

Auditability means that you – or someone else who you trust to do the job – can look into the various components of the TCB and assure yourself that they have been written, compiled and  are executing properly.  As I explained in Of projects, products and (security) community, the person may not always be you, or even someone in your organisation, but if you’re using widely deployed open source software, the rest of the community can be doing that auditing for you, which is a win for you and – if you contribute your knowledge back into the community – for everybody else as well.

Auditability typically gets harder the further you go down the stack – partly because you’re getting closer and closer to bits – ones and zeros – and to actual electrons, and partly because there is very little truly open source hardware out there at the moment.  However, the more that we can see and audit of the TCB, the more confidence we can have in it as a building block for the rest of our system.

Measurability (and open source)

The other thing you want to be able to do is ensure that your TCB really is your TCB.  Tamper-evidence is related to this, but that’s a run-time property only (for software components, at least).  Being able to measure when you provision your system and then to check that what you originally loaded is still what you think it should be when you boot it is a very important property of a TCB.  If what you’re running is open source, you can check it yourself, against your own measurements and those of the community, and if changes are made – by you or others – those changes can be checked (as part of auditing) and then propagated through measurement checking to the rest of the community.  Equally important – and much more difficult – is run-time measurability.  This turns out to be very difficult to do, although there are some techniques emerging which are beginning to get traction – for now, we tend to rely on tamper-evidence, which is easier in hardware than software.

Summary

Trusted Compute Bases (TCBs) are a key concept in building systems that we hope will behave in ways we expect – or allow us to find out when they are not.  Tamper-evidence, auditability and measurability are three important properties that they should display, and it turns out that open source is an important factor in helping us ensure two of those.

 

 

 

Of projects, products and (security) community

Not all open source is created (and maintained) equal.

Open source is a  good thing.  Open source is a particularly good thing for security.  I’ve written about this before (notably in Disbelieving the many eyes hypothesis and The commonwealth of Open Source), and I’m going to keep writing about it.  In this article, however, I want to talk a little more about a feature of open source which is arguably both a possible disadvantage and a benefit: the difference between a project and a product.  I’ll come down firmly on one side (spoiler alert: for organisations, it’s “product”), but I’d like to start with a little disclaimer.  I am employed by Red Hat, and we are a company which makes money from supporting open source.  I believe this is a good thing, and I approve of the model that we use, but I wanted to flag any potential bias early in the article.

The main reason that open source is good for security is that you can see what’s going on when there’s a problem, and you have a chance to fix it.  Or, more realistically, unless you’re a security professional with particular expertise in the open source project in which the problem arises, somebody else has a chance to fix it. We hope that there are sufficient security folks with the required expertise to fix security problems and vulnerabilities in software projects about which we care.

It’s a little more complex than that, however.  As an organisation, there are two main ways to consume open source:

  • as a project: you take the code, choose which version to use, compile it yourself, test it and then manage it.
  • as a product: a vendor takes the project, choose which version to package, compiles it, tests it, and then sells support for the package, typically including docs, patching and updates.

Now, there’s no denying that consuming a project “raw” gives you more options.  You can track the latest version, compiling and testing as you go, and you can take security patches more quickly than the product version may supply them, selecting those which seem most appropriate for your business and use cases.  On the whole, this seems like a good thing.  There are, however, downsides which are specific to security.  These include:

  1. some security fixes come with an embargo, to which only a small number of organisations (typically the vendors) have access.  Although you may get access to fixes at the same time as the wider ecosystem, you will need to check and test these (unless you blindly apply them – don’t do that), which will already have been performed by the vendors.
  2. the huge temptation to make changes to the code that don’t necessarily – or immediately – make it into the upstream project means that you are likely to be running a fork of the code.  Even if you do manage to get these upstream in time, during the period that you’re running the changes but they’re not upstream, you run a major risk that any security patches will not be immediately applicable to your version (this is, of course, true for non-security patches, but security patches are typically more urgent).  One option, of course, if you believe that your version is likely to consumed by others, is to make an official fork of project, and try to encourage a community to grow around that, but in the end, you will still have to decide whether to support the new version internally or externally.
  3. unless you ensure that all instances of the software are running the same version in your deployment, any back-porting of security fixes to older versions will require you to invest in security expertise equal or close to equal to that of the people who created the fix in the first place.  In this case, you are giving up the “commonwealth” benefit of open source, as you need to pay experts who duplicate the skills of the community.

What you are basically doing, by choosing to deploy a project rather than a product is taking the decision to do internal productisation of the project.  You lose not only the commonwealth benefit of security fixes, but also the significant economies of scale that are intrinsic to the vendor-supported product model.  There may also be economies of scope that you miss: many vendors will have multiple products that they support, and will be able to apply security expertise across those products in ways which may not be possible for an organisation whose core focus is not on product support.

These economies are reflected in another possible benefit to the commonwealth of using a vendor: the very fact that multiple customers are consuming their products mean that they have an incentive and a revenue stream to spend on security fixes and general features.  There are other types of fixes and improvements on which they may apply resources, but the relative scarcity of skilled security experts means that the principle of comparative advantage suggests that they should be in the best position to apply them for the benefit of the wider community[1].

What if a vendor you use to provide a productised version of an open source project goes bust, or decides to drop support for that product?  Well, this is a problem in the world of proprietary software as well, of course.  But in the case of proprietary software, there are three likely outcomes:

  • you now have no access to the software source, and therefore no way to make improvements;
  • you are provided access to the software source, but it is not available to the wider world, and therefore you are on your own;
  • everyone is provided with the software source, but no existing community exists to improve it, and it either dies or takes significant time for a community to build around it.

In the case of open source, however, if the vendor you have chosen goes out of business, there is always the option to use another vendor, encourage a new vendor to take it on, productise it yourself (and supply it to other organisations) or, if the worst comes to the worst, take the internal productisation route while you search for a scalable long-term solution.

In the modern open source world, we (the community) have got quite good at managing these options, as the growth of open source consortia[2] shows.  In a consortium, groups of organisations and individuals cluster around a software project or set of related projects to encourage community growth, alignment around feature and functionality additions, general security work and productisation for use cases which may as yet be ill-defined, all the while trying to exploit the economies of scale and scope outlined above.  An example of this would be the Linux Foundation’s Confidential Computing Consortium, to which the Enarx project aims to be contributed.

Choosing to consume open source software as a product instead of as a project involves some trade-offs, but from a security point of view at least, the economics for organisations are fairly clear: unless you are in position to employ ample security experts yourself, products are most likely to suit your needs.


1 – note: I’m not an economist, but I believe that this holds in this case.  Happy to have comments explaining why I’m wrong (if I am…).

2 – “consortiums” if you really must.

Breaking the security chain(s)

Your environment is n-dimensional – your trust must be, too.

One of the security principles by which we[1] live[2] is that security is only as strong as the weakest link in a chain.  That link is variously identified as:

  • your employees
  • external threat actors
  • all humans
  • lack of training
  • cryptography
  • logging
  • anti-virus
  • auditing capabilities
  • the development lifecycle
  • waterfall methodology
  • passwords
  • any other authentication mechanisms
  • electrical wiring
  • hurricanes
  • earthquakes
  • and pestilence.

Actually, I don’t think I’ve ever seen the last one mentioned, but it’s only a matter of time.  However, very rarely does anybody bother to identify exactly what the chain is that it is being broken by the weakest link splintering into a thousand pieces.

There are a number of candidates that spring to mind:

  1. your application flow.  This is rather an old-fashioned way of thinking of applications: that a program is started, goes through a set of actions, and then terminates, but to think more broadly about it, any action which causes an application to behave in unexpected or unintended ways is a possible security flow, whether that is a monolithic application, a set of microservices or an app on  mobile device.
  2. your software stack.  Depending on how you think about your stack, there are likely to be at least 5, maybe a dozen or maybe even scores of layers in your software stack (for an example with just a few simple layers, see Announcing Enarx).  However you think about it, you need to trust all of those layers to do what who expect them to do.  If one of them is compromised, malicious, or just poorly implemented or maintained, then you have a security issue.
  3. your hardware stack.  There was a time, barely five years ago, when most people (excepting us[1], of course), assumed that hardware did what we thought it was supposed to do, all of the time.  In fact, we should all have known better, given the Clipper Chip and the Pentium bug (to name just to famous examples), but with Spectre, Meltdown and a growing realisation that hardware isn’t as trustworthy as was previously thought, everybody needs to decide exactly what security they can trust in which components.
  4. your operational processes.  You can have the best software and hardware in the world, but if you don’t maintain it and operate it properly, it’s going to be full of holes.  Failing to invest in operations, monitoring, logging, auditing and the rest leaves you wide open.
  5. your supply chain. There’s a growing understanding in the industry that our software and hardware supply chains are possible points of failure[3].  Whether your vendor is entirely proprietary (in which case their security is largely opaque) or open source (in which case you’ve got a chance to be able to see what’s going on), errors or maliciousness in the supply chain can scupper any hopes you had of security for your deployment.
  6. your software and hardware lifecycle.  Developing software?  Patching it?  Upgrading hardware (or software)?  Unit testing?  Unit testingg?  We all know that a failure to manage the lifecycle of our environment can lead to security problems.

The point I’m trying to make above is that there’s no single chain.  Your environment is n-dimensional – your trust must be, too.  If you don’t think about all of these contexts – and there will be more beyond the half-dozen that I’ve just noted – then you can’t have a good chance of managing security in your environment.  I honestly don’t think that there’s any single weakest link in the chain, because there are always already multiple chains in play: our job is to think about as many of them as possible, and then manage an mitigate the risks associated with each.


1 – the mythical “IT security community”.

2 – you’re right: “which we live by” would sound much more natural.

3 – and a growing industry to try to provide fixes.

How not to make a cup of tea

This is an emotive topic.

A few weeks ago, I wrote an article entitled “My 7 rules for remote-work sanity“. This was wildly successful, caused at least one email storm on our company servers, and caused a number of readers to ask me to tackle the question of how to make a cup of tea. Because that isn’t contentious at all.

I’ve resisted that, partly because this is (supposed to be) mainly a security blog, and partly because it would be too easy. Instead, I’ve written this article, which is full of advice and guidance about how not to make a cup of tea or, more accurately, how to make a bad cup of tea. This isn’t hugely related to security either, but as I’ve been writing it, it’s reminded me of how strong the idea of “anti-patterns” is, particularly in security. Sometimes it’s hard to explain to people how they should apply security controls to system, and it’s easier to explain what not to do, so that people can learn from that. This is my (very tenuous) link to security in this article. I hope it (and the rest of the article) serve you well.

I am British, but I travel quite frequently to the United States and to Canada. During my travels, I have been privileged to witness many, many attempts to make tea which have been catastrophic failures. This article is an attempt to celebrate these failures so that people, like me, who have learned over many years how to make tea properly, can celebrate the multitude of incorrect ways in which tea can be ruined.

This is an emotive topic. There are shades of opinion across many issues (upon some of which we will touch during this article), across class lines, geographical lines and even moral lines (I’m thinking here in particular of the question of whether to use cow’s milk – an ethical point for vegans). And, so you understand that I’m not overstating the divides that can occur over this important skill, I’d point out that an entire war was started solely over the belief of a certain group of people who believed that the correct way to make tea was to dump an entire shipment of leaves into a salt-water harbour[1] in a small settlement named after a town in Lincolnshire[2].

Without further ado, let us launch into our set of instructions for how not to make tea (by which I mean “hot black tea” in this context), but with a brief (yet important) digression.

De minimis

There are certain activities associated with the making of tea which I am going to declare “de minimis” – in other words, of minimal importance to the aim of creating a decent cup of tea. These may be areas of conflict within the tea drinking community, but I would argue that the majority of Real Tea Drinkers[tm] would accept that a cup of tea would not be ruined by following any of the options for any of the practices noted below. As this article aims to provide a beginner’s guide to how not to make tea, I contend that your choice of any of the options below will not (at least on its own) cause you to be making not-Tea.

  • Milk, not milk or lemon: I drink my tea with milk. Some drink it without, and some with lemon. Tea can be tea in any of these states.
  • Sugar or not sugar: I used to drink my tea with sugar, but now do not. Tea can be tea with or without sugar.
  • Cup or mug: I prefer a mug for most tea drinking opportunities, but a cup (with saucer) can make a nice change.
  • Bag or loose leaf: we’re getting into contentious territory here. I have recently moved to a strong preference for loose leaf, partly because it tends to be higher quality than bags, but if bags are what you’ve got, then you can make a decent cup of tea with them.
  • In the pot or in the mug: if you’re using loose leaf tea, then it’s in the pot. If it’s in a mug, then it’s a bag. You can, however, make tea in a pot with a bag.
  • Milk first or afterwards: there’s evidence to suggest that putting the milk in first means that it won’t scald, but I’m with George Orwell[3] on this: if you put the tea in first, you can add milk slowly to ensure the perfect strength.
  • Warming the pot: you only need to warm the pot if you’re using bone china. End of.

You might think that I’ve just covered all the important issues of contention above, and that there’s not much point in continuing with this article, but please remember: this article is not aimed at those who wish to make an acceptable cup of tea, but to those who do not wish to make the same. Those who wish to make a cup of non-tea will not be swayed by the points above, and neither should they be. If you belong in this group: whether (for example) a person of North American descent looking to cement your inability to make a cup of tea, or (again, for example) a person of British descent looking for guidance in how to be accepted into North American society by creating a representative cup of non-tea, then, dear reader, please read on.

Instructions

Tea (actual)

The easiest way to fail to make a cup of tea is to choose something which isn’t tea. I’m going to admit to a strong preference to black tea here, and this article is based on how to make a cup of black tea, but I admit to the existence of various other tea types (yellow, white, green, oolong). All of them, however, come from the tea plant, Camellia sinensis. If it doesn’t, then it isn’t tea. Retailers and manufacturers can label it “herbal tea”[4]. Anything which doesn’t come from from the tea plant is an infusion or a tisane.

To be clear, I absolutely include Rooibos or “Red Bush” tea. I tried this once, under the mistaken belief that it was actual tea. The experience did not end well. I’m sure there’s a place for it, but not in my mug (or cup), and it’s not tea. I mean: really.

There are some teas which are made from the tea plant, and have flavourings added. I’m thinking in particular of Earl Grey tea, which has oil of bergamot added to it. I’m not a fan, but that’s partly due to a very bad experience one morning after the imbibing of a significant amount of beverages which definitely weren’t ever pretending to be tea, the results of which also lead to my not drinking gin and tonic anymore[5].

To clarify, then:

  • tea: yes, tea.
  • Earl Grey: yes, tea.
  • rooibos: not tea.
  • fruit tea: not tea.
  • lemon tea: not tea.
  • rhubarb and orange tea: not tea
  • raspberry and old sticks tea: not tea.
  • vanilla tea: not tea.
  • etc., etc.

The very easiest way not to make tea, then, is to choose something which isn’t derived directly from the Camellia sinensis plant. If you’re looking for more adventurous or expert ways not to make tea, however, carry on.

Use non-boiling water

Beyond the obvious “not actually using tea” covered above, the easiest way to fail to make a cup of tea is to use water which is not sufficiently hot. And by “sufficiently hot”, I mean “has just come off the boil”. There’s actual science[6] showing that lots of the important tea-making processes cannot take place at temperatures below 90°C (194°F). To be sure that you’re going to make a cup of bad tea, just be sure not to go with boiling water.

I’ve recently visited a number of establishments in the USA where they offered to make tea with water designed for coffee-making at temperatures of 175°F and 183°F. That’s 79.4°C and 83.9°C. A member of staff at one of these establishments explained that it would be “dangerous” to use water at a higher temperature. I kid you not. They knew that they didn’t need to aim for just off the boil: well under 99°C should do nicely for something almost but not quite like a cup of tea. A warning: many (but not all) outlets of Peet’s Coffee do provide water which is hot enough (often 211-212°F) , if you ask them. You are in significant danger of getting a proper cup of tea if you’re not very careful. This, in my experience, is entirely unique for a coffee chain anywhere in the USA.

Many US hotels will offer to make you a cup of tea in the morning, if you ask nicely enough and sound (passive-aggressively) British enough. You might think that you would be guaranteed a proper cup, but worry not: they will almost certainly use really bad tea, the water will be insufficiently hot and they will definitely not bother to pour it directly over the tea-bag anyway. Hotels are great places to find a really bad cup of tea in the USA.

As a minor corollary of this, another way to fail to make a cup of tea is to boil the water at altitude (e.g. up a mountain) or in an airplane. Because air pressure is reduced in both cases, the boiling point of water is reduced, and so you’re not likely to be able to get the water hot enough, so that’s another great option.

Boil the water incorrectly

What: you didn’t know that you could boil water incorrectly? Oh, but you can. Proper tea is made from water boiled once in a kettle, because if you boil it more than once, something happens: you’ve removed oxygen that was originally dissolved in the water, and this turns out to make it taste bad.

Use the wrong type(s) of milk

The easy way out is to use 2% (semi-skimmed) or 4% (whole fat) cow’s milk, but you don’t want to do that: that’ll give you proper tea. In order not to make tea properly, try UHT milk, almond milk, soy milk or similar. I haven’t tried ewe’s or goat’s milk, but I’m sure it’s easy to mess up a good cup of tea with those.

Condensed milk is an interesting option. I’ve had this in India – where I think they add it instead of sugar – and, well, it didn’t taste like tea to me.

Let it go cold

I’m not even talking about so called “iced tea” here. I’m just talking about tea which has been brewed, then poured, then left to go cold. Yuck.

Brew for too long

Quite apart from the fact that it may go cold, it’s possible to make tea just too strong. There’s a range that most people will accept as proper tea, but you can leave most tea too long, and it will be too strong when you pour it. How long that is will depend partly on preference, and partly on the type of tea you’re using. If you want to ensure you make a bad cup of tea, tune these carefully.

Don’t brew for long enough

Again, it’s easy to get this wrong. Some types of tea brew very quickly, and you’re in danger, for these types, of pouring a decent cup despite your best interests. Use this technique with care, and preferably in conjunction with others of the approaches listed.

Use a little strainer

It is possible to make a decent cuppa with one of those little strainers into which you place your tea leaves, but it’s difficult. The problem seems to be that in order to make a properly strong cup of tea, you’re going to need to put quite a lot of tea leaves into the strainer. This means that the water won’t be able to interact with most of them, as they’ll be stuffed in, and not able to circulate properly. You can try swishing it around a bit, but by the time you’ve got to this, the water will probably be too cold (see above).

Microwave

Microwave your water. This is wrong on so many levels (do a search online).

Use bad tea

Mainly, I think, because most US citizens have no idea how to make a cup of tea properly, they are willing to accept the stuff that passes for “tea bags” in the US as actual tea. There are exceptions, but the standard fare that you’ll find on supermarket shelves isn’t anything like actual tea, so it’s very simple to make a bad cup even if you’ve done everything else right.

My preferred cup of tea

After all of the above, you may be wondering what my preferred cup of tea looks like. Here’s a brief algorithm, which I’m happy to open source:

  1. freshly drawn water in the kettle
  2. kettle boiled
  3. a teaspoon of tea into a small pot (how heaped depends on the type), current favourites include:
  4. pour the boiling water into pot (I tend to use pots with built-in strainers)
  5. allow to brew (how long depends on the type of tea)
  6. pour from the pot into a large mug (not too large, or the tea will get too cold to drink before you get to the bottom)
  7. add semi-skimmed (2%) milk (not UHT)
  8. drink as soon as its cooled enough not to blister the inside of the mouth
  9. leave the bottom few millimetres to avoid ingesting any leaves which may have made their way into the mug.

So there you have it. That’s how I make a cup of tea.


1 – yes, that’s how to spell it.

2 – I’m assuming this was the sole reason. I’m a little hazy on the details, but it all seems to have turned out OK for both sides.

3 – who, given that he wrote both the books Animal Farm and 1984, knew a thing or two about how not to do things.

4 – yes, there’s an “h”, yes it’s aspirated. “‘erbal?” Not unless dropping aitches is part of your general dialect and accent, in which case, fine.

5 – I still drink gin, only not with tonic. It’s the tonic water that I’ve managed to convince my taste buds was the cause of the resulting … problem.

6 – Really, look!

What is DoH, and why should I care?

Firefox is beginning to roll out DoH

DoH is DNS-over-HTTPS.  Let’s break that down.

DNS is Domain Network System, and it’s what allows you to type in the server name (e.g. aliceevebob.com or http://www.redhat.com), which typically makes up the key part of a URL, and then get back the set of numbers which your computer needs actually to contact the machine you want it to talk to.  This is because computers don’t actually use the names, they use the numbers, and the mapping between the two can change, for all sorts of reasons (a server might move to another machine, it might be behind a firewall, it might be behind a load-balancer – those sorts of reasons).   These numbers are called “IP addresses”, and are typically[1] what are called “dotted quads”.  An example would be 127.0.0.1 – in fact, this is a special example, because it maps back to your own machine, so if you ask for “localhost”, then the answer that DNS gives you is “127.0.0.1”.  All IP[1] addresses must be in of the type a.b.c.d, where the a, b, c and d are numbers between 0 and 254 (there are some special rules beyond that, but we won’t go into them here).

Now, your computer doesn’t maintain a list of the millions upon millions of server names and their mappings to specific IP address – that would take too much memory, and ages to download.  Instead, if it needs to find a server (to get email, talk to Facebook, download a webpage, etc.), it will go to a “DNS server”.  Most Internet providers will provide their own DNS servers, and there are a number of special DNS servers to which all others connect from time to time to update their records.  It’s a well-established and generally well-run system across the entire Internet.  Your computer will keep a cache of some of the most recently used mappings, but it’s never going to know all of them across the Internet.

What worries some people about the DNS look-up process, however, is that when you do this look-up, anyone who has access to your network traffic can see where you want to go.  “But isn’t secure browsing supposed to stop that?” you might think.  Well, yes and no.  What secure browsing (websites that start “https://”) means is that nobody with access to your network traffic can see what you download from and transmit to the website itself.  But the initial DNS look-up to find out what server your browser should contact is not encrypted. This might generally  be fine if you’re just checking the BBC news website from the UK, but there are certainly occasions when you don’t want this to be the case.  It turns out although DoH doesn’t completely fix the problem of being able to see where you’re visiting, many organisations (think companies, ISPs, those under the control of countries…) try to block where you can even get to by messing with the responses you get to look-ups.  If your computer can’t even work out where the BBC news server is, then how can it visit it?

DoH – DNS-over-HTTPS – aims to fix this problem.  Rather than your browser asking your computer to do a DNS look-up and give it back the IP address, DoH has the browser itself do the look-up, and do it over a secure connection.  That’s what the HTTPS stands for – “HyperText Transfer Protocol Secure” – it’s what your browser does for all of that other secure traffic (look for the green padlock”).  All someone monitoring your network traffic would see is a connection to a DNS server, but not what you’re asking the DNS server itself.  This is a nice fix, and the system (DoH) is already implemented by the well-known Tor browser.

The reason that I’m writing about it now is that Firefox – a very popular open source browser, used by millions of people across the world – is beginning to roll out DoH by default in a trial of a small percentage of users.  If the trial goes well, it will be available to people worldwide.  This is likely to cause problems in some oppressive regimes, where using this functionality will probably be considered grounds for suspicion on its own, but I generally welcome any move which improves the security of everyday users, and this is definitely an example of one of those.


1 – for IPv4.  I’m not going to start on IPv6: maybe another time.

What is confidential computing?

Industry interest has been high, and overwhelmingly positive.

On Wednesday, 21st August, 2019 (just under a week ago, at time of writing), Jim Zemlin of the Linux Foundation announced the intent to form the Confidential Computing Consortium, with members including Alibaba, Arm, Baidu, Google Cloud, IBM, Intel, Microsoft, Red Hat, Swisscom and Tencent.  I’m particularly proud as Red Hat (my employer) is one of those[1], and I spent the preceding few weeks and days working very hard to ensure that we would be listed as one of the planned founding members.

“Confidential Computing” sounds like a lofty goal, and it is.  We’ve known for ages that you should encrypt sensitive data at rest (in storage), in transit (on the network), but confidential computing, as defined by the consortium, is about doing the same for sensitive data – and algorithms – in use.  The consortium plans to encourage industry to use hardware technologies generally called Trust Execution Environments to allow applications and processes to be encrypted as they are running.

This may sound somewhat familiar to those who follow my blog, and it should: Enarx, an open source project launched by Red Hat, was announced as one of the projects that should be part of the initial launch.  I’ve written about Enarx in several places:

Additionally, you’ll find lots of information on the introduction page of the Enarx wiki.

The press release from the Linux Foundation lists the following goals for the Confidential Computing Consortium (my emboldening):

The Confidential Computing Consortium will bring together hardware vendors, cloud providers, developers, open source experts and academics to accelerate the confidential computing market; influence technical and regulatory standards; and build open source tools that provide the right environment for TEE development. The organization will also anchor industry outreach and education initiatives.

Enarx, of course, fits perfectly into this description, as per the text in bold.  Beyond that, however, is the alignment that there is with the other aims of the Enarx project, and the opportunities with which a wider consortium presents us.  The addition of hardware vendors gives us – and the other participants – opportunities to discuss implementations (hardware and software) in an open environment, cloud providers and other users will give us great use cases, and academic involvement broadens the likelihood of quick access to new ideas and research.

We also expect industry and regulatory standards to be forthcoming, and a need for education as the more sectors and industries engage with confidential computing: the consortium provides a framework to engage in related activities.

It’s early days for the Confidential Computing Consortium, but I’m really hopeful and optimistic.  Already, the openness displayed between the planned members on both technical and non-technical collaboration has gone far beyond what I would have expected.  The industry interest – as evidenced by press and community activities – has been high, and overwhelmingly positive. Fans of Enarx – and confidential computing generally – should be excited by the prospect of greater visibility and collaboration.  After all, isn’t that what open source is about in the first place?


1 – this seems like a good place to point out that the views in this article and blog are my own, and may not represent those of my employer, of the Confidential Computing Consortium, the Linux Foundation or any other body.