error when using openvpn with OQS signature

[k-Artin]

hello i am getting the following error when using openvpn with OQS signature:

2023-02-27 13:18:36 us=339169 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit unknown type, signature: p521_falcon1024 2023-02-27 13:18:36 us=362887 [test server] Peer Connection Initiated with [AF_INET]myip:2234 2023-02-27 13:18:36 us=365937 OpenSSL: error:04000065:object identifier routines::unknown nid 2023-02-27 13:18:36 us=368782 TLS_ERROR: BIO read tls_read_plaintext error 2023-02-27 13:18:36 us=371915 TLS Error: TLS object -> incoming plaintext read error 2023-02-27 13:18:36 us=374594 TLS Error: TLS handshake failed 2023-02-27 13:18:36 us=377651 Fatal TLS error (check_tls_errors_co), restarting 2023-02-27 13:18:36 us=380265 TCP/UDP: Closing socket

the signature algorithm is p521_falcon1024 and the key of CA certificate، server key and server certificate is p521_falcon1024. I can communicate between the openssl s_server and openssl s_client with this certificates and keys. the openssl and openvpn version is : openssl 3.2.0-dev OpenVPN 2.7_git

and the OS is windows 10.

i think something wrong. Thank you in advance!

[baentsch]

Thanks for this report. Is the problem only with falcon? In other words, can you successfully use other signature algorithms, e.g., p521_dilithium5? Or is it only the p521_falcon1024 hybrid and plain falcon1024 works? Final question: Have you built this yourself (using oqs-provider current main branch)?

[k-Artin]

Have you built this yourself (using oqs-provider current main branch)?

yes i use main branch of oqs-provider and the latest version of openssl master that you are changing it.

[baentsch]

OK -- the latest code, then, good. But does the problem only occur with Falcon? Anyway, can you please share here a setup and/or script that lets me reproduce the issue/leads to the above error messages?

[k-Artin]

I test with falcon1024 and dilithium2, and again this error occurred.
I am trying to create openVPN Tunnel between client and server that have been implemented on two separate VMs. They use kyber512 as KEM and falcon1024 as signature, and OS is debian.

[baentsch]

Thanks for this additional information. I still don't know how to reproduce the issue. Can you run your test alternatively using https://hub.docker.com/r/openquantumsafe/openvpn which is tested to work OK (for some use cases)?

[baentsch]

When using the docker image above, there's a simple test with which you can validate (or not) that PQ-TLS1.3 signatures are working: Simply run docker run -it openquantumsafe/openvpn bash -c "openssl s_client -connect test.openquantumsafe.org:6180" and you will see that a correct "dilithium2-p384_kyber768" connection can be established. This fails when using the same command using the docker image tagged "0.7.2" as there, the provider-based signature support was not available in OpenSSL:

$ docker run -it openquantumsafe/openvpn:0.7.2 bash -c "openssl s_client -connect test.openquantumsafe.org:6180"
Connecting to 149.81.106.123
CONNECTED(00000003)
8082360EFF7E0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:1459:SSL alert number 40

So, in your local Windows build, be sure to check the output of the openssl s_client command above using the openssl binary you built as part of the OpenVPN build: If this works, but OpenVPN doesn't, please let me know. If this doesn't work, your windows build has gone wrong.

[k-Artin]

i use the command below: openssl.exe s_client -connect test.openquantumsafe.org:6180 -CAfile ca.crt -groups p384_kyber768 and this command is working and Everything was fine and connection was established..

Connecting to 149.81.106.123 CONNECTED(000001F0) depth=1 CN=oqstest_CA verify return:1 depth=0 CN=test.openquantumsafe.org verify return:1

Certificate chain 0 s:CN=test.openquantumsafe.org i:CN=oqstest_CA a:PKEY: , 128 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 11 12:14:27 2022 GMT; NotAfter: Aug 11 12:14:27 2023 GMT

[baentsch]

@k-Artin sorry for seeing your response only now. So the openssl build seems OK and even the dilithium2 verification is OK, right? Just to be sure, can you confirm connecting to a falcon port, say 6594, using openssl also works?! In that case we definitely have an OpenVPN-only issue -- which would be weird because there is no oqs-specific code in it...

