[Openvpn-users] Correct use of ncp-ciphers/ncp-disable for the data channel cipher

[s***@keemail.me]

I read about the new options --ncp-ciphers and --ncp-disable, which allow a negotiable cipher for the data channel encryption.

It's not clear to me how it's used.

When I specify `---ncp-ciphers AES-256-GCM:AES-128-GCM`, then the cipher will be one of th mentioned two, right?
What happens to the `--cipher` option? Do I still configure that option and it defines the preferred cipher?

In general, how do the options --ncp-ciphers, --ncp-disable and --cipher cooperate?

Kind regards,
SaAtomic

[David Sommerseth]

Post by s***@keemail.me
I read about the new options --ncp-ciphers and --ncp-disable, which
allow a negotiable cipher for the data channel encryption.
It's not clear to me how it's used.
When I specify `---ncp-ciphers AES-256-GCM:AES-128-GCM`, then the cipher
will be one of th mentioned two, right?
What happens to the `--cipher` option? Do I still configure that option
and it defines the preferred cipher?
In general, how do the options --ncp-ciphers, --ncp-disable and --cipher cooperate?

Lets start from the server side, to make it simpler in the beginning.

--cipher on the server defines the "default" cipher it expects clients
to use, which is very important for clients which does not support NCP
(basically all clients older than v2.4.0).

--ncp-ciphers defines the ciphers the server may allow clients to use.
This also makes it possible for clients older than v2.4.0 to use a
different cipher than the default --cipher. So if your server use
--cipher BF-CBC (which is the default if --cipher is not provided) and
add --ncp-ciphers AES-256-GCM:AES-256-CBC ... the server will allow all
clients to use --cipher BF-CBC, AES-256-CBC or AES-256-GCM. This makes
it possible to gradually update client configs one-by-one without
breaking any ones configuration. So in practice, all clients which is
v2.3 and older can use --cipher BF-CBC, AES-256-CBC while v2.4 clients
and newer can use the same ones plus in addition also AES-256-GCM.

The --ncp-disable actually disables this flexibility. If the server
uses --ncp-disable, it falls back to the pre v2.4 behaviour, where
clients and server muse use the same --cipher.


So to the client side. For NCP options to be really useful on the
client side, the server must *not* use --ncp-disable.

A v2.4 (and newer) client which uses --ncp-disable will behave identical
to any older clients. It is only the --cipher which defines which
algorithm will be used. If the server allows that cipher, depends on if
it matches the --ncp-cipher list or not.

A v2.4 (and newer) client which adds --ncp-ciphers can steer which
ciphers a NCP capable server will use. So if the server uses
--ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC and you
want your client to only use 128 bits ciphers, you add to the client
configuration --ncp-ciphers AES-128-GCM:AES-128-CBC. With this
configuration, even if the server have --cipher BF-CBC as the default,
the client ciphers will be upgraded to AES-128-GCM or AES-128-CBC
(depending on the strongest cipher which the SSL libraries support).

But NCP will only work if a typical client/server configuration. This
does not work on peer-to-peer mode configurations. So the server side
must have --mode server (or just --server) in the config and the client
must have use --client (or --tls-client + --pull).

In addition, which cipher which will effectively be used also depends on
which ciphers the SSL libraries OpenVPN is built against supports.


I hope this clarified more than adding more confusion :)

[Gert Doering]

Hi,

Post by David Sommerseth
A v2.4 (and newer) client which adds --ncp-ciphers can steer which
ciphers a NCP capable server will use. So if the server uses
--ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC and you
want your client to only use 128 bits ciphers, you add to the client
configuration --ncp-ciphers AES-128-GCM:AES-128-CBC. With this
configuration, even if the server have --cipher BF-CBC as the default,
the client ciphers will be upgraded to AES-128-GCM or AES-128-CBC
(depending on the strongest cipher which the SSL libraries support).

Close. There is no signalling client->server about the list of
supported ciphers yet, only "I can do NCP!" - in this case the server
will pick the first cipher from *the server side* --ncp-ciphers list.

"I can do NCP!" (IV_NCP=1) is defined as "the client can do server-pushed
ciphers, AND supports AES-256-GCM".

[..]

