tls-ciphersuites not working on server side

SerGay

Hello.
I want to use TLSv1.3 TLS_AES_128_GCM-SHA256 openvpn tunnel.
I try to set

tls-ciphersuites TLS_AES_128_GCM-SHA256

on server side on Ubuntu 18.04. But nothing change and Control Channel stay:

TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384

When I make same changes in client (Windows) config I have what I want

TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256

But in this case, I will not be able to control clients from the server side if in the future I change my decision.
Is there a way to change the tls-ciphersuites clients from the server side?

TinCanTech

I think you need to specify --tls-version-min 1.3

mio

SerGay wrote Hello.
I want to use TLSv1.3 TLS_AES_128_GCM-SHA256 openvpn tunnel.
I try to set

tls-ciphersuites TLS_AES_128_GCM-SHA256

SerGay

TinCanTech wrote I think you need to specify --tls-version-min 1.3

Nope.
It won't help.
The control channel is already using tls 1.3.

Perhaps I asked the question incorrectly. I'll try to clarify.
I just want to be able to control the TLS 1.3 encryption mode from the server side, as it can be done with TLS 1.2 using the --tls-cipher option.

TinCanTech

Like this:

2020-11-01 17:40:20 us=52256 0.0.0.0:3554 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256, 384 bit EC, curve: secp384r1

TinCanTech

SerGay wrote Is there a way to change the tls-ciphersuites clients from the server side?

Do you mean for the server to control the client TLS cipher/ciphersuite, like auto-negotiate ?

SerGay

TinCanTech wrote Like this:

2020-11-01 17:40:20 us=52256 0.0.0.0:3554 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256, 384 bit EC, curve: secp384r1

Yes. But i use RSA.

TinCanTech wrote Do you mean for the server to control the client TLS cipher/ciphersuite, like auto-negotiate ?

Yep.

When I used openvpn on ubuntu 16.04 and older without built-in support for TLS 1.3 to set the encryption mode to TLS 1.2, I added the line --tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 to the server configuration and it was automatically distributed to the client. Those. the client understood that a similar set of TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 should be used instead of the default TLS-DHE-RSA-WITH-AES-256-GCM-SHA384.

With TLS 1.3 this does not work from the server side and only works from the client side. That is, by specifying --tls-ciphersuites TLS_AES_128_GCM-SHA256 in the server configuration, the selection priority is given to the client, and the mode remains TLS_AES_256_GCM-SHA384.

I do not know how else to explain to make it clear.

TinCanTech

SerGay wrote I do not know how else to explain to make it clear.

Your complete explanation is more clear.

The problem you face is that TLS cipher configuration is complex
and there is only so much that Openvpn (Free Open Source Software) can do ..

You could raise this as a feature request ?

It is most likely that SSL libraries will pickup TLS 1.3 as they become ready ..

Edit: After testing, the problem you face could be that the client side does not support 1.3 .. it works for me.

SerGay

TinCanTech wrote Edit: After testing, the problem you face could be that the client side does not support 1.3 .. it works for me.

Have you read my very first post?
The connection is established with the TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384 and I am trying to do TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256.
How to put it mildly ...
Don't you think that the client still supports TLS 1.3?

And the problem is not in the client.
The server allows the client to connect with a set of ciphers that it (the server) has not explicitly set.

TinCanTech

Like I said: It works for me.

I have not tested with Windows, maybe Windows version does not support this yet ?

300000

Client and server must be the same version and if you specify ciphers it should be the same. But if you can't update client and only from server so it automatically choose the same ciphers on server and client if client is older version there is no way to set ciphers from server

On my android phone i set this one and have ecc Run very like

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256

ecdh-curve secp521r1

SerGay

300000 wrote Client and server must be the same version

They are the same.

I don't change tls-ciphersuites on the client, only on the server.
Therefore, it remains unclear to me why the server allows connecting with a set of ciphers (albeit a stronger one) but not indicated in the list of allowed ones.

If you set up, say, nginx and set it a tls encryption set, then during auto-negotiation with the client, one of the server ciphers (the same as the client one) will be selected, depending on the priority specified on the server. If the client does not support the set of ciphers specified on the server, then the client will simply be refused connection.
OpenVPN gives priority to the client. Those, the client dictates the conditions to the server and, theoretically (and practically), can lower the encryption level by specifying it in its configuration.

port 443
proto tcp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-crypt ta.key 0
topology subnet
server yyy.yyy.yyy.yyy 255.255.255.0
push "route zzz.zzz.zzz.zzz 255.255.255.0"
ifconfig-pool-persist ipp.txt
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
status /dev/null
log-append /dev/null
tcp-nodelay

