9Tem
Does HTTP/3 necessitate additional – beyond HTTP/2 via TLS1.3 – restrictions on client authentication (mTLS)?
A recent Nginx release allows me to set listen 443 quic; to enable HTTP/3. Neat. I had been using HTTP/2 with TLS1.3 before, so I did not expect that change much, just optimize round trips with otherwise matching security properties.
One major change, though: Firefox will not send client certificates. Though it perfectly could:
- Same RSA+sha256 certificate fed to
aioquicHTTP/3 example authenticates to same website. - Same RSA+sha256 certificate is offered by identical Firefox binary & profile via HTTP 1 or 2
Unfortunately, Firefox does not tell me for what reason it choses to disregard the certificate request only while using HTTP/3. Am I missing some difference between TLS1.3 via TCP and QUIC?
- Unordered packets complicate things a bit.. Maybe some security guarantee could not be upheld if this worked in QUIC exactly as it does over TCP?
- Renegotiating while multiplexing is not an option, right? I heard it was outright banned in HTTP/2 which HTTP/3 keeps up.
- Maybe some limitations on which algorithms the certificate has to use? Yet the transport should not change the authentication part of the whole TLS dance, as that had already been properly separated from record protection when upgrading from TLS 1.2.
