certificate exception dialog: use the exposed failed channel from the docshell instead of the recent bad cert service

RESOLVED FIXED in mozilla33

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: keeler, Assigned: keeler)

Tracking

({addon-compat})

unspecified
mozilla33
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Bug 1025330 aims to make available the failed channel that led to a particular SSL error page. In the certificate exception dialog, we can make use of this rather than the flawed recent bad cert service.
Posted patch patchSplinter Review
I'm just uploading this for reference right now.
Comment on attachment 8440173 [details] [diff] [review]
patch

Review of attachment 8440173 [details] [diff] [review]:
-----------------------------------------------------------------

Jared - do you have time to look at this? Thanks.
Attachment #8440173 - Flags: review?(jaws)
Attachment #8440173 - Attachment description: patch for reference → patch
Attachment #8440173 - Flags: review?(jaws) → review+
Doesn't this break Thunderbird, which doesn't use docshells and has to rely on the recent bad cert service?
I don't think so - the certificate exception dialog can fetch the certificate directly if it needs to (by making another request to the peer that failed). If that doesn't work, Thunderbird will have to be modified to pass in the SSLStatus from the failed connection. I've marked addon-compat in case this turns out to be necessary.
Keywords: addon-compat
https://hg.mozilla.org/mozilla-central/rev/2d734c2008b1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(In reply to David Keeler from comment #5)
> I don't think so - the certificate exception dialog can fetch the
> certificate directly if it needs to (by making another request to the peer
> that failed).

That doesn't work for banned (i.e. email) ports...
(In reply to David Keeler (:keeler) [use needinfo?] from comment #8)
> Does this help?
> http://www-archive.mozilla.org/projects/netlib/PortBanning.html#exceptions

No, because the dialog box uses XHR and XHR can't hit those ports.

(In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> [...] Thunderbird will have to be modified to
> pass in the SSLStatus from the failed connection. I've marked addon-compat
> in case this turns out to be necessary.

Yes, that is the correct thing to do.

In fact, David, I suggest that you follow this up by removing the "Add Exception" button from the Server tab of the certificate manager, making the SSLStatus argument mandatory, and then removing the XHR from the dialog box completely, along with removing the UI elements that allow the user to change the hostname, etc. This will make the UI in Firefox (and probably Thunderbird) much more sensible. In Firefox, the "Add Exception" button isn't necessary because if the user wants to add an exception, he/she can just put the URL into the address bar and deal with the error-page-based UI.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #9)
> In fact, David, I suggest that you follow this up by removing the "Add
> Exception" button from the Server tab of the certificate manager, making the
> SSLStatus argument mandatory, and then removing the XHR from the dialog box
> completely, along with removing the UI elements that allow the user to
> change the hostname, etc. This will make the UI in Firefox (and probably
> Thunderbird) much more sensible. In Firefox, the "Add Exception" button
> isn't necessary because if the user wants to add an exception, he/she can
> just put the URL into the address bar and deal with the error-page-based UI.

I'll note that the last time I had to add an SSL exception in Thunderbird, I ended up needing to go through the Add Exception button since the security error dialog either failed to pop up or it failed to let me add an exception.

From recollection of the last time I tried poking in how SSL sockets worked, dealing with these details of SSL connection failures broke my brain--is it possible to write a short guide on the proper way to get the exceptions dialog, etc. working for addon authors (and TB developers)?
(In reply to Joshua Cranmer [:jcranmer] from comment #10)
> I'll note that the last time I had to add an SSL exception in Thunderbird, I
> ended up needing to go through the Add Exception button since the security
> error dialog either failed to pop up or it failed to let me add an exception.

I think that the Add Exception button may still make sense for Thunderbird. However, see below.

> From recollection of the last time I tried poking in how SSL sockets worked,
> dealing with these details of SSL connection failures broke my brain--is it
> possible to write a short guide on the proper way to get the exceptions
> dialog, etc. working for addon authors (and TB developers)?

1. Attempt a connection to the server.

2. Ensure Grab the nsITransportSecurityInfo for your failed connection and store it in securityInfo.

3. let sslStatus = securityInfo.QueryInterface(Ci.nsISSLStatusProvider).SSLStatus;

4. if (!sslStatus || !(sslStatus.isDomainMismatch || sslStatus.isNotValidAtThisTime || sslStatus.isUntrusted)) then stop. Cert error overrides are not going to help you.

3. When you instantiate the dialog box, pass in sslStatus.

Now, if you want to keep the "Add Exception" button functioning after bug 940506, you'll have to do is save the SSLStatus from your failed connection somewhere so that your "Add Exception" button's code can find it. But, IMO, that is a lot of work for a UX that isn't so good. So, maybe it is better to redesign the whole UX for this for Thunderbird. Note that some people working on the B2G email client seem to have come up with a UX for this kind of thing that is quite different than Thunderbird's; perhaps that can be adopted to XUL or something.
Blocks: 1034203
You need to log in before you can comment on or make changes to this bug.