(Seems my Firefox was a little out of date. It looks like this these days. Same story though.)

Deleted: firefox.png 140 KB

	firefox.png 140 KB View Download

+meacer, estark

Uggg about the filtering software sending it.

We've been discussing making a custom interstitial for cert errors caused by suspected filtering software. Perhaps that same UI treatment could be applied here.

Also, separately, it would be nice to get cert error reports for these too even though they aren't exactly chain validation failures.

This isn't about certificate verification failure.

This is an alert that is intended to be sent *by* the server when the *client* sends a client certificate (little-used TLS login-ish feature) and the *server* did not like it. We can't show an interstitial in this case: there's nothing to click-through. The server did not like our login credentials and won't let us through.

To be clear, by "interstitial" I didn't mean "bypassable SSL error warning." I just meant "screen that shows you error text of some kind." The interstitials for cert errors caused by suspected filtering software won't have a click-through, they will be hard-fails. So we could reuse the same UI even though the underlying trigger is different.

From a terminology standpoint, it might be helpful to call them error pages. That's the part of the code they're in, and they better reflect the fact that it's an error (no hope of recovery), rather than the suggested transient/overridable nature of interstitial.

To be clear, the //net stack is *not* well suited to surfacing network errors through the interstitial_ui (//chrome/browser/ui/webui/interstitials). The certificate interstitials (//components/security_interstitials) can only handle certificate validation errors, while all other UI goes through error pages (//components/error_page).

So it's unclear what you mean by "reuse the same UI" - are you talking about //components/security_interstitials, //chrome/browser/ui/webui/interstitials, or //components/error_page? The only one we can readily reuse is the latter, but I suspect you meant one of the former, and that's significantly more work because it's not how either side is architected.

Re #5: We already share layout HTML/CSS between neterrors and interstitials. It is not a problem. We can figure that out later if we decide we want the same UI treatment.

I think the important question I am trying to pose is, "Do we want to use the same strings for these two error cases?" If the answer is yes, we can hash out the rest.

*shrug* If we have strings for wonky filtering software and we want to surface UI for it, that seems reasonable enough. Though I expect equally many cases will just give us a generic ERR_CONNECTION_RESET and ERR_CONNECTION_CLOSED, so a generic one seems fine enough too.

(Code-wise, there's no reason why we couldn't map access_denied to a different net error code when no certs are sent so ERR_SSL_BAD_CLIENT_AUTH_CERT can still be used when the server is behaving per spec.)

Looking at the 15 most recent product forum entries, 10 of them appear to be instances of this. I think this means we need to special-case the mapping. I don't really want to legitimize this misbehavior though, so I propose we do:

- If access_denied alert and no CertificateRequest was received, map to a generic ERR_SSL_PROTOCOL_ERROR.

That matches how we handle any other random TLS alerts we don't understand. What do folks think?

+gCon, as this is a top 5 error for Chrome

To clarify, all I'm proposing to do is move them from the ERR_SSL_BAD_CLIENT_AUTH_CERT bucket to the ERR_SSL_PROTOCOL_ERROR bucket. (And then  issue #646567  is about moving some ERR_SSL_PROTOCOL_ERROR to the ERR_SSL_BAD_CLIENT_AUTH_CERT bucket.) So we'll still not be able to tell the user more than "something weird happened and we're not sure what", but at least they won't see the word "certificate" and unhelpful error text.

Re #11: I'm fine with that for now. 

It would be nice long term if we could try to detect the content filtering case and show content filtering UI to place the blame appropriately, but we should probably handle the easier / more obvious content filter cases first (which meacer is working on).

https://codereview.chromium.org/2350483002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fe132d9d1a03966649118030e50715d1a063f73c

commit fe132d9d1a03966649118030e50715d1a063f73c
Author: davidben <davidben@chromium.org>
Date: Tue Sep 27 18:07:21 2016

Improve error pages on client certificate failures.

This makes the following changes:

- Tweak ERR_BAD_SSL_CLIENT_AUTH_CERT's text be suitable for both
  invalid and missing client certs. net_error_list.h actually already
  documents it for this case, but the user-visible error does not.

- Since TLS lacks a dedicated alert for missing client certificates,
  servers often send a generic handshake_failure alert. Detect this case
  and map to ERR_BAD_SSL_CLIENT_AUTH_CERT.

- One of the many bad client cert alerts is access_denied.
  Unfortunately, that was badly named so firewalls sometimes send it,
  giving users a confusing error page. Detect this case too and map it
  to ERR_SSL_PROTOCOL_ERROR, the same error we would use for an unexpected
  alert.

Add a bunch of tests for these cases.

Screenshot of the new ERR_BAD_SSL_CLIENT_AUTH_CERT:
https://drive.google.com/file/d/0Bz14lOW5Hke4ZzRPLXZwUUlzOFk/view?usp=sharing

BUG= 630883 , 646567 

Review-Url: https://codereview.chromium.org/2350483002
Cr-Commit-Position: refs/heads/master@{#421265}

[modify] https://crrev.com/fe132d9d1a03966649118030e50715d1a063f73c/components/error_page_strings.grdp
[modify] https://crrev.com/fe132d9d1a03966649118030e50715d1a063f73c/net/socket/ssl_client_socket_impl.cc
[modify] https://crrev.com/fe132d9d1a03966649118030e50715d1a063f73c/net/socket/ssl_client_socket_impl.h
[modify] https://crrev.com/fe132d9d1a03966649118030e50715d1a063f73c/net/socket/ssl_client_socket_unittest.cc