Merge lp:~jheiss/galera/galera into lp:galera

[Jason Heiss]

I documented the ssl_ca configuration parameter and fixed a few typos I found in the process

[Jason Heiss (jheiss)]

Alright, that's better. Sorry for the confusion.

[Alex Yurchenko (ayurchen)]

Jason, thanks for the patch. However we are not at all convinced that checking remote cert against CA authority is applicable to communication within Galera cluster.

The purpose of such operation in client-server communication is to establish the authenticity of server so that client can trust and accept server's public key.

The way SSL works in Galera cluster, both private and public keys are already present on the node. It does not have to *trust* the remote end. If this node and remote node keys don't match, there simply will be no connection.

In other words, it is sufficient that SSL in Galera cluster is used in "pre-shared key" manner, whereas in web client to web server communication it is used to DISTRIBUTE keys from an unknown source, and so needs CA authority check at that step (key distribution).

review: Disapprove

[Jason Heiss (jheiss)]

Sorry for the slow reply. This is an unusual use of SSL and it took me a while to think it through. I think I understand now that you are expecting users to deploy the cluster with all members sharing the same key and self-signed certificate (specifically self-signed, not just a shared cert issued by a third party).

I do see one potential problem though. The server code set_verify_mode(verify_peer), but it does not include verify_fail_if_no_peer_cert. So a rogue client could connect and present no client certificate and, it seems to me, be allowed to connect.

For the benefit of others, here's my thought process. Let's assume I'm running a cluster. When I add a node to the cluster I want these things to occur:

1: I want the cluster to be able to determine if the new node is authorized to join the cluster
  a: authentication of the new node
  b: authorization that the node is allowed to join
2: I want the new node to be able to determine that it is communicating with genuine members of the cluster
  a: authentication of the cluster members

How does galera achieve those goals?

1a: Whatever key and cert you specify with ssl_key and ssl_cert are used by galera for both client and server operations. So the new node joining the cluster presents that certificate as an SSL client cert to authenticate itself. The cluster members contacted by the new node can authenticate the new node by verifying that the client's certificate was issued by their cert. This works because everyone is sharing the same self-signed certificate. But I believe the problem I mentioned above would allow a rogue client to connect by not presenting a client certificate.

1b: Presuming the above issue is addressed clients must present a certificate, and that certificate must be signed by the certificate the cluster is using (i.e. self-signed). Since the cluster owner controls that certificate there shouldn't be any unauthorized certificates available for clients to present.

2: The client will verify the server's certificate against its certificate. Again presuming you've used a self-signed certificate specific to a single cluster the client can be sure it is communicating with authentic cluster members.

[Alex Yurchenko (ayurchen)]

The possibility of a node connecting without having any certificate is an interesting point and we'll look into it once more for the next release. (however I doubt that it is the case)

Unmerged revisions

169. By Jason Heiss on 2013-11-07

Document ssl_ca and fix a few related typos.

=== modified file 'docs/source/galeraparameters.rst'
--- docs/source/galeraparameters.rst	2013-08-28 15:57:58 +0000
+++ docs/source/galeraparameters.rst	2013-11-07 08:46:23 +0000
@@ -43,6 +43,9 @@
 | :ref:`socket.ssl_key                  |                       | 1.0                   | n/a                | No       |
 | <socket.ssl_key>`                     |                       |                       |                    |          |
 +---------------------------------------+-----------------------+-----------------------+--------------------+----------+
+| :ref:`socket.ssl_ca                   |                       | 1.0                   | n/a                | No       |
+| <socket.ssl_ca>`                      |                       |                       |                    |          |
++---------------------------------------+-----------------------+-----------------------+--------------------+----------+
 | :ref:`socket.ssl_compression          | *yes*                 | 1.0                   | n/a                | No       |
 | <socket.ssl_compression>`             |                       |                       |                    |          |
 +---------------------------------------+-----------------------+-----------------------+--------------------+----------+
@@ -228,7 +231,7 @@
    pair: Parameters; socket.ssl_cert
 
 A path (absolute or relative to the working
-directory )to an SSL certificate (in PEM format). 
+directory) to an SSL certificate (in PEM format). 
 
 .. rubric:: socket.ssl_key
 
@@ -238,9 +241,21 @@
    pair: Parameters; socket.ssl_key
 
 A path (absolute or relative to the working
-directory to a private key for a certificate
+directory) to a private key for a certificate
 (in PEM format).
 
+.. rubric:: socket.ssl_ca
+
+.. _`socket.ssl_ca`:
+
+.. index::
+   pair: Parameters; socket.ssl_ca
+
+A path (absolute or relative to the working
+directory) to the certificate authority (CA) certificate
+(in PEM format).  Used to verify the certificates of peers.
+Defaults to the value of ssl_cert if not specified.
+
 .. rubric:: socket.ssl_compression
 
 .. _`socket.ssl_compression`:

=== modified file 'docs/source/ssl.rst'
--- docs/source/ssl.rst	2013-08-28 15:57:58 +0000
+++ docs/source/ssl.rst	2013-11-07 08:46:23 +0000
@@ -15,6 +15,9 @@
 .. index::
    pair: Parameters; socket.ssl_key
    
+.. index::
+   pair: Parameters; socket.ssl_ca
+   
 *Galera Cluster* supports :abbr:`SSL (Secure Sockets Layer)`
 for the encryption of replication traffic. Authentication
 is not supported. SSL is a cluster-wide option and must be
@@ -38,9 +41,9 @@
 
     socket.ssl_cert = <path_to_cert_file>; socket.ssl_key = <path_to_key_file>
 
-Other SSL configuration parameters include ``socket.ssl_compression`` and
-``socket.ssl_cipher``. See :ref:`Galera Parameters <Galera Parameters>`
-for details.
+Other SSL configuration parameters include ``socket.ssl_ca``,
+``socket.ssl_cipher`` and ``socket.ssl_compression``. See
+:ref:`Galera Parameters <Galera Parameters>` for details.
 
 .. note:: You cannot use a mixed cluster where some nodes have SSL and
           some do not. We recommend configuring SSL when you are setting

=== modified file 'gcomm/src/gcomm/conf.hpp'
--- gcomm/src/gcomm/conf.hpp	2013-11-02 17:37:38 +0000
+++ gcomm/src/gcomm/conf.hpp	2013-11-07 08:46:23 +0000
@@ -65,7 +65,7 @@
 
         /*!
          * @brief File containing CA certificates in PEM format
-         *        ("socket.ssl_verify_file")
+         *        ("socket.ssl_ca")
          */
         static std::string const SocketSslVerifyFile;