Post by David Sommerseth
In addition, which cipher which will effectively be used also depends on
which ciphers the SSL libraries OpenVPN is built against supports.

Sort of. If the SSL libraries do not support AES, NCP will be disabled.

Otherwise, there is no automatism "SSL library does not have <x>, so fall
back to <x>" - it will just fail.


(... and I bet there's yet another detail I didn't get right either)

gert

[David Sommerseth]

Post by Gert Doering
Hi,

Post by David Sommerseth
A v2.4 (and newer) client which adds --ncp-ciphers can steer which
ciphers a NCP capable server will use. So if the server uses
--ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC and you
want your client to only use 128 bits ciphers, you add to the client
configuration --ncp-ciphers AES-128-GCM:AES-128-CBC. With this
configuration, even if the server have --cipher BF-CBC as the default,
the client ciphers will be upgraded to AES-128-GCM or AES-128-CBC
(depending on the strongest cipher which the SSL libraries support).

Close. There is no signalling client->server about the list of
supported ciphers yet, only "I can do NCP!" - in this case the server
will pick the first cipher from *the server side* --ncp-ciphers list.
"I can do NCP!" (IV_NCP=1) is defined as "the client can do server-pushed
ciphers, AND supports AES-256-GCM".

Ahh! Thanks! I was not aware that AES-GCM is required for NCP

Post by Gert Doering
[..]

Post by David Sommerseth
In addition, which cipher which will effectively be used also depends on
which ciphers the SSL libraries OpenVPN is built against supports.

Sort of. If the SSL libraries do not support AES, NCP will be disabled.

Do you mean AES-GCM, or AES in general? AES-GCM is the AEAD cipher
stuff which is quite different from plain AES. And AES is even
supported in OpenSSL v0.9.8.

Post by Gert Doering
Otherwise, there is no automatism "SSL library does not have <x>, so fall
back to <x>" - it will just fail.

Right!

Post by Gert Doering
(... and I bet there's yet another detail I didn't get right either)

Steffan, come save us! :)

[Steffan Karger]

Hi,

Post by David Sommerseth

Post by Gert Doering

Post by David Sommerseth
A v2.4 (and newer) client which adds --ncp-ciphers can steer which
ciphers a NCP capable server will use. So if the server uses
--ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC and you
want your client to only use 128 bits ciphers, you add to the client
configuration --ncp-ciphers AES-128-GCM:AES-128-CBC. With this
configuration, even if the server have --cipher BF-CBC as the default,
the client ciphers will be upgraded to AES-128-GCM or AES-128-CBC
(depending on the strongest cipher which the SSL libraries support).

Close. There is no signalling client->server about the list of
supported ciphers yet, only "I can do NCP!" - in this case the server
will pick the first cipher from *the server side* --ncp-ciphers list.
"I can do NCP!" (IV_NCP=1) is defined as "the client can do server-pushed
ciphers, AND supports AES-256-GCM".

Ahh! Thanks! I was not aware that AES-GCM is required for NCP

Post by Gert Doering
[..]

Post by David Sommerseth
In addition, which cipher which will effectively be used also depends on
which ciphers the SSL libraries OpenVPN is built against supports.

Sort of. If the SSL libraries do not support AES, NCP will be disabled.

Do you mean AES-GCM, or AES in general? AES-GCM is the AEAD cipher
stuff which is quite different from plain AES. And AES is even
supported in OpenSSL v0.9.8.

The statement is true for both AES and AES-GCM, but NCP indeed
specifically requires AES-GCM.

Post by David Sommerseth

Post by Gert Doering
Otherwise, there is no automatism "SSL library does not have <x>, so fall
back to <x>" - it will just fail.

Right!

Post by Gert Doering
(... and I bet there's yet another detail I didn't get right either)

Steffan, come save us! :)

You covered this quite well.

One corner case to note is perhaps that pre-2.4 clients (or 2.4 clients
with --ncp-disable) built with --enable-small (typically done on
resource-constraint devices like home routers), do not tell the server
which cipher they are using. This means that a 2.4 server with NCP
enabled can not switch to the correct cipher, and thus that --cipher on
both server and client must match for the connection to work. I'm
working on a workaround for this.

-Steffan