Comments (6)
I'm seeing what you're seeing in my repro. We'll investigate. Thanks for the report.
from pqcrypto-vpn.
I think I see what's going on here. There are two issues:
-
It turns out the
ecdh-curve
configuration directive in OpenVPN is only respected server-side. It's ignored on the client. In the normal case this makes sense: the client offers up all the groups it supports and the server picks (based on theecdh-curve
directive if provided, or its own default list if not). So the client has x25519 at the top of its list, and starts offering that. In our case, it might make sense to have the client also process the directive, so it sends a supported group list of exactly one element. OpenVPN's options interface doesn't currently support providing more than one curve; we could extend this to allow the client to set a list of supported groups, much as we allowed for a list of supported TLS 1.2 ciphersuites in the previous version. -
Wireshark is leading us astray by not actually parsing everything correctly. There's a Change Cipher Spec, and then there's Continuation Data. The data being split up like this is confusing Wireshark. In my trace, the Change Cipher Spec's size shows as 1242 bytes, which is absurdly oversized for that type. That type is 6 bytes. What follows in that packet and the Continuation Data is another Client Hello, and this time its Key Share extension has the correct group and key exchange data. Wireshark just isn't picking this apart, probably because the Kyber keys are bigger than sikep434. The key exchange data for sikep434 in my trace is 330 bytes, whereas kyber768 is 1008 bytes. Between this and OpenVPN's protocol I think Wireshark is losing track. But, going through the bytes by hand I can pick out the second ClientHello. The rest of my trace is showing as more Continuation Data, but I expect if I pick it apart I'll find another Server Hello to complete the negotiation.
So what's actually happening is:
- Client sends ClientHello with all of its supported groups, but optimistically offers a x25519 key share (because OpenVPN ignores the
ecdh-curve
on the client). - Server replies back with a HelloRetryRequest and says, "No, sikep434 (or kyber768) please" with a key share extension that only states the group. The key exchange data vector can be empty when this extension is used in a HelloRetryRequest. (See 4.2.8 in RFC 8446). Server also sends a ChangeCipherSpec.
- Client sends a ChangeCipherSpec and another ClientHello, in which it offers sikep434 (or kyber768) with new key share.
- Server replies with a ServerHello with its key share.
- And now application data can pass.
If I look at a trace where sikep434 is selected, the same thing is happening: the client first offers an x25519 key share, and the server comes back with a Hello Retry Request with another key share extension that only has the group it wants. In this case, Wireshark manages to see and parse the second Client Hello that comes back with sikep434 group and key exchange data. It's just not seeing it in the Kyber case.
So in summary: Everything looks like it's working as it should, and we are getting a key negotiated with the desired algorithm. Wireshark just seems to be getting confused and isn't parsing all the pieces of the TLS 1.3 negotiation, possibly as a consequence of them being fragmented and/or encapsulated in OpenVPN's protocol.
from pqcrypto-vpn.
I think allowing the client to set group for KEX from the ecdh-curve directive would be helpful; even one choice is fine with the goal of extending it to more than one.
Is there any way you could write a plugin, or modify the wireshark TLS decoder, to handle this? :D
from pqcrypto-vpn.
It looks like making the client respect the ecdh-curve
directive is pretty straightforward, so I'll look into doing that.
I don't think I'm up for trying to fix Wireshark's bugs, though. :) Have you considered opening a bug in their bug tracker, and supplying one of these captures to show what's going on? They'd be much better equipped to fix the parsing than me.
from pqcrypto-vpn.
I tested ecdh-curve
on the client side and it works; kyber512 shows up as expected from looking at the s_client/s_server
. However, for kyber768 wireshark cannot parse it at all. Could you please confirm that for kyber768 the keys are exchanged and that they are of the right size?
from pqcrypto-vpn.
That was what I tracked down before the analysis I posted yesterday, with Wireshark missing the second ClientHello. The key share extension in there had the kyber768 group number and a key share of the right size.
from pqcrypto-vpn.
Related Issues (20)
- Enabling KEM and QSIGNATURE of choice in PQCrypto-VPN HOT 2
- OQS OpenSSL fails to run after build. HOT 2
- PQCrypto-VPN builds and runs, but OQS-KEX keys missing in traffic. HOT 15
- dev1.3 branch, build error HOT 2
- Add command-line parameters to skip either the Linux or Windows build
- Add logging to show key exchange algorithm negotiated HOT 1
- build error
- Update Raspberry Pi "post-quantum access point" instructions for PQCrypto-VPN 1.3 HOT 1
- Instructions for more/all liboqs algorithms support (KEMs and signature) HOT 1
- OpenVPN version update? HOT 1
- Compatibility with OQS-OpenSSL_1_1_1 branch of openssl HOT 1
- Curve configuration setting HOT 10
- Integrate with liboqs 0.4.0 HOT 14
- sidhp751 crash - linux HOT 7
- How to build a custom PQCrypto-VPN with latest (dev) liboqs and OQS-OpenSSL (1.1.1k) on Windows 10 HOT 4
- tls-cipher schemes for control channel negotiation request and certificate read issue HOT 38
- Picnic HOT 3
- Build failure at step 1. HOT 3
- branch: oqsrepo Build Error HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pqcrypto-vpn.