Closed Bug 943937 Opened 11 years ago Closed 6 years ago

for non-overridable certificate errors, provide the same diagnostic information as for overridable errors

Categories

(Firefox :: Security, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: gerv, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [fxprivacy])

At the time of writing, connecting to:
https://mailhost.icec.ti-edu.ch/Login.aspx?ReturnUrl=%2fdefault.aspx
fails with the following error:

"An error occurred during a connection to mailhost.icec.ti-edu.ch. The Certifying Authority for this certificate is not permitted to issue a certificate with this name. (Error code: sec_error_cert_not_in_name_space)"

However, the Firefox UI to the left of the URL bar, when clicked, says "This website does not supply identity information", which is what it says for HTTP connections. So, it does not allow the user to view the details of the problematic certificate. Chromium does.

Gerv
The certificate chain should be available as of bug 1029155 (generally docshell.failedChannel.securityInfo.failedCertChain, with some QueryInterface-ing as appropriate). Now it's just a question of building appropriate UI around it. (Note that for overridable errors, we already do expose this information in a way (if the user clicks the error code in the advanced section, we dump out some text that shows the encoded certificates - they can then use openssl or some other tool to examine them)).
Component: Security: PSM → Security
Product: Core → Firefox
Summary: Firefox does not give UI access to cert when connection fails with namespace error → for non-overridable certificate errors, provide the same diagnostic information as for overridable errors
I believe we have all the infrastructure necessary to implement this, I would use the exact same UI as in:

https://subdomain.preloaded-hsts.badssl.com/

The only thing I'm still unsure of is which error cases we want to apply this behavior to. Comment 0 mentions sec_error_cert_not_in_name_space, I assume SEC_ERROR_REVOKED_CERTIFICATE is another. Can we get the full list of error cases we want to handle like this?
Whiteboard: [fxprivacy][triage]
Priority: -- → P3
Whiteboard: [fxprivacy][triage] → [fxprivacy]
(In reply to Panos Astithas [:past] from comment #6)
...
> The only thing I'm still unsure of is which error cases we want to apply
> this behavior to. Comment 0 mentions sec_error_cert_not_in_name_space, I
> assume SEC_ERROR_REVOKED_CERTIFICATE is another. Can we get the full list of
> error cases we want to handle like this?

Basically any error where nsINSSErrorsService.isNSSErrorCode returns true (note that you have to pass it an NSPR error code, not an nserror value) and nsINSSErrorsService.getErrorClass returns ERROR_CLASS_SSL_PROTOCOL. One caveat is that the failedChannel.securityInfo.failedCertChain might not be available in all cases.
Has there been progress on this bug?
It's very problematic -- whenever I run into the non-over-rideable error, it appears that my only recourse as an end-user is to use a different browser to figure out what is going on.
Blocks: 706392
No longer depends on: 706392
Dana, do you think we could add that to the roadmap? Thanks
Flags: needinfo?(dkeeler)
(In reply to Sylvestre Ledru [:sylvestre] from comment #13)
> Dana, do you think we could add that to the roadmap? Thanks

J.C. would have a better idea of where this would fit into the roadmap.
Flags: needinfo?(dkeeler) → needinfo?(jjones)
I agree we should fix this, and am marking it as blocking Bug 1442203 which tracks our error page fixups.

That said, is this going to be changes to the about:certerror / about:neterror code that we're moving to JS in Bug 1415279? E.g., is this one of those things that was fiendishly hard while it was all mostly in C++, and now will be easy-ish?
Flags: needinfo?(jjones)
Some of the prep work we did for bug 1415279 certainly makes this easier. I think at this point really what's necessary is finishing the X509.jsm implementation (including appropriate cert linters) and building something that displays the relevant information in a useful way (which I imagine involves some design work). (See also the bug to reimplement the cert viewer in JS, which I can't find right now.)
I'd say this was resolved with bug 1484873, right?
Flags: needinfo?(jjones)
Flags: needinfo?(dkeeler)
I agree. Certainly the spirit is handled.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jjones)
Flags: needinfo?(dkeeler)
Resolution: --- → FIXED
I'm running 64.0a1 (2018-10-18) (64-bit), and I browse to https://revoked.r6.roots.globalsign.com/ and I still see the old non-override-able error message. It's fine that I cannot override it, but how do I get the cert chain? I do not see the "More..." button.

For https://expired.r6.roots.globalsign.com/ I can get the cert chain by clicking on the "More..." button and then clicking on the link in the error code, "SEC_ERROR_EXPIRED_CERTIFICATE", and then "Copy text to clipboard".
(In reply to Kathleen Wilson from comment #20)
> I'm running 64.0a1 (2018-10-18) (64-bit), and I browse to
> https://revoked.r6.roots.globalsign.com/ and I still see the old
> non-override-able error message. It's fine that I cannot override it, but
> how do I get the cert chain? I do not see the "More..." button.
> 
> For https://expired.r6.roots.globalsign.com/ I can get the cert chain by
> clicking on the "More..." button and then clicking on the link in the error
> code, "SEC_ERROR_EXPIRED_CERTIFICATE", and then "Copy text to clipboard".

Yes, making OCSP errors get the same treatment as certificate errors is bug 1486551. I'm looking into it :)
I didn't realize they were separate. Thanks!
Hmmm - I was more thinking we would add the behavior where if you click the error code we show a dump of debugging information. Is that planned?
Flags: needinfo?(jhofmann)
(In reply to Dana Keeler [:keeler] (she/her) (use needinfo) from comment #23)
> Hmmm - I was more thinking we would add the behavior where if you click the
> error code we show a dump of debugging information. Is that planned?

Sorry, I don't understand. Sites with HSTS already have that feature, they are only distinct from non-HSTS sites in that they don't get the button to skip. Do you mean for OCSP? Yeah, my plan would be to make OCSP errors look approximately like HSTS errors look right now, but we should probably discuss that somewhere else :)
Flags: needinfo?(jhofmann)
You need to log in before you can comment on or make changes to this bug.