Trying to understand netlogs with

[Pavol Marko]

Hi all,

we've got netlogs in https://bugs.chromium.org/p/chromium/issues/detail?id=1378144#c12 where some SOCKETs end up in 

t=23002 [st=4527] SSL_CLIENT_CERT_REQUESTED
t=23002 [st=4527] -SSL_CONNECT
--> net_error = -110 (ERR_SSL_CLIENT_AUTH_CERT_NEEDED)

while others continue providing a client certificate.

I'm struggling to understand the difference.

It would be nice if someone who can interpret this could check :-) Thanks!

So far, my only guess would be that chrome decides to not provide a client certificate for some reason (which would be weird), but I'm not sure if URLRequest / layers further below could decide on their own to abort when a client cert has been requested?

Thanks,

Pavol

[David Benjamin]

Seeing ERR_SSL_CLIENT_AUTH_CERT_NEEDED is to be expected and doesn't indicate a problem in itself. You need to look at surrounding objects for the context.

We don't learn client certificates are requested until after we connect to the server. If the net stack doesn't have a client certificate decision cached for a host, individual sockets do not know how to answer a CertificateRequest, received in the middle of a TLS handshake. When we see such a thing, we need to go through series of steps, jumping up through the browser, as none of this is available from the network service:

1. Query the OS for what client certificates are available

2. Ask the user (or have the enterprise policy suppress the prompt) which certificate to use.

3. Load the private key associated with the client certificate.

4. Continue the handshake, generating a signature with the private key at the appropriate time

Each of these steps may take time, potentially even block on user prompt, either because we need to prompt (step 2), or because the smartcard driver shows a PIN prompt at inopportune time, or because some operation blocks on a very slow TPM. (Ideally only step 4 would block on the TPM, but perhaps CrOS has regressed this.) If we were to keep the handshake waiting that whole time, particularly across step 2, the server would likely time out on us. Additionally, the way the net stack optimizes connection use makes usefully pausing the socket tricky. (The auth request needs to be bound to a URLRequest in order to be linked back to a tab, to show UI.) There are also cases with TLS renegotiation that further complicate matters.

So, instead, as soon as the net stack sees a CertificateRequest it doesn't know how to answer, it aborts the socket with ERR_SSL_CLIENT_AUTH_CERT_NEEDED. The layer above that then catches this error, and surfaces it out of URLRequest::Delegate::OnCertificateRequested. You can see this in the NetLog as URL_REQUEST_DELEGATE_CERTIFICATE_REQUESTED. That comes out of the network stack and lets the browser do steps (1-3). I see that step is taking a while, which suggests either something in CrOS's machinery here is being slow, or we're waiting on the user to make a decision. If this user has the enterprise policy to suppress a prompt, it's the former. This may be related to https://crbug.com/1385566, which also looks like a CrOS performance regression.

There may also be multiple of these happening in parallel, if multiple requests happen at once.

From there, one of three things can happen:

- We get a client certificate and key. These are passed back to the network service (the key is wrapped in a Mojo object), which caches the decision across the URLRequestContext and then restarts the HTTP request, getting a fresh connection. This time when we get a CertificateRequest, we'll know how to respond, without blocking on user activity.

- The user might choose to continue with no client certificate. This is passed back to the network service which, again, caches the decision and restarts. We'll get a CertificateRequest again and, once more, we know how to respond.
- The client certificate request is aborted. We leave the URLRequest to fail with ERR_SSL_CLIENT_AUTH_CERT_NEEDED and do not update the cache. This mostly happens if the URLRequest is no longer associated with a tab, so the user didn't make an affirmative decision one way or nothing. (We can't continue without a certificate because that would get cached and it's possible, had the user been prompted, they would have chosen a certificate.)

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMNoXd3gmcHfaZnBF51prjAYRRrpqhtFNCt3EU0GWZX85aojBQ%40mail.gmail.com.

[Michael Ershov]

Hi David, thank you for checking.

https://crbug.com/1385566 indeed looks related, I also noticed in our bug that it affects both ash and lacros.

So I'll deduplicate them.

Your answer gives a lot of very useful context on the issue and I think it'd be nice to copypaste it into the bug you linked (before we forget that this thread exists). But will leave the decision on sharing it with a wider audience to you =) 

Michael Ershov

Software Engineer

mie...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

Thanks,

Pavol

[David Benjamin]

Feel free to paste it or link to it or whatever. This is a public list anyway :-)