Support of SSL protocol

[oleg-jukovec]

The patch adds support for using SSL to encrypt the client-server
communications [1]. It uses a wrapper around the OpenSSL library for
full compatibility with Tarantool Enterprise (GOST cryptographic
algorithms [2] are not supported by Golang's crypto/tls). The feature
can be disabled using a build tag [3] 'go_tarantool_ssl_disable'.

1. https://www.tarantool.io/ru/enterprise_doc/security/#enterprise-iproto-encryption
2. https://github.com/gost-engine/engine
3. https://pkg.go.dev/go/build#hdr-Build_Constraints

Related issues:

#155

We have forked go-openssl library (I hope that temporarily). It will be great if you review my commints there too:
https://github.com/tarantool/go-openssl/tree/v0.0.7-24-g0fadeb4-tarantool

I am not familiar with GitHub's CI/CD. I might have missed something. Please, check CI/CD more carefully if you can.

P.S. I will update a Tarantool Enterprise version in tests from beta after the release (on Tuesday?).

[DifferentialOrange]

To be honest, I'm not familiar with SSL, but since a similar task in assigned to me in tarantool-python, I decided to review that one. Thank you for providing useful links in the description, it helped me to better understand what's going on.

I have left several comments. There are some parts of code I haven't reviewed in-depth yet, but I think I'll give it a shot later.

The main question is compatibility. I've got a bit confused while reviewing the code. What will happen if we connect with SSL-builded connector to older Tarantool? With SSL opts? What do we need ssl_disable dummy functions for: is it only a question of language imports or there is something more?

[oleg-jukovec]

The main question is compatibility. I've got a bit confused while reviewing the code. What will happen if we connect with SSL-builded connector to older Tarantool? With SSL opts?

I don't see any problem.

If Transport = 'ssl' is set It will be the same as with another incorrect configuration (host, port etc). Just do it in a correct way (don't set Transport = 'ssl', set up right ip, port etc) and all be fine.

What do we need ssl_disable dummy functions for: is it only a question of language imports or there is something more?

An user will be able to make build without OpenSSL dependency (maybe he doesn't need it), as it was before. Linking with the OpenSSL library can complicate build.

ligurio removed their request for review

[Totktonada]

A thing of taste: feel free to incorpore or ignore.

PingServer and PingTransport can be extracted from Listen. If we want to leave ability to pass a client completely different host/port/transport, there is the usual term for that: advertize URI/host/port. At least it is used in etcd in the sense 'URI to use for connecting to the instance' as opposed to 'URI to listen on'.

PingSsl: I would named it just Ssl, because it does not clash with anything. Or, say, ClientSsl, because it is client's options in fact.

[oleg-jukovec]

Thank you. It's a good idea to replace Ping because it's a implementation detail. So I've renamed PingServer, PingTransport, PingSsl to ClientServer, ClientTransport, ClientSsl.

It useful to set these values directly in tests (to set the wrong ones, for example, we use SSL for a server, but not for a client).

[Totktonada]

LGTM. I don't see problems in the code and can't add more value here.

Well, there is (a low?) risk of extra dynamic dependency on system's openssl (discussed in Georgy's comment). I'm okay to let Oleg to take the risk.

I would like to know more regarding ability to link openssl statically into resulting executable and leave some instructions for a user. Maybe even a sanity check like 'if static-openssl build flag is enabled, the connector will fail on building at attempt to link it to openssl dynamically'. However I'm okay to work on it later if there will be a demand.

Let's acquire a second approve (I think Georgy can finish its review) and proceed.

[Totktonada]

<..duplicated message, removed..>

[DifferentialOrange]

Well, there is (a low?) risk of extra dynamic dependency on system's openssl (discussed in Georgy's comment). I'm okay to let Oleg to take the risk.

Then maybe we should leave this patch until the next tag, after we tag current stable and compatible things?

[DifferentialOrange]

Should be LGTM after resolving remaining things.

To be honest, I'm also not a fan of adding an SSL dependencies by default, but if discussions result is like this, well, I will not oppose it.

[DifferentialOrange]

If we're missing libssl, libcrypto and never use transport == connTransportSsl, will application with go-tarantool work is it was built with default flags? I'm not well up in linking.

[Totktonada]

The resulting executable will have the dynamic dependency on libssl and libcrypto (shown in ldd or otool -L). The dynamic loader will refuse to load a dynamic executable if any library is missing.

It is safe while given executable is used within a distro of particular version (because distros guarantees ABI compatibility -- where we had openssl 1.1, it will not be updated to openssl 3; at least not from base repositories). So if you build an application for each distro or at least have separate builds for openssl 1.1 and openssl 3 distros, everything should be fine.

If you want to build an executable that would work on, say, Fedora 35 and Fedora 36 both (or Ubuntu Impish and Ubuntu Jammy both), you're in the trouble.

So the question is actually about ways to deliver the resulting application. I can't judge about some 'usual way' here.

[Totktonada]

<...> maybe we should leave this patch until the next tag, after we tag current stable and compatible things?

Okay. It seems, it is time to make a release. @oleg-jukovec, can you, please, release the connector?

[oleg-jukovec]

@oleg-jukovec, can you, please, release the connector?

Sure, it's done.