Chrome reaction to Alt-Svc header and user-generated CA + cert

[Nicholas Jennings]

Hi All, I'm in the process of testing the `Alt-Svc` header with Chrome and QUIC.

I have an HTTPS service (TCP 443) and a QUIC service (UDP 443) running on an internal network. I've generated a root CA and used it to sign a cert that's used by both of the services. I've also added the CA to system that is running Chrome.

If I use Chrome to access the HTTPS service (let's call it `example.org`) the cert is recognized and accepted without manual intervention to accept the cert. The same for the QUIC service if I load Chrome with the following directive to explicitly use QUIC at the start:

```

open -a "Google Chrome Canary" --args --enable-logging=stderr --v=1 --user-data-dir=/tmp/canary --enable-quic --no-proxy-server --allow-insecure-localhost --origin-to-force-quic-on=www.example.org:443

```

In other words, if I explicitly go to either the HTTPS or QUIC service, the cert is recognized and accepted without any warnings. 

Now, if I add an `Alt-Svc` header to the HTTPS service:

```

Alt-Svc: quic=":443"; v="44,43,39,46"; ma=93600

```

The browser never switches over to QUIC on subsequent refreshing of the HTTPS page (I've verified QUIC is enabled in the browser). Using wireshark, I see a few UDP packets sent behind-the-scenes and in the final packet the cert is rejected, inspecting the packet contains the following string:

```

TProof invalid: Failed to verify certificate chain: net::ERR_QUIC_CERT_ROOT_NOT_KNOWN

```

From the users-perspective there is no error and they only see the content served from HTTPS and never QUIC.

If we test with a cert signed with a trusted public CA, we do not encounter this rejection, the Alt-Svc header is used as expected. So this is only happening when using custom generated CA to sign the cert (ie. for internal testing).

Does anyone have any more information on this? Is it the intended behaviour for Chrome? 

Thanks,

Nick Jennings

Akamai Technologies

[David Schinazi]

Hi Nicholas,

This is intended behavior. Chrome does not currently allow custom root CAs for QUIC.

In other words, when the certificate chains to a root that isn't publicly trusted, Chrome disallows QUIC but allows TLS.

When this happens, QUIC fails with net::ERR_QUIC_CERT_ROOT_NOT_KNOWN.

If you are testing QUIC, I'd recommend getting a free certificate from LetsEncrypt.

David

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/a4d92e8f-6c79-4108-8de2-c2ee40ad637c%40chromium.org.

[Nick Harper]

You can also test QUIC with the --origin-to-force-quic-on command line flag, though that skips the Alt-Svc header processing.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAPDSy%2B5hbU3q951K%3DiMf_ZHQt%3Dpkt_CGpHdJeMiNLPaPsrCboQ%40mail.gmail.com.

[Jennings, Nicholas]

Hi David,

 

Do you know if this is public trust is determined by the EV qualified list that’s bundled in the Chromium binary?  Is there a way to subvert this or add a custom CA to this list? Either with a command-line parameter, or less ideally - with code modification?

In order to get a certificate with LetsEncrypt I believe we would need a publicly accessible IP, which we currently don’t have access to within our test environment. It’s an option, but in the meantime I’m wondering if there is any other possible work-around.

 

For any other testing with Chrome, the –origin-to-force-quic-on param (as Nick Harper mentioned) works fine, however for this test case it’s not appropriate as we need to first make the request to the TCP service before we can verify the switch to UDP.

 

Thanks,

Nick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAPDSy%2B5hbU3q951K%3DiMf_ZHQt%3Dpkt_CGpHdJeMiNLPaPsrCboQ%40mail.gmail.com.

[Nick Harper]

On Fri, Mar 13, 2020 at 9:50 AM 'Jennings, Nicholas' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hi David,

 

Do you know if this is public trust is determined by the EV qualified list that’s bundled in the Chromium binary?  Is there a way to subvert this or add a custom CA to this list? Either with a command-line parameter, or less ideally - with code modification?

The public trust does not require an EV cert, just that Chrome recognizes the root CA as a standard root (as opposed to user-installed root). It's definitely possible to get around this with a code modification - I believe the files you want to look at are //net/cert/known_roots_$PLATFORM.(cc|h).

In order to get a certificate with LetsEncrypt I believe we would need a publicly accessible IP, which we currently don’t have access to within our test environment. It’s an option, but in the meantime I’m wondering if there is any other possible work-around.

 

For any other testing with Chrome, the –origin-to-force-quic-on param (as Nick Harper mentioned) works fine, however for this test case it’s not appropriate as we need to first make the request to the TCP service before we can verify the switch to UDP.

There's a chance the --ignore-certificate-errors-spki-list flag might work around this. It takes a comma-separated list of sha256 spki hashes of certs that if present in the cert chain will skip the normal cert verifier. This flag has to be used with --user-data-dir not pointing to the default location. I'm doubtful it will work though because I don't see it setting is_issued_by_known_root in the CertVerifyResult struct.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/08102910-DF8F-431E-B2C6-5D1103A9C9FD%40akamai.com.