No support for ECC certs with 384 key size, logs doesn't suggest the reason of failure

[Szwendacz99]

The library is not able to handle endpoints using ECC TLS certificate with 384bit key size. Example is quic.nginx.org domain.

It also fails in a way that is not easy to debug and find the reason:

❯ python /tmp/http3_client.py -v https://quic.nginx.org
2024-05-13 16:35:27,075 DEBUG asyncio Using selector: EpollSelector
2024-05-13 16:35:27,084 DEBUG quic [c77d98a740b89af2] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2024-05-13 16:35:27,114 INFO quic [c77d98a740b89af2] Retrying with token (66 bytes)
2024-05-13 16:35:27,116 DEBUG quic [c77d98a740b89af2] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2024-05-13 16:35:27,145 DEBUG quic [c77d98a740b89af2] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2024-05-13 16:35:27,146 INFO quic [c77d98a740b89af2] Connection close received (code 0x128, reason handshake failed)
2024-05-13 16:35:27,146 DEBUG quic [c77d98a740b89af2] QuicConnectionState.CONNECTED -> QuicConnectionState.DRAINING
2024-05-13 16:35:27,746 DEBUG quic [c77d98a740b89af2] Discarding epoch Epoch.INITIAL
2024-05-13 16:35:27,747 DEBUG quic [c77d98a740b89af2] Discarding epoch Epoch.HANDSHAKE
2024-05-13 16:35:27,747 DEBUG quic [c77d98a740b89af2] Discarding epoch Epoch.ONE_RTT
2024-05-13 16:35:27,747 DEBUG quic [c77d98a740b89af2] QuicConnectionState.DRAINING -> QuicConnectionState.TERMINATED
Traceback (most recent call last):
  File "/tmp/http3_client.py", line 564, in <module>
    asyncio.run(
  File "/usr/lib64/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/tmp/http3_client.py", line 387, in main
    async with connect(
  File "/usr/lib64/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib64/python3.12/site-packages/aioquic/asyncio/client.py", line 88, in connect
    await protocol.wait_connected()
  File "/venv/lib64/python3.12/site-packages/aioquic/asyncio/protocol.py", line 132, in wait_connected
    await asyncio.shield(self._connected_waiter)
ConnectionError

This example at least tells that the handshake failed, but I have private domain, where http3 is served by Traefik 3.0.0 and there the reason is empty, and code is the same (0x128).

Tested on 1.0.0 version of aioquic, Python 3.12 (venv) and Python 3.9 (conda venv), both under Fedora system.

[rthalley]

The client is indeed not offering ECDSA_SECP384R1_SHA384, so the error is accurate; the server is rejecting us. Though AFAIK it is not one of the things everyone is supposed to support by default, so I wonder why some web sites are using it. It works if you manually add it to the list (self._signature_algorithms) in the TLS context. I will investigate further if the default should change or if there needs to be some API support.

[Szwendacz99]

Apparently the issue also exists for key exchange algorithms, like on https://www.linuxiarz.pl/ where for h3 connections the Key Exchange Group is "P384", while signature algorithm is good old RSA 2048

[Szwendacz99]

I don't quite see how to set self._signature_algorithms for tls context before connection attempt (which will obviously fail), without modifying the library source code.

[rthalley]

Sorry about the confusion; when I said it works if self._signature_algorithms is set, I actually changed the source just to see what happened. There is no API for this currently. We could just make our list the same as (say) Chrome's, or we could add an API. I'm not sure what is best at the moment.