serverCertificateHashes really only allow if not pooled?
martenrichter opened this issue · comments
I am wondering why serverCertificateHashes does not allow pooling.
If the connection hashes in the implementation include a sorted list of the supplied serverCertificateHashes, the implementation may pool if the hashes match.
(Also, I think that Firefox currently always pools, but I am not sure if I understand the source correctly; it just looked like it in the debugger?)
I don't think Firefox supports pooling yet, but I could be behind. @jesup ?
That is correct, Firefox doesn't currently support pooling
Bug 1815735 - Implement pooling for webtransport
I am not 100% sure, but I will investigate it further (I need to look deeper into the code while fixing serverCertificatehashes). I think Firefox may only support pooling... as the connection hashes do not distinguish different sessions. (https://bugzilla.mozilla.org/show_bug.cgi?id=1873263)
So, at least in my interpretation (not sure whether this follows from the spec text currently), "allowPooling" does not just allow pooling two different WebTransport sessions, it specifically instructs the browser to use the default HTTP session pool (which would mean a pre-existing HTTP/3 connection that is also used for regular HTTP requests), and those have to follow regular certificate validation rules.
@vasilvv is correct. allowPooling: true translates to newConnection = "no" in
- "Let connection be the result of obtaining a connection with networkPartitionKey, url, false, newConnection, and http3Only. If the user agent supports more than one congestion control algorithm, choose one appropriate for congestionControl for sending of data on this connection. When obtaining a connection, if serverCertificateHashes is specified, instead of using the default certificate verification algorithm, consider the certificate valid if it meets the custom certificate requirements and if verifying the certificate hash against serverCertificateHashes returns true. If either condition is not met, let connection be failure."
Parsing that, it first calls:
...which may then bail early and return any existing connections that happen to match (i.e. pooling). Are certificates relevant here?
But then we still append that whole "if serverCertificateHashes is specified" section, and I don't see any specific language around when that does or doesn't apply. On first brush I see no reason why allowPooling: true changes anything in the case where this algorithm doesn't bail early.
I guess it comes down to whether these certificate-hash-based connections end up in the "connection pool"?
it specifically instructs the browser to use the default HTTP session pool (which would mean a pre-existing HTTP/3 connection that is also used for regular HTTP requests),
Ok, that is also what I thought, and the regular certificate chain requirement can only be lifted if the network partition key (I assume that it is a hash uniquely identifying the connection) also contains something to mark the current collection of server CertificateHashes.
I guess it comes down to whether these certificate-hash-based connections end up in the "connection pool"?
Precisely, that is the question.
My question was motivated by my desire to fix a web transport issue in the stream handling in Firefox (together with my lib), but for an easy test setup, I needed the serverCertificateHashes stuff.
So I am fixing the implementation there, and at the moment, I think Firefox always used the connection pool, but I have to sort this out so that no connection with serverCertificateHashes compromises the standard pool.
Meeting:
- Do we want to allow pooling of custom serverCertificateHashes?
- Orthogonal in theory
- We could simply say no pooling of serverCertificateHashes
- pooling is largely an optimization
- What's the benefit of creating two separate WebTransport sessions A and B compared to just using A?
- What if there's a separate app making the same connection?
- Might be low priority
- Defer
@jan-ivar
Could you also please comment on the following (as you are from Mozilla):
https://phabricator.services.mozilla.com/D197857
That is the work-in-progress patch for Firefox, which can also offer pooling with serverCertificatehashes, so that it steers in a useful direction.
Meeting:
- No strong interest in changing language around this at this time.