Error when client certificate is requested

Question

Error when client certificate is requested

Payne-X6 opened this issue a year ago · comments

When the server requests a client certificate (in the case of a GnuTLS server, the gnutls_certificate_server_set_request function), the aioquic client returns a QUIC Error: 266, reason: , frame_type: 6 error and the connection is closed

doronz88 · Answer 1 · Thu Jun 29 2023 15:47:38 GMT+0800 (China Standard Time)

I'm encountering the same problem when implementing a client for communicating with Apple's iOS services (starting at iOS 17)

Jeremy Lainé · Answer 2 · Tue Jul 04 2023 13:46:51 GMT+0800 (China Standard Time)

Hi, I've been wanting to implement this but lack a publicly accessible server against which to test it. If anyone wants to tackle this please make sure you include a full test suite!

doronz88 · Answer 3 · Wed Jul 05 2023 15:02:57 GMT+0800 (China Standard Time)

@jlaine I added a PR that should handle it
@Payne-X6 can you also make sure this fixes your issue?

Jan Hák · Answer 4 · Thu Jul 13 2023 20:30:22 GMT+0800 (China Standard Time)

@doronz88 I tried your PR. It works with small changes, beware that the client cert does not need to be set (can be set to None).
This is also valid, some server implementations may request but not require a client cert.
But with a few conditions in _client_handle_finished this can be fixed.

Jan Hák · Answer 5 · Thu Jul 13 2023 20:52:36 GMT+0800 (China Standard Time)

One more little detail. From Wireshark it seems that the certificate is sent from the client to the server twice, once in a Protected Payload (I think this is unnecessary) and once in a Handshake packet. I'm not 100% sure where the certificate should be sent, but sending it 2x seems redundant to me.

doronz88 · Answer 6 · Mon Jul 31 2023 15:43:36 GMT+0800 (China Standard Time)

@Payne-X6 I fixed the _client_handle_finished to handle no certificates. From my understanding, the certificate being sent twice isn't necessarily bad, since the client cannot tell before trying to establish the connection wether the remote party would use CertificateRequest-based authentication. I could add an option for disabling its send in the Hello packet.

@jlaine Could you take a look at the PR I reopened? I tested it and managed to create a fully working connections with the new iOS services.

Jan Hák · Answer 7 · Mon Oct 16 2023 21:58:01 GMT+0800 (China Standard Time)

@doronz88 Could you add a not-None check for self.certificate_private_key ? It's crashing on self.certificate_private_key.sign(...) (cf348bd#diff-7ade72bf4580c7d1ea561a54e1067f4d744c1f0f037ccd42737467b0360ab51bR1597).

doronz88 · Answer 8 · Tue Oct 17 2023 13:17:59 GMT+0800 (China Standard Time)

I stopped caring about aioquic since it seems this project isn't very active on PRs (to say the least).
This support was added instead in:

https://github.com/jawah/qh3

Jeremy Lainé · Answer 9 · Sun Nov 05 2023 17:36:41 GMT+0800 (China Standard Time)

I stopped caring about aioquic since it seems this project isn't very active on PRs (to say the least). This support was added instead in:

Great, love the positive attitude. Stepping up and offering to co-maintain would have just been too much effort.

Jeremy Lainé · Answer 10 · Thu Nov 16 2023 16:02:51 GMT+0800 (China Standard Time)

When the server requests a client certificate (in the case of a GnuTLS server, the gnutls_certificate_server_set_request function), the aioquic client returns a QUIC Error: 266, reason: , frame_type: 6 error and the connection is closed

Do you have a public server where you encountered this please?

Daniel Salzman · Answer 11 · Thu Nov 16 2023 16:14:26 GMT+0800 (China Standard Time)

When the server requests a client certificate (in the case of a GnuTLS server, the gnutls_certificate_server_set_request function), the aioquic client returns a QUIC Error: 266, reason: , frame_type: 6 error and the connection is closed

Do you have a public server where you encountered this please?

You can use ns2.xdp.cz. for testing.

Jeremy Lainé · Answer 12 · Thu Nov 16 2023 20:49:27 GMT+0800 (China Standard Time)

You can use ns2.xdp.cz. for testing.

Unfortunately I'm not having any luck, that server doesn't respond to my INITIAL packet. Is it actually an HTTP/3 server?

Daniel Salzman · Answer 13 · Thu Nov 16 2023 20:58:40 GMT+0800 (China Standard Time)

You can use ns2.xdp.cz. for testing.

Unfortunately I'm not having any luck, that server doesn't respond to my INITIAL packet. Is it actually an HTTP/3 server?

It's a DNS server with enabled DNS over QUIC (port 853).

Daniel Salzman · Answer 14 · Thu Nov 16 2023 21:16:03 GMT+0800 (China Standard Time)

Thank you!

Jeremy Lainé · Answer 15 · Thu Nov 16 2023 21:34:28 GMT+0800 (China Standard Time)

PR #386 had a number of problems:

The signature algorithm negotiation was wrong, it would blindly try negotiating any of the supported algorithms, not just the ones compatible with the type of certificate used by the client.
It incorrectly handled the case when the client does not have a certificate compatible with what the server requests. RFC8446 states that the client should still send a Certificate message, but with no certificates.
The client certificate code was not exercised by any tests.

Jeremy Lainé · Answer 16 · Thu Nov 16 2023 21:48:44 GMT+0800 (China Standard Time)

It's a DNS server with enabled DNS over QUIC (port 853).

Ah that's what I was missing. The handshake does complete with the latest code in main both with and without a client certificate. I do however need to disable certificate validation when running the test as the server's certificate does not have any Subject Alternative Name.