Can you please share all steps you did do generate the error trace at the start so I can reproduce? For example, are you 100% certain that you have a correct openssl.cnf file, for example? Please share its contents here: I currently have the assumption that this script has not been correctly executed on your side:

sed -i "s/default = default_sect/default = default_sect\noqsprovider = oqsprovider_sect/g" /opt/oqssa/ssl/openssl.cnf && sed -i "s/\[default_sect\]/\[default_sect\]\nactivate = 1\n\[oqsprovider_sect\]\nactivate = 1\n/g" /opt/oqssa/ssl/openssl.cnf && sed -i "s/providers = provider_sect/providers = provider_sect\nssl_conf = ssl_sect\n\n\[ssl_sect\]\nsystem_default = system_default_sect\n\n\[system_default_sect\]\nGroups = ${KEM_ALGLIST}\n/g" /opt/oqssa/ssl/openssl.cnf

The result would be that openvpn does not activate the oqsprovider at all. A correct openssl.cnf must contain the lines

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

and

[oqsprovider_sect]
activate = 1

[k-Artin]

Just to be sure, can you confirm connecting to a falcon port, say 6594, using openssl also works?!

yes with falcon also work:

Connecting to 149.81.106.123 CONNECTED(000001E8) depth=1 CN=oqstest_CA verify return:1 depth=0 CN=test.openquantumsafe.org verify return:1

Certificate chain 0 s:CN=test.openquantumsafe.org i:CN=oqstest_CA a:PKEY: , 128 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 11 12:14:27 2022 GMT; NotAfter: Aug 11 12:14:27 2023 GMT

For example, are you 100% certain that you have a correct openssl.cnf file, for example?

for ubuntu i using your dockerfile with few changes (like removing the command CMD ["serverstart.sh"]) and i still got the error above (OpenSSL: error:04000065:object identifier routines::unknown nid). If we do not enter the commands you said in openssl.cnf, we will get a different error in openssl s_client:

Call to SSL_CONF_cmd(-groups, p384_kyber768) failed 78290000:error:0A080106:SSL routines:gid_cb:passed invalid argument:ssl/t1_lib.c:1040:group 'p384_kyber768' cannot be set.

[baentsch]

Thanks for these confirmations. Indeed, you're right: If openssl.cnf were wrong, the PQ KEM group could not be set.

Then I'm at a loss, frankly: You are basically saying that the result of the oqs-openvpn Docker(file) build works OK (in the Linux docker image), but the very same commands (to generate certs and set up the openvpn connection) do not work OK under Windows, is that correct?

Again, the best I can offer is an effort to reproduce your setup -- but for that I'd need a complete description (incl. the scripts you use) how everything was built under Windows. I'd then fire up a Windows VM somewhere to see what you see (and debug into it).

[k-Artin]

Then I'm at a loss, frankly: You are basically saying that the result of the oqs-openvpn Docker(file) build works OK (in the Linux docker image), but the very same commands (to generate certs and set up the openvpn connection) do not work OK under Windows, is that correct?

i got the same error in both ubuntu and windows (OpenSSL: error:04000065:object identifier routines::unknown nid). this error in both ubuntu and windows (only in openvpn) happen when i using the OQS signature. The openvpn connection is established correctly when i am using the kem groups and classic signatures. (in both windows and ubuntu). i think somting wrong in using nid in openssl for providers.

[baentsch]

That's "great" (so it's reproducible). So please let me have the exact commands you execute with(in) the openquantumsafe/openvpn docker image to get to see the above error messages.

[k-Artin]

we can not use openquantumsafe/openvpn because it is using classic signature (rsa).i want using OQS signature. i suggest using dockerfile in the ubuntu without:

COPY serverstart.sh ${INSTALLDIR}/bin COPY clientstart.sh ${INSTALLDIR}/bin

WORKDIR ${INSTALLDIR}

CMD ["serverstart.sh"] STOPSIGNAL SIGTERM

[baentsch]

