How to use msquic to interact with nginx on Linux

[baentsch]

I'm trying to use msquic on Linux (i.e., using openssl) to interact with a quic-enabled nginx server. To someone knowledgable in msquic --and considering I have practically 0 Windows experience-- does this appear feasible? Is there some documentation how to achieve this? When trying to learn about this reading the Linux interop documentation things look bleak.

Concrete questions:

1. Is there (client) sample code (capable of being built and run on Linux) using msquic to interact with https://quic.nginx.org or would one have to try to adapt the sample code?
2. Is there documentation how to set/change the (suggested) TLS1.3 key exchange algorithm(s) on the client (similar to openssl's -groups option)? From reading the code, it seems msquic (at least on Linux/when using openssl) hard codes P-256:X25519:P-384:P-521 without an option to change this. Is this correct and intentional?

Background: The goal is to create an experimental integration of quantum-safe crypto algorithms into (MS)QUIC in an interoperable way (following https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-00) and to easily activate/experiment with the various different algorithms (selected via the TLS1.3 "supported_groups" extension).

Thanks in advance for suggestions/pointers!

[nibanks]

It depends on your definition of interact. MsQuic is purely a QUIC layer/implementation; not HTTP/3. But if your goal is simply to complete an HTTP/3 handshake (not actually do the fully HTTP/3 protocol), then you can use quicreach to do the QUIC handshake:

> quicreach -server:quic.nginx.org -alpn:h3

quic.nginx.org:443:

  0x00000001           h3    reachable

or

> quicreach -server:quic.nginx.org

quic.nginx.org:443:

                    hq-29  unreachable
                    h3-29  unreachable
                      smb  unreachable
               hq-interop  unreachable
  0x00000001           h3    reachable

[nibanks]

For the cipher algorithms, it's a bit more complicated. In MsQuic.h we expose QUIC_ALLOWED_CIPHER_SUITE_FLAGS:

typedef enum QUIC_ALLOWED_CIPHER_SUITE_FLAGS {
    QUIC_ALLOWED_CIPHER_SUITE_NONE                      = 0x0,
    QUIC_ALLOWED_CIPHER_SUITE_AES_128_GCM_SHA256        = 0x1,
    QUIC_ALLOWED_CIPHER_SUITE_AES_256_GCM_SHA384        = 0x2,
    QUIC_ALLOWED_CIPHER_SUITE_CHACHA20_POLY1305_SHA256  = 0x4,  // Not supported on Schannel
} QUIC_ALLOWED_CIPHER_SUITE_FLAGS;

Then, in tls_openssl.c we have the logic to build up the cipher suites string that's passed to OpenSSL. So the right way to add support for a new algorithm would be to update all that code. Temporarily, you could simply update this code though:

//
// Default list of Cipher used.
//
#define CXPLAT_TLS_DEFAULT_SSL_CIPHERS    "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

[nibanks]

Ah, you were asking about key exchange algorithms. Yeah, as you mentioned we don't expose control for that yet (we haven't had any requests to do so), so for now you'd have to just update the hardcoded value.

[baentsch]

you can use quicreach to do the QUIC handshake

Thanks! This looks like just the right thing: The goal is to check the full handshake goes through (ideally finding out after how many retransmissions if any as some algorithms are transferring quite some data...). Data transfer itself isn't that interesting as that's using classic crypto/ciphers.

we don't expose control for that yet [...] so for now you'd have to just update the hardcoded value.

Yikes. Understood -- but... to give you an idea of the number of algorithms we'd need/want to toggle between, take a look here. Maybe I'll go with patching CXPLAT_TLS_DEFAULT_SSL_CIPHERS to the contents of an environment variable instead. There's nothing speaking against that, right?

[baentsch]

ideally finding out after how many retransmissions if any as some algorithms are transferring quite some data...

Answering my own (implicit :) question above: Here's the link answering that: https://github.com/microsoft/msquic/blob/main/docs/Diagnostics.md#performance-counters .

Thus: All questions resolved: Thanks again, @nibanks !

[nibanks]

to give you an idea of the number of algorithms we'd need/want to toggle between, take a look here.

Wow! That's a lot. We don't want to use environment variables preferably. For your own testing that's obviously fine, but to be merged into main, we'd want something that isn't global.

[baentsch]

to be merged into main, we'd want something that isn't global

Me neither. If things turn out to be working OK, I'd add something similar to "-groups" if there'd be wider interest (?) in experimenting with quantum-safe crypto in QUIC.

[nibanks]

I'd definitely say there's interest in this area! Thanks for experimenting with MsQuic!

[baentsch]

In turn let me say Thanks for making msquic publicly available -- and allowing Linux-lovers to work with it: It truly enables nice experimentation!