TLS support: pgagroal - PostgreSQL

[jesperpedersen]

Support TLS v1.2 and TLS v1.3.

• Extend the server structure with the required configuration parameters
• Extend the connection structure with the SSL_SESSION data (i2d_SSL_SESSION())

[dpinchukov-ueni]

is there any hope of this getting merged into master?
i am playing around with pgagroal (1.1.0 release), and it looks like while the client->pgagroal connections can use TLS, the pgagroal->postgresql connections cannot.
support for this seems to be implemented in jesperpedersen@62b1424, but that branch is now rather outdated.

[jesperpedersen]

I'm working on something else at the momment, so community effort currently.

[jesperpedersen]

#404 is related

[ashu3103]

@jesperpedersen

Please assign me this issue.

[jesperpedersen]

@ashu3103 Have fun with it !

[ashu3103]

@jesperpedersen

What is the issue with the current implementation, the worker is establishing tls for itself and supplies the ssl context to pipeline for ssl support in further connections.

Just for the part where use_pooled_connection (reusing a prefilled connection) are used there is no ssl.

[jesperpedersen]

@ashu3103 Yeah, we can connect to a TLS protected PostgreSQL instance, but the connections can't be cached since we can't currently serialize the SSLContext to be part of the pool.

You can investigate newer versions of OpenSSL, or look at alternative implmentations like

• https://github.com/eduardsui/tlse
• https://github.com/Mbed-TLS/mbedtls

Create a test setup with self-signed certificates, create a connection, and return it to the pool. You will see it isn't cached.

This ties into requiring TLS certificates for connections - it is the easier part to start with

[ashu3103]

@ashu3103 Yeah, we can connect to a TLS protected PostgreSQL instance, but the connections can't be cached since we can't currently serialize the SSLContext to be part of the pool.

But why are we not able to make SSLContext a part of the pool? Something like config->connections[ssl] = (SSL*)ssl_context

You can investigate newer versions of OpenSSL, or look at alternative implmentations like

• https://github.com/eduardsui/tlse
• https://github.com/Mbed-TLS/mbedtls

Sure, but don't you think openssl has better community support and therefore rapid development

Create a test setup with self-signed certificates, create a connection, and return it to the pool. You will see it isn't cached.

This ties into requiring TLS certificates for connections - it is the easier part to start with

Okay!

[ashu3103]

@ashu3103 Yeah, we can connect to a TLS protected PostgreSQL instance, but the connections can't be cached since we can't currently serialize the SSLContext to be part of the pool.

But why are we not able to make SSLContext a part of the pool? Something like config->connections[ssl] = (SSL*)ssl_context

In _prefill_auth we can do a ssl handshake after _get_connection and save in pool

You can investigate newer versions of OpenSSL, or look at alternative implmentations like

• https://github.com/eduardsui/tlse
• https://github.com/Mbed-TLS/mbedtls

Sure, but don't you think openssl has better community support and therefore rapid development

Create a test setup with self-signed certificates, create a connection, and return it to the pool. You will see it isn't cached.
This ties into requiring TLS certificates for connections - it is the easier part to start with

Okay!

Also in _return_connection is there a specific reason which ssl has to NULL for the connection to be cached

if (config->connections[slot].has_security != SECURITY_INVALID &&
       (config->connections[slot].has_security != SECURITY_SCRAM256 ||
        (config->connections[slot].has_security == SECURITY_SCRAM256 &&
         (config->authquery || pgagroal_user_known(config->connections[slot].username)))) &&
       ssl == NULL)
   {

[jesperpedersen]

We have to reserve the slot in the pool - even for a SSL based connection