All right -- you can get this effect by simply executing docker run -it openquantumsafe/openvpn bash: You will wind up in a shell where "serverstart.sh" has not been executed. Which commands are you then executing to arrive at the error state?

[k-Artin]

sorry i am using the dockerfile in the https://github.com/open-quantum-safe/oqs-demos/blob/main/openvpn/Dockerfile without:

COPY serverstart.sh ${INSTALLDIR}/bin COPY clientstart.sh ${INSTALLDIR}/bin

WORKDIR ${INSTALLDIR}

CMD ["serverstart.sh"] STOPSIGNAL SIGTERM

after that i am using the command bellow to generate ca,server and client certificate:

openssl genpkey -algorithm falcon512 -out server_key.key openssl genpkey -algorithm falcon512 -out client_key.key openssl genpkey -algorithm falcon512 -out ca_key.key openssl req -key ca_key.key -x509 -out ca_cert.crt openssl req -new -key client_key.key -out client_cert.csr openssl req -new -key server_key.key -out server_cert.csr openssl x509 -req -in server_cert.csr -CA ca_cert.crt -CAkey ca_key.key -CAcreateserial -out server_cert.crt openssl x509 -req -in client_cert.csr -CA ca_cert.crt -CAkey ca_key.key -out client_cert.crt

after that i am using the config file for server and client:

server config for openvpn:

mode server proto tcp-server dev tun topology subnet

server 10.0.5.0 255.255.255.0 port 2235

user nobody group nogroup persist-key persist-tun keepalive 10 120 dh none

tls-server tls-version-min 1.3 tls-version-max 1.3 providers oqsprovider default ca ca_cert.crt cert server_cert.crt key server_key.key

tls-groups kyber512 tls-ciphersuites TLS_AES_256_GCM_SHA384

cipher AES-256-GCM verb 5

push "redirect-gateway def1 bypass-dns" push "dhcp-option DNS 10.0.5.1" push "dhcp-option DNS 8.8.8.8"

client config for openvpn:

client

proto tcp-client dev tun pull remote 172.17.0.3 port 2235

user nobody group nogroup persist-key persist-tun

tls-client tls-version-min 1.3 tls-version-max 1.3 providers oqsprovider default ca ca_cert.crt cert client_cert.crt key client_key.key

tls-groups kyber512 tls-ciphersuites TLS_AES_256_GCM_SHA384

cipher AES-256-GCM verb 5

After establishing the tunnel i got the error bellow:

2023-03-06 11:28:03 us=995096 OpenVPN 2.7_git [git:master/c333a0c05f9d454e+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Mar 6 2023 2023-03-06 11:28:03 us=995444 library versions: OpenSSL 3.2.0-dev , LZO 2.10 2023-03-06 11:28:03 us=995552 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. 2023-03-06 11:28:04 us=4979 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ] 2023-03-06 11:28:04 us=5090 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ] 2023-03-06 11:28:04 us=5650 TCP/UDP: Preserving recently used remote address: [AF_INET]172.17.0.3:2235 2023-03-06 11:28:04 us=5709 Socket Buffers: R=[131072->131072] S=[16384->16384] 2023-03-06 11:28:04 us=5729 Attempting to establish TCP connection with [AF_INET]172.17.0.3:2235 2023-03-06 11:28:04 us=6969 TCP connection established with [AF_INET]172.17.0.3:2235 2023-03-06 11:28:04 us=7005 TCPv4_CLIENT link local: (not bound) 2023-03-06 11:28:04 us=7037 TCPv4_CLIENT link remote: [AF_INET]172.17.0.3:2235 2023-03-06 11:28:04 us=7158 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay WR2023-03-06 11:28:04 us=7938 TLS: Initial packet from [AF_INET]172.17.0.3:2235, sid=a7d05bec 18e8aa5b WRWRWRWRWR2023-03-06 11:28:04 us=12337 VERIFY OK: depth=1, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd 2023-03-06 11:28:04 us=12547 VERIFY ERROR: could not extract CN from X509 subject string ('C=AU, ST=Some-State, O=Internet Widgits Pty Ltd') -- note that the field length is limited to 64 characters 2023-03-06 11:28:04 us=12606 OpenSSL: error:0A000086:SSL routines::certificate verify failed 2023-03-06 11:28:04 us=12815 TLS_ERROR: BIO read tls_read_plaintext error 2023-03-06 11:28:04 us=12839 TLS Error: TLS object -> incoming plaintext read error 2023-03-06 11:28:04 us=12853 TLS Error: TLS handshake failed 2023-03-06 11:28:04 us=13052 Fatal TLS error (check_tls_errors_co), restarting 2023-03-06 11:28:04 us=13127 TCP/UDP: Closing socket

