PQCrypto-VPN builds and runs, but OQS-KEX keys missing in traffic. about pqcrypto-vpn HOT 15 CLOSED

Regarding the Wireshark problem: I'm guessing, but OpenVPN has its own packet framing it uses to multiplex control and data packets over the same connection, and provide reliable transport to the control packets. What you may be seeing is Wireshark seeing the beginning of a TLS 1.2 connection inside the first packet, but getting confused when OpenVPN's framing header appears at the beginning of the next packet. Wireshark supposedly has a dissector for OpenVPN (https://wiki.wireshark.org/OpenVPN) but I don't know why it isn't working here.

As for the content of the TLS handshake, that's a question for the OQS team rather than us, since all details of the TLS handshake are handled by their code. Since we're using an interim version of the code from two years ago at this point, though, it may not be worth digging into this problem too far. I see from open-quantum-safe/openssl#156 you've already discovered some of the issues we've found in trying to migrate to the 1.1.1 fork.

from pqcrypto-vpn.

Do you see the same issue if you establish a regular TLS connection with openssl s_client and s_server with that ciphersuite? It should be the same code running but without any OpenVPN framing that may be messing with Wireshark.

from pqcrypto-vpn.

1. Terminal view, note the failures.
   
2. Wireshark view
   
3. The server never replied, note the error on the terminal for it...129 ciphers to choose from, and not one match available anywhere. That cipher was chosen from openssl ciphers -V; which shows up.
4. Wireshark looking at the cipher suites:
   

It is unclear to me why this fails like so while OpenVPN seems to at least return a server hello without crashing...although without any keys. Listing so many cipher suites is also interesting, unclear if that should be the case.

Edit I tried the Wireshark dissector for OpenVPN with no success for the malformed packets. I even disabled --tls-aut-- to get rid of the HMAC in header and still no success in parsing the whole thing.

from pqcrypto-vpn.

The long list of ciphersuites offered by the server is surprising. Do you not have a tls-cipher in the server configuration?

I'm at a loss to explain this happening with this particular ciphersuite. Have you seen this behavior with any ciphersuites using PQ key exchange algorithms?

from pqcrypto-vpn.

@kevinmkane As you can see, that is the client hello...so that is the list the client is able to accept. The server does have the cipher set to OQSKEX-MLWE-KYBER-ECDSA-WITH-AES-256-GCM-SHA384 as you can see from the command line. Those are not from the OpenVPN, but from the openssl built inside the container using the s_client/s_server.

In particular, for the OpenVPN the chosen cipher does show up on the server side along with one other cipher, which appears to be a default "empty" cipher. The problem is that the key_exchange extension of TLS containing the ECDH key is not present on either the Client or Server Hello for the PQCrypto-VPN.

from pqcrypto-vpn.

I have done some more testing which points in the direction of the original issue:

1. Terminal: I used the command in docs to make available all OQSKEX.
   

2.Client Hello: note number of ciphers available

3. Server Hello: notice the certificate is passed but DH key is not. The cipher chosen was 0xff06 which corresponds to OQSKEX_GENERIC_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
   

4. Server KEX: The TLS record for the KEX is large (4427 bytes), but where are the keys? I would like to note that for OQS OpenSSL 1.1.1, with the oqs-demo for nginx, Wireshark is able to parse the keys in this record even if the algorithms are quantum and show the actual bytes passed in as key material.
   

5. Client KEX:
   

6. Change Cipher Spec: last message on the handshake
   

Worth noting is that the comment I made yesterday where openssl has an error for that specific ciphersuite in that test still happens, but when I specify some other ciphersuite openssl handles it without breaking. I have not made extensive testing, but rather tested a few random ones for sanity.

from pqcrypto-vpn.

Sorry, my head was on backwards yesterday. I meant the tls-cipher directive on the client. not the server.

Have you observed this behavior at all in the 1.1.1 fork of OQS-OpenSSL? What you've said so far suggests you haven't. If not, I'm inclined to defer this for now until we do our update, and see if the problem still occurs at that point. If it doesn't, then it was a bug in the 1.0.2 fork that's no longer being maintained and not worth pursuing, and if it does, then we'll pursue it with the OQS team at that time.

from pqcrypto-vpn.

@kevinmkane How long until the 1.1.1 fork is integrated into PQCrypto-VPN?

from pqcrypto-vpn.

We don't have a set schedule, due to other scheduling constraints unrelated to this project, but we're actively working on it. Right now we're working on the necessary changes to OQS-OpenSSL to allow OpenVPN to select the key exchange algorithms. When those are ready, then we'll start the needed changes to OpenVPN and testing. If you're interested, when we have an initial update ready to try, I'm happy to put it up in a branch.

from pqcrypto-vpn.

Sure, I'd be happy to test stuff. What time scale should I anticipate? weeks, months, years? I might start poking around OpenSSL and OpenVPN source code myself to see how to make it work.

from pqcrypto-vpn.

My hope is about a month, two at the most.

from pqcrypto-vpn.

@ReverseControl I've got a candidate of the 1.3 release ready for you to try out, in the dev-1.3 branch: https://github.com/microsoft/PQCrypto-VPN/tree/dev-1.3

I've moved to using submodules for the various dependencies, so clone with: git clone --branch dev-1.3 --recurse-submodules https://github.com/microsoft/PQCrypto-VPN.git. There's also a Dockerfile under openvpn/build/docker as well. The Windows build is now done completely cross-compiled, so everything gets built in one step now.

Feedback welcome!

from pqcrypto-vpn.

@kevinmkane I will take a look.

from pqcrypto-vpn.

Preliminary report: it kinda works, but not really.

I am only testing the quantum KEX at the moment. I looked at #5 and read your comments there which were very helpful. So, per your example it seems that setting ecdh-curve sikep434 does the right thing in the traffic; setting ecdh-curve kyber512 also seems to do the right thing; but, setting ecdh-curve kyber768 or ecdh-curve kyber1024 does not do the right thing. I will test more and make a detailed issue about it with images of the traffic.

By 'do the right thing' I mean that, both parties send their key material in traffic AND they have about the right number of bytes per their specification on the NIST submission. I will include the exact number of bytes and all that in the detailed issue later.

There are some other minor issues with the binaries to be an issue submitted later; its an easy fix, or this should not be happening at all and I am being silly.

from pqcrypto-vpn.

When you investigate Kyber, can you also run an experiment where you're just running openssl s_server and openssl s_client using those algorithms, and see if you observe the same behavior in the traffic? Our interface to OpenSSL is very thin, so it's hard to imagine what we might be doing to break something that works otherwise. If you observe the same behavior, though, that sounds like an issue for them.

But I will stand by for your reports. Thanks for your continuing interest!

from pqcrypto-vpn.