Month: October 2019

MariaDB & MySQL

MariaDB & MySQL

The transport layer security dance. Like it?

I was pretty disappointed with both these RDBMS, having been catching up on the latest recently. For almost the last fifteen years I’ve been involved with high-transaction rate, low-latency platforms and solutions – almost entirely focusing on MS SQLS, Oracle and PostgreSQL in the relational world. Other non-relational solutions provide in other areas of capability, but MySQL isn’t really capable of the “big stuff” on it’s own (without some serious middleware a.k.a. Google and Wikipedia) but it’s been a favourite of mine in the past where SME-level solutions have needed open-source approaches.

You may remember also that Big Red scooped up Sun in 2009, catching MySQL in the same net – much to the consternation of users of MySQL. Oracle’s reputation isn’t good in the vendor space, nor has it got a great track record on the technical / developer support.

In fact Oracle’s concern at an open-source contender such as MySQL gaining so much traction in Oracle’s own enterprise RDMBS space, it tried pulling the rug from underneath MySQL’s feet a few times – most notably by buying the BerkleyDB engine a few years prior to the Sun acquisition. Shortly after the sale took place MySQL dropped the engine as it was realised it was barely used anyway.

New feature requests and ideas being mulled over on the MySQL dev side would also potentially mean that MySQL could potentially go toe-to-toe with Oracle RDBMS in most scenarios.

Oracle weren’t going to give up so easily and the development community were acutely aware of this.

So much so that Michael Widenius led the “Save MySQL” campaign, petitioning the European Commission to stop the merger. However that effort was largely unsuccessful so they forked MySQL the day the sale was announced, created the MariaDB moniker and wandered out of the Sun enclosure. A number of Sun’s MySQL developers followed him such was the concern at Oracle’s actions.

That tale being told, I’m still bewildered as to why repository builds of both MySQL Community and MariaDB are build with YaSSL – an ageing TLS library from WolfSSL. WolfSSL don’t even link to the product directly on their website anymore, nor include it in their product comparison chart.

OpenSSL, WolfSSL or BoringSSL are just three transport protection protocol libraries available, it seemed counter intuitive to compile with a library that doesn’t even support TLS1.2. From what I can see it doesn’t support EC ciphers at all either. Strange that we as a community would want to continue using it.

But with some digging I found Debian bug 787118 from 2014. Digging further into that it became clear that this was a legal issue:

“OpenSSL cannot be linked to from GPL code without the authors providing an exception to clause 6 of the GPL, since the OpenSSL license imposes restrictions incompatible with the GPL.”

I just learned something new. There’s a bit of back-and-forth on that same Debian bug and an inference that the YaSSL reference will be replaced by CYaSSL. Sounds better?

Nope. The first remark visible on the CYaSSL github repo is to warn people to use WolfSSL instead. In fact it looks like CYaSSL hasn’t been updated since 2015 / 3.3.2 and the patch to it was never implemented.

Default MDB Install SSL status

So no OpenSSL or BoringSSL, and no sign of MariaDB maintainers looking to compile with WolfSSL, instead of obsolete libraries? It’s also an embedded TLS library which supports TLS 1.3 and EC ciphers. I know there’s a lot of talk about how clunky & unwieldy the OpenSSL code base has become, so can see mileage in opting for something more efficient.

Frustratingly, I can see that there has been work to this end on the MariaDB JIRA, which appears linked to 10.4. Looks like the work is done in upstream versions but Debian unstable hasn’t seen a whiff of this yet, with mariadb-10.3 still hogging the limelight. Unfortunately this highlights one of the few disadvantages with widely-used FOSS products, in that time is required to properly evaluate and then commit to replacing something as important as security libraries.

AWS enforces certificate-based authentication which is really useful in this context, and AWS do offer MariaDB RDS instances so I suspect the underlying OS is not Debian Stable. However this shows that it is possible and operational. For now I just I don’t see the value in setting up stunnel to workaround the problem as this essentially means the mechanism used for development won’t replicate the mechanism on prod.

The problem with not developing against a standard security design is that we should never develop anything that is instantly & fundamentally different outside of the dev environment.

I’m not comfortable using non-EC transport-layer security for something as serious as security data & meta-data, especially in data centre scenarios. Think I’ll let MariaDB get this under control before exploring any further, but I fully intend to write both PostgreSQL and MariaDB-compatible data layers for Ringo Dingo eventually.

For now though, I’ll continue to focus the work on PostgreSQL & OpenSSL (for it’s sins).

And so it begins…

And so it begins…

The journey from product roadmap to backlog prioritisation is always challenging…

I’ve already written a good portion of the middle-ware for the product post-pilot, but am now realising it’s a pretty big job for one person. Building servers and selecting appropriate EU IaaS providers, adhering to legislation and keeping technically relevant are only small parts of the roadmap.

In 2016 there was a lot of spam going about. At one point I was getting thousands of emails a week of which approximately half were to addresses I’d used explicitly to send SARs (subject access requests).

It wasn’t just appalling re-use of data, it was wanton flaunting of data protection and privacy laws for profit. Some of the attitudes were Facebook-level appreciate of data protection law – including one response to a standard ASA complaint which the ASA uncomfortable and gave a few of us a laugh:

In response to a complain to the ASA; which related to an advertiser (AdView & Roxburghe) buying lists of names and email addresses from Indian data traders; failing to verify or ask for explicit consent and then using those peoples details to send them spam advertising the Roxy services

Fortunately two things happened:

  1. I had acquired a lot of skills & some significant experience in technical fields over the years
  2. The more spam I received, the more data & meta-data I was accumulating on spammers

After a couple of years of trying direct action in the UK County Courts (with mixed success) I realised I could use the meta-data to build an email security product which I could then distribute on open-source. I started tinkering with Python and my usual email client, Gnome Evolution – as it allows you to easily create mail filters which call a script.

That evolved into a much wider capability that I’ve piloted on my own mailbox for the last two years or so. All seems to work reasonably well and efficiently. However after visiting a few of the stands at the InfoSec Europe 2019 trade show at Olympia, I realised there’s a lot of companies selling the same or similar platforms for a lot of money.

However none of them seemed to interact with spam email the way I was designing my product.

Which brings us to the subject of this blog – an email security product code-named “Ringo Dingo”, after asking for suggestions from everyone at home. Next time perhaps I’ll pick a random word from a dictionary.

So I needed a way of tracking the random thoughts crossing my brain about it, rather than forget something critical or unusual that would be good to add to the overall capability. I started using my usual kanban, Trello, to log ideas and triage the good stuff from the crap, and have progressed all workable options to boards.

The pilot is pretty much done and dusted, so I started redesigning Ringo Dingo as middleware – which would enable the access from any mail client or MTA. What was missing was a book of progress on the overall piece… which is where this blog comes in.

My other blogs focuses on other topics relating to data protection whereas the this record is purely R&D.