client
dev tun
windows-driver wintun
proto tcp
sndbuf 0
rcvbuf 0
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth-nocache
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
verb 3

TLS1 TLS_AES_256_GCM-SHA384

port 443
proto tcp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
tls-ciphersuites TLS_AES_128_GCM-SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-crypt ta.key 0
topology subnet
server yyy.yyy.yyy.yyy 255.255.255.0
push "route zzz.zzz.zzz.zzz 255.255.255.0"
ifconfig-pool-persist ipp.txt
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
status /dev/null
log-append /dev/null
tcp-nodelay

client
dev tun
windows-driver wintun
proto tcp
sndbuf 0
rcvbuf 0
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth-nocache
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
verb 3

TLS2 TLS_AES_256_GCM-SHA384

port 443
proto tcp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
tls-crypt ta.key 0
topology subnet
server yyy.yyy.yyy.yyy 255.255.255.0
push "route zzz.zzz.zzz.zzz 255.255.255.0"
ifconfig-pool-persist ipp.txt
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
status /dev/null
log-append /dev/null
tcp-nodelay

client
dev tun
windows-driver wintun
proto tcp
sndbuf 0
rcvbuf 0
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth-nocache
auth SHA256
cipher AES-128-CBC
data-ciphers AES-128-GCM:AES-128-CBC
tls-ciphersuites TLS_AES_128_GCM-SHA256
verb 3

TLS3 TLS_AES_128_GCM-SHA256

TinCanTech

To my knowledge, the SSL library is responsible for behaviour, as described by RFC's.

That being said, this does work for me exactly the way you want it to.

I suspect that the SSL binary shipped with OpenVPN for Windows is slightly older
than those I use for Linux and so the behaviour is slightly different.

If you have enough information you could raise a bug report.

It would also help if you specified which versions of openvpn and openssl you are using.

SerGay

TinCanTech wrote If you have enough information you could raise a bug report.

It would also help if you specified which versions of openvpn and openssl you are using.

https://community.openvpn.net/openvpn/ticket/1118
last post

Server: Ubuntu 18.04.5 LTS, OpenVPN 2.5.0, OpenSSL 1.1.1 11 Sep 2018.
Client: Win10, OpenVPN 2.5.0, OpenSSL 1.1.1h 22 Sep 2020.

SerGay

I'm sorry if I look bothersome.

I just want to control the connection I'm using, not be content with the defaults.
Besides, I am wary of what I don’t understand. If I do not understand Eleptic Curve Cryptography, I will not use ECDHE. And I will continue to use DHE and RSA.
But in this case I want to use TLS 1.3, with the catch that I can control it. And in this case, it does not lend itself to control, and I do not understand why.

300000

i run server on raspberry and client on windows with version 2.49 with some config below

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
ecdh-curve secp521r1

2020-11-05 21:07:57 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 521 bit EC, curve: secp521r1
2020-11-05 21:07:57 [openvpnserver] Peer Connection Initiated with [AF_INET]222.222.222.222:222
2020-11-05 21:07:58 MANAGEMENT: >STATE:1604610478,GET_CONFIG,,,,,,
2020-11-05 21:07:58 SENT CONTROL [openvpnserver]: 'PUSH_REQUEST' (status=1)
2020-11-05 21:07:58 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway local def1 ,ping 190,route-method exe,socket-flags TCP_NODELAY,sndbuf 3932106,rcvbuf 3932106,route-method exe,route 10.10.80.0 255.255.255.0 ,route 192.168.20.0 255.255.255.0,route 192.168.100.0 255.255.255.0,dhcp-option WINS 192.168.20.1,dhcp-option DNS 192.168.20.1 ,dhcp-option DOMAIN

and the log auto choose TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 521 bit EC, curve: secp521r1 on windows so you can set anything you like if you use the same version.

if you like to test i can make the sample test for you and try it on your unbutu server. when run on raspberry that is what i got from log.

TinCanTech

I just tested 2.5 on Windows and it works for me.

2020-11-05 21:50:03 us=447892 OpenVPN 2.5.0 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2020-11-05 21:50:03 us=447892 Windows version 6.1 (Windows 7) 32bit
2020-11-05 21:50:03 us=447892 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
Enter Management Password:
<..snip..>
2020-11-05 21:50:04 us=432350 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_128_GCM_SHA256, 384 bit EC, curve: secp384r1

TinCanTech

For the record, all my server config required to be changed is:

tls-ciphersuites TLS_AES_128_GCM_SHA256

SerGay

TinCanTech wrote For the record, all my server config required to be changed is:

tls-ciphersuites TLS_AES_128_GCM_SHA256

Server only?
Is there no such line in client configurations?

TinCanTech

SerGay wrote Is there no such line in client configurations?

Correct, I did not change anything in the client config.