1700884 - Expose more security errors from HTTP3?

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, task, P2)

Description

[Dragana Damjanovic [:dragana]]

Currently, from all nss errors HTTP3 exposes only certificate errors (errors return from the cert verification and if we cannot extract the certificate). Other nss errors are transform into NS_ERROR_NET_HTTP3_PROTOCOL_ERROR.

This errors are relevant for showing error page to a user. Looking at the code that picks which error pages to show:
STATE_USES_SSL_3
STATE_USES_WEAK_CRYPTO
ERROR_CLASS_BAD_CERT
and other nss errors

ERROR_CLASS_BAD_CERT are reported by HTTP/3 stack and are shown
STATE_USES_SSL_3 can not happen (this will be a protocol error)
STATE_USES_WEAK_CRYPTO (QUIC specifies which cipher suite it support; if a peer does not offer them it is fine to interpret that as a protocol error; I expect that neqo will not return this error)
other nss errors - this is also fine to report as a protocol error

I want to ask Dana and Martin:
have I miss some errors that are shown to the users?
do you agree with the above behavior (that is the current behavior)?
Should we expose any other nss error to a user via a error page?

Comment 1

[Martin Thomson [:mt:]]

I don't know if there are other problems that are here, but most of the problems we get in TCP simply aren't possible with QUIC. That's because we expunged all of the bad crypto we have to tolerate with TCP. So yeah, most of the bad stuff is confined to X.509. I wouldn't worry too much about this for the moment.

I checked our fallback code, which has a bunch of reasons we might want to distinguish specific TLS-layer errors. SSL_ERROR_NO_CYPHER_OVERLAP is potentially interesting to surface, but I don't anticipate this being necessary in the short term (there is not a lot of cipher diversity in QUIC at this stage). Everything else is just different ways of reporting that the connection was busted. We care about this in TLS, but the problems in QUIC are less often crypto-based and more like MTU or other transport issues.

Comment 2

[Dana Keeler (she/her) [:keeler]]

I agree - most of the errors that are in any way actionable are certificate errors, so I'm not sure we need to expose more errors here.

Comment 3

[Dragana Damjanovic [:dragana]]

Closing the bug for now. If we need to expose a specific code we will open a separate bug.