Here is the answer I think, but I can't decipher it:
Delayed error responses
When Squid fails to negotiate a secure connection with the origin server and bump-ssl-server-first is enabled, Squid remembers the error page and serves it after establishing the secure connection with the client and receiving the first encrypted client request. The error is served securely. The same approach is used for Squid redirect messages configured via deny_info. This error delay is implemented because (a) browsers like FireFox and Chromium do not display CONNECT errors correctly and (b) intercepted SSL connections must wait for the first request to serve an error.
Furthermore, when Squid encounters an error, it uses a trusted certificate with minimal properties to encrypt the connection with the client. If we try to mimic the true broken certificate instead, the user will get a browser error dialog and then, if user allows, the Squid error page with essentially the same (and possibly more detailed/friendly) information about the problem. Using a trusted certificate avoids this "double error" effect in many cases. And, after all, the information is coming from Squid and not the origin server so it is kind of wrong to mimic broken origin server details when serving that information.
Squid closes the client connection after serving the error so that no requests are sent to the broken server.
It is important to understand that Squid can be configured to ignore or tolerate certain SSL connection establishment errors using sslproxy_cert_error. If the error is allowed, Squid forgets about the error, mimics true broken certificate properties, and continues to talk to the server. Otherwise, Squid does not mimic and terminates the server connection as discussed above. Thus, if you want users to see broken certificate properties instead of Squid error pages, you must tell Squid to ignore the error.
from https://wiki.squid-cache.org/Features/MimicSslServerCert