[baentsch]

Hmm -- looking at the error messages, I wonder what this is supposed to mean:

WARNING: No server certificate verification method has been enabled.

-> Where does this config have to be set? Am I starting things correctly by simply executing openvpn --config server.conf and openvpn --config client.conf (with these files containing the entries you provided above)?

Then, have you seen this error message:

VERIFY ERROR: could not extract CN from X509 subject string ('C=AU, ST=Some-State, O=Internet Widgits Pty Ltd')

Where is this CN coming from? What data did you enter when creating the certificates? No CN?

[k-Artin]

-> Where does this config have to be set? Am I starting things correctly by simply executing openvpn --config server.conf and openvpn --config client.conf (with these files containing the entries you provided above)?

this command is correct and you just changing the ip address in remote and Enter the address of the place where the certificates and keys was made (ca , cert and key).

Where is this CN coming from? What data did you enter when creating the certificates? No CN?

I have not entered any CN , ST and etc in the certificate.

[baentsch]

Looking at this anew in the morning, there's a clear error in the above: The certificates do not conform to ´openvpn´ requirements as stated in the error message:

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

--> The openssl commands above do not add the required extended cert usage fields. Accordingly, the server cannot work. Also, I just verified that the setup script above also does not work with RSA as a signature algorithm.

The problem thus clearly is no OQS issue but one of correctly working with certificate extensions (unless you use a suitable "openssl.cnf" file that you did not share if you have it).

If you have time to look into this, a PR would be welcome to make the openvpn demo work without kylemanna/openvpn "easyrsa" certificate setup. Most likely, a suitable openssl.cnf file would need to be provided together with a setup script suitably parameterized for algorithm type. I'll get to this in the coming days, if you don't have time, @k-Artin .

[k-Artin]

I try this experiment with OQS-OpenSSL_1-1-1 and post-quantum signatures such as falcon1024 and dilithium, without any error. So OpenVPN don't have any problem with oqs-signatures when using from OQS-OpenSSL_1-1-1. Now I think this problem refer to oqs-provider.

--> The openssl commands above do not add the required extended cert usage fields. Accordingly, the server cannot work. Also, I just verified that the setup script above also does not work with RSA as a signature algorithm.

No. I test it, my setup script workes with RSA as a signature algorithm (openvpn with oqs-provider and kyber512) without any error.

VERIFY ERROR: could not extract CN from X509 subject string ('C=AU, ST=Some-State, O=Internet Widgits Pty Ltd') -- note that the field length is limited to 64 characters

if you notice to log messages, you can see that problem refer to length limitation. Can you find main reason of this problem? @baentsch

Next, I add below line to client config:

remote-cert-tls server

and run script,

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

does not occur.

[baentsch]

TLDR; will do an overhaul of the demo to allow everyone to select arbitrary PQ sig algs. If you're interested in the problem(s), read on.

VERIFY ERROR: could not extract CN from X509 subject string ('C=AU, ST=Some-State, O=Internet Widgits Pty Ltd') -- note that the field length is limited to 64 characters

if you notice to log messages, you can see that problem refer to length limitation. Can you find main reason of this problem? @baentsch

Yes. The problem you stated above:

I have not entered any CN , ST and etc in the certificate.

Thus, the error message is logical: "could not extract CN from X509 subject string". The length limitation statement is just "FYI" and irrelevant in this context (where you did not provide CN). This is the first error. A CN must be provided.

Then:

No. I test it, my setup script workes with RSA as a signature algorithm (openvpn with oqs-provider and kyber512) without any error.

The script works OK, agreed, but it does not create certificates in a form required for openvpn to work correctly: The certificates must have ExtendedKeyUsage fields set as per the documentation. Your sample script does not do that. Here is a corrected script that works (also not doing any prompting):

openssl genpkey -algorithm $1 -out server_key.key && \
openssl genpkey -algorithm $1 -out client_key.key && \
openssl genpkey -algorithm $1 -out ca_key.key && \
openssl req -key ca_key.key -x509 -subj "/CN=oqsopenvpntest CA" -config openvpn-openssl.cnf -out ca_cert.crt && \
openssl req -new -key client_key.key -subj "/CN=openvpnclient.openquantumsafe.org" -config openvpn-openssl.cnf -out client_cert.csr && \
openssl req -new -key server_key.key -subj "/CN=openvpnserver.openquantumsafe.org" -config openvpn-openssl.cnf -out server_cert.csr && \
openssl x509 -req -in server_cert.csr -CA ca_cert.crt -CAkey ca_key.key -CAcreateserial -out server_cert.crt -extensions usr_cert -extfile openvpn-openssl.cnf && \
openssl x509 -req -in client_cert.csr -CA ca_cert.crt -CAkey ca_key.key -out client_cert.crt -extensions usr_cert -extfile openvpn-openssl.cnf 

Essential to the correct operation of that script (where the algorithm name is given as parameter) is an openvpn-openssl.cnf file with the following changes compared to the openssl.cnf that is currently embedded in the docker image:

diff openvpn-openssl.cnf openssl.cnf 
177c177
< req_extensions = v3_req # The extensions to add to a certificate request
---
> # req_extensions = v3_req # The extensions to add to a certificate request
225,226c225
< keyUsage = nonRepudiation, digitalSignature, keyEncipherment,keyAgreement
< extendedKeyUsage        = serverAuth, clientAuth
---
> # keyUsage = nonRepudiation, digitalSignature, keyEncipherment
250,251c249
< extendedKeyUsage        = serverAuth, clientAuth
< keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
---
> keyUsage = nonRepudiation, digitalSignature, keyEncipherment
270c268
< keyUsage = cRLSign, keyCertSign
---
> # keyUsage = cRLSign, keyCertSign

With these changes (to the creation of certificates), openvpn properly starts (both for "rsa" as well as any OQS signature algorithm) -- but only if the debug level is set to 0 ("verb 0" in both client and server config): The reason is that the debug message for "Control Channel:" triggers an error in OpenSSLv3 (not properly displaying a provided signature algorithm). I'll also create a reproducer for this independent of openvpn and fix this in the upstream code.

Thanks again for the report -- lots of moving pieces that need improvement....

[k-Artin]

With these changes (to the creation of certificates), openvpn properly starts (both for "rsa" as well as any OQS signature algorithm) -- but only if the debug level is set to 0 ("verb 0" in both client and server config): The reason is that the debug message for "Control Channel:" triggers an error in OpenSSLv3 (not properly displaying a provided signature algorithm).

thank you this is working. i have a question about that.

why does this error not happen when I use opensslv3 with classic signature, and this problem exists only with OQS signatures ??? (when verb 5)

This option (verb) is only showing openvpn connection details. something is weird and this error shouldn't happen. (Just because of verb option ) are you see any issue or community talking about that???

[baentsch]

thank you this is working.

Thanks for confirming this solves the issue for you.

this error shouldn't happen. (Just because of verb option )

Correct. It should not happen. As I wrote before:

triggers an error in OpenSSLv3 (not properly displaying a provided signature algorithm).

To your comment;

are you see any issue or community talking about that???

Not yet. We'll need to create a stand-alone reproducer for this and raise an issue in OpenSSL.

[baentsch]

Not yet. We'll need to create a stand-alone reproducer for this and raise an issue in OpenSSL.

In case you're interested @k-Artin, I did this now & here's a pointer to a possible fix (and background discussion in the issue): https://github.com/openssl/openssl/pull/20501