Encryption is important component of secure environments. While being intangible property security doesn’t get enough attention when it comes to describing various systems. “Encryption support” is often the most of details what you can get asking how secure the system is. Other important details are often omitted, but the devil in details as we know. In this post I will describe how we secure backup copies in TwinDB.

See the picture. This is what happens when encryption is used incorrectly. The encryption algorithm can be perfect, but poor choice of the mode results in a quite readable encrypted image. This mode is called “Electronic Code Book”, avoid it at all means.

Another bright example of improper encryption use was illustrated in Venona project.

Today, oCERT published advisory 2015-003 describing a TLS vulnerability in MySQL and derivative products.  The content isn’t exactly news – it is documented legacy behavior and the subject of an earlier blog post describing how MySQL Server 5.7 solves the problem.  That said, the efforts of Duo Security are certainly appreciated and welcomed – it provides a meaningful context to discuss how to properly harden existing MySQL 5.5 and 5.6 deployments, as well as frame a discussion on potential changes in these versions to increase security.

Vulnerability

The vulnerability described in the advisory relies on the legacy behavior of the client …

As I wrote earlier, we want the default experience in MySQL 5.7 to be secure by default.  Part of this includes securing connections by automatically creating key material and using TLS for connections where possible.  This may have some significant implications for third-party software – especially products which depend upon capturing, evaluating and/or redirecting client/server traffic at the network level.  This blog post is intended to highlight for developers and users of such products potential issues they may want to consider or address during the pre-GA period for MySQL Server 5.7.

What types of products are dependent upon access to unencrypted protocol data?  Most immediately apparent are proxy-based and network capture-based products.  Proxy-based products typically rely on the same characteristics which can …

MySQL 5.7 aims to be the most secure MySQL Server release ever, and that means some significant changes in SSL/TLS.  This post aims to tie together individual enhancements introduced over the span of several Development Milestone Releases (DMRs) into the larger initiative.  In the simplest terms, we hope to have a minimal TLS configuration enabled by default, and for connections to prefer TLS by default.  Let’s dig into the various aspects of this:

Generation of TLS key material

MySQL Server has long supported TLS connections, yet very few deployments are actually configured to leverage this.  This is partly because creation of key material – the certificates and keys needed to establish TLS connections – is a multi-step, extra, manual process.  Basic TLS concepts have to be understood, third-party software …

August 7, 2014 By Severalnines

Deploying Galera Clusters across WAN environments might lead to concerns around data privacy and security - especially as more organisations are having to comply with national and international regulations. You would not want hackers eavesdropping or intercepting replication traffic. Encrypted replication hides what is sent between the Galera nodes, and makes sure each node is only communicating to the ones it trusts. But how expensive is encryption?

In this blog, we will show you how to encrypt the replication traffic between your Galera nodes. We will also look into the performance impact of this encryption.

Encrypted Replication

Galera supports SSL for the encryption of replication traffic. When encryption is enabled, Galera group communication and Incremental State Transfer (IST) happens over an SSL-encrypted …

I don’t normally quote The Register, but I was clearing tabs and found this article: 350 DBAs stare blankly when reminded super-users can pinch data. It is an interesting read, telling you that there are many Snowden’s in waiting, possibly even in your organisation. 

From a MariaDB standpoint, you probably already read that column level encryption as well as block level encryption for some storage engines are likely to come to MariaBD 10.1 via a solution by Eperi. However with some recent breaking news, Google is also likely to do this – see this thread about  …

We’ve recently received a number of questions on how to implement incremental MySQL backups alongside encryption with Percona XtraBackup. Some users thought it was not initially possible because with the default

--encrypt

options with XtraBackup, all files will be encrypted, but alas, that is not the case. This is where the option

--extra-lsn-dir

becomes useful, because it allows you to save LSN (Log Sequence Number) information to another directory and exclude it from encryption, allowing you to use the same information needed by incremental backups. Enough talk, let me show you.

Because you would want to usually script your backup and restore procedure, I’d use variables here as well to make you more familiar. First, I’d create 3 folders, where my backups will be stored, ‘full’ for full backups, ‘incr’ for …

April 10, 2014 By Severalnines

In the wake of recent concerns and debates raised around the Heartbleed bug, we wanted to update Severalnines ClusterControl users on any impact this bug might have on ClusterControl & associated databases and/or applications.

Background

If your ClusterControl's web application has been accessible on the internet, then most likely you have also been exposed to the Heartbleed OpenSSL security bug, see: http://heartbleed.com for more details. 

By default, our database deployment script enables SSL encryption for the Apache web server on the Controller host with a generated private SSL key and a self-signed certificate. SSL encryption is used between the UI and the Controller REST API if you have clusters added with HTTPS, which we do by default. The content that is …

If you’ve been following this blog (my colleague, David Busby, posted about it yesterday) or any tech news outlet in the past few days, you’ve probably seen some mention of the “Heartbleed” vulnerability in certain versions of the OpenSSL library.

So what is ‘Heartbleed’, really?

In short, Heartbleed is an information-leak issue. An attacker can exploit this bug to retrieve the contents of a server’s memory without any need for local access. According to the researchers that discovered it, this can be done without leaving any trace of compromise on the system. In other words, if you’re vulnerable, they can steal your keys and you won’t even notice that they’ve gone missing. I use the word “keys” literally here; by being able to access the contents of the impacted service’s memory, the attacker is …

Introduction

MySQL Enterprise Backup (MEB) 3.10 introduces support for encrypted backups by allowing backup images, or single-file backups, to be encrypted. However, backups stored in multiple files in a backup directory can not be encrypted.

Any MEB command that produces a backup image can be optionally requested to encrypt it. The encrypted backup image can be stored in a file or tape in the same way as an unencrypted backup image. Similarly, any MEB command that reads data from a backup image accepts also an encrypted backup image. This means that encrypted backups can be used in all the same situations as unencrypted backup images.

MEB encrypts data with Advanced Encryption Standard (AES) algorithm in CBC mode with 256-bit keys. AES is a symmetric block cipher which means that the same key is used both for encryption and decryption. The AES cipher has been adopted by the U.S. government and it is now used worldwide. …